Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Definir con precisión qué repo de alumne usar #49

Open
dato opened this issue Aug 12, 2020 · 6 comments
Open

Definir con precisión qué repo de alumne usar #49

dato opened this issue Aug 12, 2020 · 6 comments
Assignees

Comments

@dato
Copy link
Member

dato commented Aug 12, 2020

Está claro que los TPs individuales van al repo individual (columna Repo de la hoja Repos). Pero a partir de ahí, nada es 100% una ciencia exacta.

El import a los repos de alumnes todavía se está haciendo en el corrector.py independiente. Ahora que lo vamos a hacer desde el sistema de entregas, afortunadamente tendremos mucha más información (identificador exacto que se usó para hacer submit del form, acceso a la planilla, etc.).

Hay que definir exactamente lo que se debe implementar acá, pero en combinación con una descripción de cómo se actualizará manualmente en la planilla si se forman/rompen grupos.

@mbuchwald
Copy link
Contributor

Veo diferentes casos:

  1. Alumnos que hacen alguno/s TDAs por separado (puesto que uno o ambos integrantes del grupo son recursantes). Entregan individualmente sus TDAs (i.e. usan padrón para entregar, no el id del grupo).
  2. Alumnos que otrora estaban unidos se separan (no es usual, pero pasa, y pasó este cuatrimestre).
  3. Uno de los alumnos del grupo abandona la materia (esto es más usual). Esto entiendo que no debería perjudicar el proceso.
  4. Dada las situaciones de 2 y 3, más la posibilidad de alguien que empezó haciendo entregas grupales solo decida hacer grupo, se unirán grupos.
  5. Dado lo anterior, podría pasar que alguien pase de grupo A -> Solo -> grupo B. O de Solo -> grupo C.

Puede que se me escape algún caso, pero esto me parece lo más usual.

Me parece que una forma sencilla de resolver la problemática solo vs grupo es que si entregan por padrón -> Entrega individual y va a repo individual y listo, ya sea para el caso de estar solo o hacer entrega individual estando en grupo.
Y para estar seguros que no hay problemas con la formación de grupos, cada vez que se forma un grupo nuevo (sea unión o lo que fuere) se le debe asignar un ID nuevo. Idem si separan (en ese caso, a ambos).
En ese caso deberíamos dejar bien claro en la UI del sistema de entregas. Nada difícil, pero lo aclaro.

@mbuchwald
Copy link
Contributor

Vale aclarar que esa lógica de padrón vs id de grupo es la que ya estamos usando para determinar quienes hacen la entrega y a qué corrector hay que enviarle (hace un tanto de tiempo, si entregabas por padrón el hash se le enviaba a tu corrector de individuales en vez de a los de grupales, que es a quien correspondería ya que son de la segunda parte)

@dato
Copy link
Member Author

dato commented Aug 13, 2020

OK. (Respecto a esto último, resultaría que hay correcciones de más de un docente en el mismo repo; pero por supuesto eso no es problema, aún mejor, y son PRs separadas.) Entonces, recapitulando:

@dato
Copy link
Member Author

dato commented Aug 13, 2020

1

Del lado de la implementación:

  • Una entrega por padrón, siempre al repo individual (columna "Repo")

Preguntas que hace la implementación lado de la planilla:

  • ¿Tendrán los alumnos que van solos, un ID de Grupo? ¿Qué hacer si se entrega por ese ID?
  • Ignorar la columna Repo2, aunque no esté vacía; usar el individual.
  • Dar error si la columna Repo2 no está vacía.
  • Usar la columna Repo2 si no está vacía.

3

Si un alumno abandona la materia, sería cuestión de eliminarle a mano el acceso a su repo (por aquello de que no tenga acceso a código que no escribió.) Eventualmente (muy eventualmente) se puede automatizar.


2

Para este caso, creemos que lo que conviene es...

  • No darles un ID nuevo, borrar el contenido de la columna Repo2 para ese grupo
  • Darles un ID nuevo, por si acaso; actualizar columna Repo2 a repo individual de cada une

