-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
Veo diferentes casos:
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. |
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) |
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: |
1 Del lado de la implementación:
Preguntas que hace la implementación lado de la planilla:
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...
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. |
1
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, 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: 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. |
Se me ocurre una alternativa, vía ajustes en la UI y en la hoja Repos:
Manejo de la planilla:
|
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.
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.
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.
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.
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.
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.
The text was updated successfully, but these errors were encountered: