Sortie de MarkUs 0.10.0

Posté par (page perso) . Modéré par patrick_g. Licence CC by-sa
31
27
juin
2011
Éducation

MarkUs est une application Web destinée à simplifier la tâche de correction du code rendu par les étudiants dans le cadre de travaux pratiques ou projets d’informatique.

La version 0.10.0 est sortie il y a quelques jours. Nous en profitons pour faire découvrir cette application.

MarkUs confère la même facilité et souplesse de correction que l’on a avec un papier et un crayon. Il permet aussi aux responsables d’enseignement et aux étudiants de former des groupes de travail, et de travailler sur des projets en utilisant un système de gestion de version (en l’occurrence SVN) par ligne de commande, ou via l’application Web (qui permet d’ajouter, de remplacer, ou de supprimer des fichiers très simplement).

MarkUs est sous licence MIT. Il a été codé avec le framework Ruby on Rails, que l’on ne présente plus.

Vous pouvez l’essayer via la version en démonstration sur le site officiel.

Initié par Karen Reid, Senior Lecturer à l’Université de Toronto (Canada), le développement de MarkUs s’est appuyé sur la contribution d’étudiants qui ont, pour beaucoup, continué à participer au projet au‐delà de leur diplôme. Aujourd’hui, MarkUs est utilisé dans 3 universités canadiennes (depuis 2009) et dans une grande école française, l’École centrale de Nantes (depuis 2010). L’École Centrale de Nantes encadre des étudiants de la filière informatique pour aider au développement de MarkUs.

Dans le cadre des RMLL, deux soumissions de conférences ont été envoyées de la part de l’École Centrale de Nantes.

Liste non exhaustive des fonctionnalités de MarkUs :

  • possibilité d’annoter le code, les images et les documents PDF (dans la limite de 30 pages) soumis par les étudiants, via un simple navigateur Web ;
  • « versionnement » des documents déposés par les étudiants via SVN, en ligne de commande ou via l’interface Web ;
  • gestion automatisée et configurable (délai de grâce, pénalités, etc.) des travaux déposés hors‐délais par les étudiants ;
  • gestion des rôles : responsable d’enseignement / chargé de TD / étudiant ;
  • importation et exportation des utilisateurs via CSV, YAML ;
  • prise en charge de plusieurs séries de TP et / ou de projets (en général, il est recommandé d’utiliser une instance de MarkUs par matière).

