Code review ideas

[bmesuere]

The following text was copied from the public wiki which will be phased out.

List of requirements for a bulk review feature (e.g. after test or exam) from first prototype. Please comment/complete. This may serve as a first steps toward prioritizing individual features and planning iterations for implementing a bulk review feature.

• code review to submission(s) for a single exercise/student
  • manually add an annotation about the entire code or to a selection of the code (single line/multiline, code range, set of code ranges)
  • specific types of annotations: strikethrough (e.g. for unnecessary parts of the code, or code sections that are completely wrong), linking multiple sections in the code (e.g. when code duplication is detected), moving code fragments to another location (e.g. when sequence of actions is in wrong order), ...
  • allow both student and course managers to make annotations on a submission (e.g. for students to ask a question about a specific point in the code)
  • student/course manager may respond to previous annotations (e.g. asking questions or giving clarifications)
  • annotations either linked to review (visibility dependent on release conditions of review) or independent of review (immediately visible for submitter)
  • expose or hide identity of reviewer to student (anonymous reviews); immaterialize automatic annotations (e.g. by linter) e.g. ask coming from the "rubber duck"
  • iterate over all submissions for a selected user and a selected exercise
  • reuse annotations made previously (as is or with slight modifications)
  • automatically hint that previously made annotations also apply to a submission
  • change-based reviews: map annotations from one submission to another submission for the same exercise of the same student (creates a trail where students (don't) act upon feedback
  • allow reviewers to submit updated versions of the code under review (e.g. to check if an update would work correctly) that are evaluated the same way as regular submissions, but are stored differently (e.g. not stored at all or stored as part of the review, not as a personal submission of the reviewer)
  • export/print reviewed code
• grading of submission(s) for a single exercise/student
  • global grade and subgrades (e.g. for individual functions/methods) as a numeric score
  • rubrics (see CodeGrade)
  • link grades as penalty to (common) mistakes encountered during review (see ans Delft = dynamic rubrics); what if there's a need to modify grades linked to mistakes down the road of the review process
  • automatically compute score(s) from #tests passed/failed
  • export/print graded code; transfer scores to learning platform via LTI
• bulk review
  • always linked to course; (optional?) deadline for submissions (might be taken over from series); optional release deadline; named reviews?
  • link selection of exercises (from course) to review (add/remove); what if exercise is removed from course?
  • link selection of users (from course) to review (add/remove); what if user unregisters from course?
  • create review from course or from specific series within course; the latter allows to attach the exercises from the series to the review by default (may be changed afterwards); by default all course users can be linked to the course; allow to automatically restrict to all users who have submitted at least one submission for at least one exercise in the review
  • bulk grade (zero score) where no submissions have been made for a particular exercise under review for a given student
  • iterate over all users linked to the review for a selected exercise; anonymised students, random order
  • iterate over all exercises linked to the review for a selected user
  • select one of the submissions for a selected exercise and a selected user (e.g. based on submission deadline set in review, manual selection)
  • release conditions: manual release, set release date, revoke release?
  • statistics about common mistakes across all reviews of an exercise, time invested in review, whether students have looked at the reviews and/or acted upon them
  • reuse common mistakes as tips & tricks for an exercise; distinction between exercise-specific mistakes and more global mistakes (e.g. linked to a programming language or well-known code smells); ontology of annotation types needed?; difference between annotations and tips & tricks might be that the latter might be internationalized, whereas there seems no use case to internationalize the former
  • iterate over all submissions linked to a particular (type of) mistake for a given exercise in the review
  • users must see an overview of all their annotations and get a notification if new annotations are available
  • course admins must see an overview of all reviews in the course, and for each review see an overview of its status
  • integration with plagiarism detection, so that review can manually inspect detections of possible plagiarism
• peer review
  • distribute review assignments over group of students (annotations and/or grading)

other review platforms for (student) code

• Gerrit Code Review
• Gradescope
• GradeWork
• Canvas
• Ans Delft
• CodeGrade

see also: link to GitHub@UGent

[IngeVerbeek]

Idee: bij het geven van feedback kan je wel op VOLGENDE klikken, maar soms was je te snel en wil je terug naar VORIGE. Dat kan momenteel niet.

[BTWS2]

@IngeVerbeek In zo'n gevallen zou vorige (⬅) in de browser ook moeten werken.

[IngeVerbeek]

Getest en inderdaad, het werkt.

[IngeVerbeek]

Idee: punten exporteren naar Skore (Smartschool) zou handig zijn.
Ook leerlingen indelen in klassen (eventueel automatisch via Smartschool) zou handig zijn bij het verbeteren.

[BTWS2]

@IngeVerbeek Het is waarschijnlijk niet 100% waarnaar je op zoek bent, maar heb je de labels geprobeerd voor het indelen van groepen? https://docs.dodona.be/nl/news/2018/12/04/_2-7-release-notes/#labels-voor-cursusgebruikers Labels die toegekend werden aan cursusgebruikers kunnen gebruikt worden bij het zoeken.

[IngeVerbeek]

Ik heb het zonet geprobeerd met die labels (ik had over het hoofd gezien dat je de labels zelf kon aanpassen). Alvast een handige feature, die ik vanaf nu zal gebruiken.
Het is inderdaad nog niet helemaal wat ik zoek (ihb punten exporteren naar Skore), maar wel ene eerste stap.

[bmesuere]

Dag @IngeVerbeek, rechtstreeks koppelen met smartschool zal waarschijnlijk niet voor direct zijn maar we kunnen eventueel wel kijken om het proces gemakkelijker te maken. Laat Skore toe om punten te importeren? Misschien kunnen we er voor zorgen dat de punten uit Dodona op zo'n manier kunnen geëxporteerd worden zodat je ze gemakkelijk in Smartschool kan inladen.

[IngeVerbeek]

Ik kan wel punten importeren vanuit BookWidgets (een programma waarin je digitale oefeningen kan opstellen, dit heeft niets met programmeren te maken), maar niet vanuit eigen bestanden. Er is wel een smartschool API, maar daar ken ik zelf niets van. https://www.smartschool.be/developers/
Het is natuurlijk geen noodzaak, punten overtypen kan ook. Maar voor leerkrachten zoals ik zou het wel tijdswinst kunnen betekenen :)

[IngeVerbeek]

Idee: in het statusoverzicht voor leerkrachten een optie zetten waarbij de leesactiviteiten uit het schema worden gehaald, waardoor alleen de oefeningen overblijven met ✔ of ❌. Dat maakt het schema overzichtelijker om leerlingen op te volgen.

[bmesuere]

Over welk statusoverzicht heb je het precies? Bij evaluaties worden leesactiviteiten normaal nooit meegenomen. Je mag eventueel de link van de pagina in kwestie mailen naar [email protected], dan nemen we een kijkje.

[pdawyndt]

@bmesuere Ik denk statusoverzicht van een reeks. Daarin zitten zowel de leesactiviteiten als de oefeningen. We kunnen daar al gebruikers uit filteren die niets ingediend hebben (geen leesactiviteiten als gelezen gemarkeerd en geen oplossingen ingediend voor oefeningen), maar hier is vraag denk ik om te filteren op kolommen (enkel oefeningen weergeven, geen leesactiviteiten).

Deze reeks heeft bv. twee leesactiviteiten (eerste twee kolommen) en drie oefeningen (laatste drie kolommen):

[IngeVerbeek]

Als ik naast een reeks op de drie puntjes klik en dan op "statusoverzicht" zie ik een raster met daarin een rij per gebruiker een een kolom per leesactiviteit/oefening. Daarin wordt een groen vinkje weergegeven als ze een oefening gemaakt hebben of een leesactiviteit gelezen, en een rood kruisje als de oefening fout is.

Ik gebruik dat om de evolutie van mijn leerlingen op te volgen tijdens de les en tussen de lessen door. Omdat ik een heleboel leesactiviteiten ertussen heb zitten (met uitleg voor de leerlingen, links naar de filmpjes met uitleg, ...) is dit overzicht erg groot en daardoor log en moeilijk te volgen. Mijn suggestie zou zijn om de leesactiviteiten te kunnen verbergen (met een aanklikbaar oogje of zo), zodat het overzicht wat compacter wordt en daardoor overzichtelijk.

Bij de evaluaties is dat inderdaad al het geval, maar die weg kan ik pas gebruiken nadat alle leerlingen hun oplossing hebben ingediend denk ik?

(Ik merk dat @pdawyndt ondertussen al met screenshots heeft aangegeven wat ik bedoel.)

[bmesuere]

Ik heb deze suggestie opgenomen in issue #3408