El problema de ambas opciones es si había correcciones a mitad, pues de repente no se pueden hacer reentregas al pull request existente.

(El tema de las correcciones a mitad en separaciones y merges del grupos es EL tema; y tengo la impresión que quizás podamos terminar necesitando un esquema más flexible para especificar los repos.)


4

Para el caso de unir dos alumnes individuales no es mucho problema, pueden seguir (re)entregando en su repo individual aquellas correcciones que estuvieran a mitad.

@mbuchwald
Copy link
Contributor

mbuchwald commented Aug 13, 2020

1

¿Tendrán los alumnos que van solos, un ID de Grupo? ¿Qué hacer si se entrega por ese ID?

Hoy en día sí, pero podríamos enforcear que no. Igualmente van a haber casos de gente con ID de grupo entregando de forma individual. Pero hoy en día a estos les da lo mismo si entregan con padrón o ID, y eso podría perjudicarnos. Podemos definir que quienes están solos entregan con padrón y listo, para que para nosotros sea consistente -> padrón = individual, ID -> grupal. Entonces simplemente usamos la opción 3.

Hay que considerar que esto sólo sea para las entregas grupales. Para las individuales tienen que poder seguir entregando de forma individual (seguro estaba implícito, pero lo digo para considerarlo al hacer pruebas)

3

Si un alumno abandona la materia, sería cuestión de eliminarle a mano el acceso a su repo (por aquello de que no tenga acceso a código que no escribió.) Eventualmente (muy eventualmente) se puede automatizar.

Si, esto no me preocupa mucho, honestamente.

2

Yo veo que cuando se resuelvan los temas del grupo, podría simplemente borrarse el ID de grupo y que entreguen de forma individual. Si luego se unen a otres, se les asigna un nuevo ID (y repo). Esto mismo debería hacerse en el caso que uno abandone: mantenemos el ID mientras hayan correcciones pendientes, y luego lo borramos.

Los problemas con el punto 2 y 3 es que:
a. Dependemos de la velocidad de quien corrige (si demora mucho, los alumnos no pueden hacer entregas de otros TPs, sea de forma individual o con nuevo grupo).
b. Quien corrige debería encargarse de borrar el ID del grupo cuando termine de corregirse esa entrega pendiente. No puedo hacerlo proactivamente (como si suelo mover a abandonaron) porque tenemos esto de las entregas pendientes.

4

Esto depende de cómo se implemente. Si era alguien que estaba en un grupo y ahora pasó a estar en otro (se rompió el anterior por "divorcio" o "abandono", y se unió con otro).

Un caso de este cuatri fueron Miguel y Mariano. Miguel estaba en grupo con X, que abandonó, y Mariano estaba solo, y se unieron para el TP2.

@dato
Copy link
Member Author

dato commented Aug 15, 2020

Se me ocurre una alternativa, vía ajustes en la UI y en la hoja Repos:

  1. en la web, se empieza por pedir siempre el padrón como ID, y se lo pide antes del campo entrega (este paso desaparece una vez haya autenticación)

  2. la hoja Repos se maneja en modo append-only; por ejemplo, si une alumne cambia de grupo, no se cambia su columna Nro Grupo, sino que se añade una nueva fila con su nuevo id de grupo (ver detalles abajo)

  3. con esto, la UI se puede articular así, de manera bastante automatizada:

    entregas2

    • si es una entrega individual, se selecciona automáticamente Entrega individual, y no se puede cambiar
    • si es una entrega grupal:
      • si el legajo introducido aparece una sola vez en la hoja Repos, se selecciona automáticamente grupal/individual según figure con ID de grupo o no
      • caso contrario, se le permite elegir entre individual, o grupal (con el drop-down ofreciendo todos sus grupos conocidos)

    La idea es que estos (nuevos) radio-buttons se manejan automáticos para el 90% de los casos (esto es: quien nunca cambia de grupo, no tiene que ajustarlos nunca [sin recursantes en juego]).