Logo MarkUs

  • # Fonctionnement

    Posté par . Évalué à 4.

    Si je comprends bien les étudiants envoient gèrent projet via un dépôt subversion connecté à Markus et peuvent définir par l'interface web, que le projet est terminé (que le dernier commit est bien le dernier) ?

    En cas de retard les commits sont refusés où le professeur voit la version a évalué et la denière version en date ?

    En tout cas je souhaite longue vie à ce projet car c'est vraiment bien de pouvoir gérer les notes avec ça. Je comprends bien que le projet à aussi un caractère éducatif dans son développement, mais je pense que cela aurait put être développé au sein d'une forge déjà existante (finallement c'est une revue de code particulière). Dans le sens inverse, je pense qu'il serait intéressant que les projets puissent avoir un wiki qui servirais à la place des PDF à rendre. Je pense que ce serait plus souple.

    Un dernier point positif c'est le fait que ça oblige les étudiant à utiliser un gestionnaire de version (pas nécessairement subversion), je pense que l'ajout de fonctionnalités tels qu'un wiki et un forum (basique) permettrait d'habituer les étudiants à la communication technique textuelle, rendrait plus naturelle l'utilisation de forge.

    C'est typiquement je genre d'enseignement important et pas toujours dispensé en cours.

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Fonctionnement

      Posté par . Évalué à 1.

      C'est typiquement je genre d'enseignement important et pas toujours dispensé en cours.

      Un peu comme l'orthographe, quoi...

      OK, je -->[]

    • [^] # Re: Fonctionnement

      Posté par . Évalué à 2.

      Les soumissions des étudiants sont toujours acceptées. Cependant, les étudiants sont prévenus via un message lorsqu'ils soumettent du code "en retard" que la date butoir est passée, et que ce code ne sera peut être pas corrigé.

      Le projet est considéré comme terminé lorsque la date butoir est passée.

      Le professeur peut indiquer des règles pour gérer les retards des étudiants. Il existe trois règles possibles:

      • Ne rien faire: Markus accepte les soumissions, en prévenant l'étudiant que la date butoir est passée.
      • Utilisation de "Grace periods": l'étudiant possède des crédits pour rendre des devoirs en retard. Si l'utilisation de ces crédits est autorisée pour ce projet, l'étudiant ne sera pas pénalisé par la soumission de code en retard, mais perdra des crédits. Une fois les crédits épuisés, l'étudiant ne pourra plus soumettre de code en retard (le code est accepté par Markus, mais ne sera pas forcément corrigé)
      • Utilisation de période de pénalité: Markus retire des points par période de retard.
    • [^] # Re: Fonctionnement

      Posté par (page perso) . Évalué à 2.

      Si je comprends bien les étudiants envoient gèrent projet via un dépôt subversion connecté à Markus et peuvent définir par l'interface web, que le projet est terminé (que le dernier commit est bien le dernier) ?

      C'est exactement ça. Les étudiants envoient leurs fichiers via l'interface Web (ou directement en commitant sur le SVN). Derrière, le système de gestion de version est SVN. Il simplifie la gestion des fichiers et amène un début de réflexion sur le versionnement des fichiers. La gestion des conflits est simplifiée. On utilise pleinement SVN lorsque l'on n'utilise pas l'interface graphique

      En cas de retard les commits sont refusés où le professeur voit la version a évalué et la denière version en date ?

      Comme l'a dit Nelle, le fichiers seront toujours acceptés par MarkUs, jusqu'au rendu de la correction. Suivant les règles de retard, MarkUs affichera ou non cette version au correcteur. Cependant, il y a toujours des situations exceptionnelles et un correcteur peut choisir manuellement de corriger la dernière version mise en ligne, même si celle-ci a été mise après la date limite de rendu.

      Dans le sens inverse, je pense qu'il serait intéressant que les projets puissent avoir un wiki qui servirais à la place des PDF à rendre. Je pense que ce serait plus souple.
      L'idée du wiki est une excellente idée pour ajouter des commentaires à un projet. Je la note dans un coin :)

      Pour le PDF, c'est lié aux façons de gérer les TP de l'Université de Toronto et de l'École Centrale de Nantes. Les enseignants avaient pour habitude de demander un rapport en plus du code à la fin du TP. Nous avons souhaité ne pas changer leurs habitudes.

      Nous avons des retours positifs à la fois des étudiants et des chargés de TP/TD. Le gain de temps à la correction est important. De plus, les étudiants apprécient de retrouver leur code à un seul endroit, ce qui facilite leurs révisions.

  • # Numéro de version

    Posté par (page perso) . Évalué à 2.

    Le site du projet indique que la dernière version stable porte le numéro 0.10.0

  • # Annotation du code

    Posté par (page perso) . Évalué à 1.

    Ce qui serait vraiment génial (enfin, du moins pour le groupe d'assistants dans lequel je me trouve), c'est d'avoir la possibilité d'annoter le code source, en plus de lui attribuer une note. En utilisant le dépôt, on pourrait même voir les lignes qui avaient été annotées et qui ont été modifiées par les étudiants.

    • [^] # Re: Annotation du code

      Posté par . Évalué à 2.

      Markus a déjà la fonctionnalité d'annotation.

      L'outil permet d'attacher à une ou plusieurs lignes de code une remarque, de les superposer. Markus permet aussi d'enregistrer les remarques pour pouvoir les réutiliser sur un même projet, en les classant par catégories prédefinies et remplies par l'administrateur/la personne en charge du cours.

      L'étudiant peut regarder les annotations directement sur le code source, ou via une page bilan, indiquant l'annotation, le fichier annoté, et la ligne/les lignes concernée(s).

      Par contre, une fois le travail corrigé, les étudiants soumettent rarement une nouvelle version (sauf dans le cas de projet long terme, ou la possibilité de voir si les étudiants ont modifié les lignes annotées serait très intéressante).

      • [^] # Re: Annotation du code

        Posté par (page perso) . Évalué à 1.

        Ah, désolé j'ai testé la démo et je n'ai pas vu cette fonctionnalité. Merci de m'avoir fait découvrir ce projet, il semble vraiment prometteur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.