Cómo lidiar con el estudiante que pone su trabajo (en casa) en github

Asigne tareas a los estudiantes en las que su trabajo deba abordar uno de sus intereses personales. Por ejemplo, en lugar de que cada estudiante programe la máquina para hacer pizza, haga que cada estudiante programe una máquina para hacer su comida favorita. Esto hará que las trampas de copiar y pegar sean más difíciles. También hará que los estudiantes se interesen más y que sus calificaciones sean más interesantes.

Creo que su punto 1 está fundamentalmente en desacuerdo con la prevención de compartir/copiar la tarea. Si alguien puede mostrar su trabajo, puede mostrárselo a sus compañeros de estudios. Sus puntos 2 y 3 sugieren que desea reutilizar la misma tarea una y otra vez cuando vuelva a enseñar la clase, lo que hace que este conflicto sea aún más inevitable. No hay forma de permitir que los estudiantes compartan su trabajo públicamente con cualquiera que quiera contratarlos, y al mismo tiempo mantenerlo en secreto para sus compañeros de estudios.

No hay nada que puedas hacer para mantener oculto para siempre todo lo que hace un estudiante en tu clase. Creo que la mejor solución es pedirles a los estudiantes que mantengan su trabajo en privado durante la clase (usando una cuenta de Github edu, Bitbucket, un repositorio local de git, lo que sea), y luego dejar que hagan lo que quieran más tarde. Eso significa que tendrás que hacer nuevas asignaciones cada vez que enseñes la clase, pero creo que es una buena práctica de todos modos.

Hay muchas cosas que equilibrar aquí, y la "mejor" solución es algo subjetiva.

Sin embargo, en mi opinión, el beneficio educativo de permitir que los estudiantes aprendan el control de versiones temprano supera con creces el mayor riesgo de exponer su código a otros que harían trampa. Si sus estudiantes planean continuar trabajando como programadores en la industria, ser experto en control de versiones es casi tan valioso como ser experto en codificación. La programación no es una tarea solitaria en estos días, después de todo.

Otra cosa a considerar: en mi universidad de pregrado, no había una política en todo el departamento sobre el control de versiones públicas (y no recuerdo que ningún profesor tuviera tal política). Sin embargo, recuerdo haber escuchado que se sugería que publicar código en un GitHub público violaba la política general contra el plagio. Este tipo de ambigüedad es mala para todos. Independientemente de lo que decida que es el camino correcto a seguir, le recomendaría que establezca sus expectativas explícitamente con respecto al control de versiones públicas.

Parece que un punto que falta en esta discusión es que, al menos en EE. UU., los estudiantes poseen los derechos de autor de su trabajo (no trivial). Como titulares de derechos de autor, pueden reproducir, distribuir y exhibir sus obras. Por supuesto, también pueden crear obras derivadas. Así que la restricción de los derechos de los estudiantes puede que ni siquiera sea legal.

Puede probar la detección automática de plagio, como MOSS desarrollado por Stanford. Detecta similitudes entre archivos de código, independientemente de cómo se nombren las variables, el orden de ejecución, etc. Luego, un humano podría observar manualmente las similitudes y juzgar si se trata de un caso de plagio. Además, según recuerdo, MOSS permite la entrada de código base compartido, lo que significa que el "código de inicio" proporcionado a todos los estudiantes no contaría para la similitud.

Mi enfoque en las tareas de programación se ha movido a hacer que los estudiantes copien todo lo que quieran de todos los repositorios de GitHub en el mundo, pero para hacer referencia a ellos en un informe sobre el proceso mediante el cual resolvieron el problema, escrito en oraciones completas. Esto es visto como un castigo cruel e inusual por parte de los estudiantes de primer año, pero cuando los exalumnos se encuentran conmigo en la ciudad después de la graduación, eso es lo que me agradecen, que les enseñé a escribir informes. Y que sus reportajes sean una gran referencia para ellos mismos.

No podemos vigilar este comportamiento, así que tenemos que tratar de educar a la gente. Les enseñamos a valorar el trabajo de otras personas citándolo o dando crédito, e insistimos en que reflexionen sobre lo que hicieron. Así que está bien decir: obtuve este código de Nancy, y luego le pregunté a Steve cómo poner widgets en esto, y como resultado finalmente logré que esto funcionara. Eso me facilita juzgar cuál es la contribución del estudiante.

Es más trabajo para mí, así que hice que los estudiantes hicieran programación en parejas, asignándoles parejas al azar cada semana. Ese es un buen ejercicio para ellos también, y llegan a conocerse mejor.

Ignoralo.

Es una tarea y no un examen. Los estudiantes que simplemente lo usan sin entenderlo corren el riesgo de reprobar el examen y ese es su problema, no el tuyo. Todos son adultos y necesitan decidir por sí mismos si quieren aprender algo o simplemente copiar algo.

Como los deberes no suelen influir en la nota final sino solo en la admisión al examen, no vale la pena intentar impedirlo.

Y github es una cosa, pero los estudiantes tienen servidores de archivos internos y wikis y otras formas de organizar cómo intercambiar la tarea actual o incluso un conjunto completo de tareas del año pasado.

Asegúrese de que todo lo que obtenga una calificación realmente relevante no se haga sin supervisión y esté un poco más relajado con la tarea que solo debería ayudar a los estudiantes a aprender y no se usa para documentar su habilidad como un examen calificado.

Si realmente ve que el código se copia entre dos estudiantes, es posible que no lo acepte. Pero esto debe hacerse comparando sus soluciones, no monitoreando github. Pueden copiar en privado o pueden haber trabajado juntos y debe decidirlo en función de la presentación de su trabajo.

Cuando realmente puedan reutilizar el código del año anterior, puede considerar cambiar las asignaciones de manera que el código no se pueda usar sin al menos entenderlo.

La solución óptima es acompañar la calificación automática del código con una revisión del código cara a cara humana, donde los estudiantes deben explicarle su código, y también puede pedirles que realicen cambios menores en línea para verificar que saben lo que saben. hizo. Si hace esto, no tiene que preocuparse por copiar, ya que la revisión del código le dirá qué tan bien conocen el material.

El problema es que esta solución requiere mucho trabajo, al menos 15 minutos por estudiante por semana. No tengo suficiente presupuesto para esto, así que utilizo una solución subóptima: hago que las tareas semanales sean solo el 10%-20% de la calificación final, de modo que el incentivo para copiar sea mínimo. Mientras tanto, me aseguro de que el examen final contenga preguntas que sean muy similares a las tareas. Así, los alumnos que hayan hecho los deberes por sí mismos tendrán una nota más alta en el examen final que los fotocopiadores.