Manejo de la planilla:

  1. no dar group ID a grupos formados por una sola persona
  2. si dos personas solas, forman grupo: dar group ID en las filas existentes de Repos
  3. si una persona que está en grupo, abandona el grupo, no hacer nada (útil para permitir correcciones pendientes)
  4. si una persona estuvo en un grupo, y cambia a otro, añadir fila en la hoja Repos; no cambiar celdas
  5. no reutilizar IDs de grupo

dato added a commit to dato/algo2_sistema_entregas that referenced this issue Sep 25, 2020
Estos son los cambios requeridos en el "backend" (corrector.py), lo
siguiente es que el frontend (main.py) complete el campo alu_repo de
la tarea CorregirTask—leyendo para ello la planilla, y las guidelines
de algoritmos-rw#49.

Como seguramente haga merge de este PR una vez a la par que el PR del
front-end, voy a decir que this closes: algoritmos-rw#51.
dato added a commit to dato/algo2_sistema_entregas that referenced this issue Sep 26, 2020
Estos son los cambios requeridos en el "backend" (corrector.py), lo
siguiente es que el frontend (main.py) complete el campo alu_repo de
la tarea CorregirTask—leyendo para ello la planilla, y las guidelines
de algoritmos-rw#49.

Como seguramente haga merge de este PR una vez a la par que el PR del
front-end, voy a decir que this closes: algoritmos-rw#51.
dato added a commit to dato/algo2_sistema_entregas that referenced this issue Sep 28, 2020
Con vistas a definir con precisión a qué repositorio se debe importar
el código (ver algoritmos-rw#49), en este commit se comienza por:

  - siempre pedir el legajo a la persona que está subiendo el código

  - para entregas grupales, hacer explícita la elección de si el código
    se sube a título individual, o grupal (antes esto iba implícito según
    se usase padrón o número de grupo como identificador)

Cambios en la UI:

  - se renombra el campo Identificador, a Legajo (el número de grupo
    se muestra, si lo hay, pero nunca se pregunta explícitamente)

  - se introduce un selector "radio" que, para trabajos grupales,
    permite cambiar la modalidad a entrega a título personal.

Refactorings internos:

  - el JSON de correctores que se envía a index.html pasa a tener
    como claves solamente legajos (eliminando claves GXX y gYYYY);
    los valores son ahora un arreglo que especifica correctores
    (individual y grupal), y número de grupo.

    Esto facilita poder seguir mostrando los nombres de corrector,
    y además saber en O(1) el número de grupo asociado a un legajo.
dato added a commit to dato/algo2_sistema_entregas that referenced this issue Sep 30, 2020
Con vistas a definir con precisión a qué repositorio se debe importar
el código (ver algoritmos-rw#49), en este commit se comienza por:

  - siempre pedir el legajo a la persona que está subiendo el código

  - para entregas grupales, hacer explícita la elección de si el código
    se sube a título individual, o grupal (antes esto iba implícito según
    se usase padrón o número de grupo como identificador)

Cambios en la UI:

  - se renombra el campo Identificador, a Legajo (el número de grupo
    se muestra, si lo hay, pero nunca se pregunta explícitamente)

  - se introduce un selector "radio" que, para trabajos grupales,
    permite cambiar la modalidad a entrega a título personal.

Refactorings internos:

  - el JSON de correctores que se envía a index.html pasa a tener
    como claves solamente legajos (eliminando claves GXX y gYYYY);
    los valores son ahora un arreglo que especifica correctores
    (individual y grupal), y número de grupo.

    Esto facilita poder seguir mostrando los nombres de corrector,
    y además saber en O(1) el número de grupo asociado a un legajo.
dato added a commit to dato/algo2_sistema_entregas that referenced this issue Oct 1, 2020
Estos son los cambios requeridos en el "backend" (corrector.py), lo
siguiente es que el frontend (main.py) complete el campo alu_repo de
la tarea CorregirTask—leyendo para ello la planilla, y las guidelines
de algoritmos-rw#49.

Como seguramente haga merge de este PR una vez a la par que el PR del
front-end, voy a decir que this closes: algoritmos-rw#51.
@dato dato added the alu_repos label Oct 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants