Last updated on Friday, December 13, 2024

Unguided callback

This page describes the rules, submission, and grading for the unguided callback. See the write-up for a description of what the assignment is about and topic suggestions.

This callback counts towards your grade as explained in the course policies. You can start working on it at any time, but check the syllabus for the due date.

Process

0. Read the rules below.
1. Form a team of 2 to 4 people.
2. Write a one-paragraph specification and submit it to Moodle by the proposal deadline. The specification should consist of:
   • 2 or 3 sentences explaining what feature you plan to implement.
   • 1 sentence explaining which course concepts you plan to use or illustrate.
   • 1 sentence explaining the distribution of tasks among team members (all team members are expected to contribute equal effort to the final result).
3. Implement your specification.
4. Submit your code on Moodle as a Git bundle (see § Submitting your code below).
5. Complete a brief individual self-assessment on Moodle.
6. Register as a team on Moodle for a checkoff slot.
7. Receive a “checkoff” as a team from a staff member. This should take approximately 4 minutes + 1 minute per person in the team. Be prepared to:
   • Give a short live demo of your feature. (2–3 minutes by a single team member)
   • Walk the staff member through the code and tests that you wrote or modified, by showing them your Git history. (1 minute per team member)
   • Answer a few clarification questions.

Rules

• Each team member should have a clearly distinct task and should fully be in charge of their part of the code.
• Don’t cheat—it’s okay to discuss ideas with classmates, but don’t share code or discuss implementation details except with your teammates.
• Don’t host your code in a public repository. Host it in a private repository on gitlab.epfl.ch configured such that only your team members have access.
• You may use AI coding assistants, but be sure that you can explain the code during the checkoff, and remember that you won’t have access to AI on the final exam.
• Similarly, you may consult resources such as textbooks or reference websites, but you must cite them and be able to explain any code or ideas you took from them.

Topic choice

You can pick any topic for your unguided callback, but:

• Your callback must be based off of one of the team members’ solutions for a previously completed lab.
• Your callback should be of the right scope: aim for approximately 30–45 minutes per person for the code + 20 minutes per person for the tests. We expect larger teams to achieve more than smaller teams.

Grading

The unguided callback is graded out of 10 points, based on the checkoff:

• Proposal quality
  • Clear, unambiguous, and well written: 1 point
  • Unclear, ambiguous, or poorly written: 0 points
• Proposal scope
  • Appropriately scoped: 1 point
  • Too ambitious or too simple: 0 points
• Correctness and completeness
  • Working demo with reasonable features and few or no bugs: 2 points
  • Mostly working demo with some bugs or some missing features: 1 point
  • Code submitted to Moodle is rejected by the grader, demo has severe bugs, or feature is trivial: 0 points
• Code quality
  • Clean, simple, functional code: 1 point
  • Overly complex, poorly organized, or overly stateful code: 0 points
• Documentation
  • Documentation and relevant require-ensuring annotations on each new function: 1 point
  • Missing documentation or pre-/postconditions: 0 points
• Git history
  • Clean commits with detailed descriptions of changes, in a private repository: 2 points
  • Clean commits without descriptions, in a private repository: 1 point
  • Sloppy history, no Git history, or repository left public: 0 points
• Tests
  • Mostly complete: 2 points
  • Incomplete: 1 point
  • Not present or not compiling: 0 points

Prior to receiving a checkoff, each team member must fill an individual self-assessment questionnaire on Moodle. This helps us detect grading discrepancies, and it helps you reflect on your performance. Submitting a self-assessment is mandatory, but your answers will not affect your grade.

Scores are individual, per EPFL policy. We may adjust scores based on a review of overall grading patterns. The staff member giving you your checkoff may ask for a score review in corner cases.

The unguided callback is worth 10% of the overall unguided assignment score. (The other 90% comes from the unguided lab. Together, the unguided lab and callback make up 20% of the overall lab score. This is also explained in the course policies.)

If you are not satisfied with your score, you may challenge it. To do so, make a private post on Ed, and explain where you disagree from the original score. Include instructions on how to run the demo. A TA (PhD student) or professor will compile your code on their own machine based on your Moodle submission and decide on a new score. This score may end up being lower than the original one.

Submitting your code

Submission is on Moodle, as usual. However, to preserve your Git history, you will submit your work as a Git bundle: a single-file copy of a repository. Use the following command to create submission.bundle:

$ git bundle create submission.bundle --all

The auto-grader on Moodle will just check your bundle and run your tests; the score that it returns is not used directly. If the code you submitted to Moodle doesn’t compile, you will get a 0 in the “Correctness and completeness” section in the rubric above.

Preparing for the checkoff

As a reminder, the unguided callback is graded by a checkoff with a staff member. Checkoffs will happen in selected help session rooms on Fri, Nov 8 and Tue, Nov 12. The callback itself is due Fri, Nov 1. Here is how the checkoff will work:

Before your checkoff

• Register (as a team: no need to register individually!) and fill in your self-assessments (individually!) on Moodle: If you come without a registration, or without all self-assessments completed, you won’t be able to get a checkoff.

• Rehearse: The checkoff is very short, and we will unceremoniously cut you off if you run over. Review the grading scheme and the description of the checkoff to know what is expected of you and exactly how long you have for each part.

On the day of your checkoff

1. Arrive early: Try to be there 5 minutes ahead of your scheduled slot, to have time to prepare.

2. Be flexible: Although the registration slots on Moodle are 20 minutes long, we cannot promise that your checkoff will be done within those 20 minutes, but we will try our best. In the worst case, please be prepared to wait for up to 1 hour. (Please be nice to our checkoff staff: this is the first time we’re running a checkoff with this many students.)

3. Prepare your materials: Have the following ready on your computer.

   • Your demo, ready to run.
   • Your proposal.
   • A Git log with diffs for each student’s changes:
     git log –graph -‌-author=“Name” -‌-patch first_commit~..
     You can find first_commit by consulting the output of git log.

4. Wait for a staff member to come to you: We will move around the room.

5. Leave the room when done: This way staff members can easily identify who is waiting.

To comply with EPFL rules, your staff member will not be able to give you a score right away. We’ll post scores on Moodle within a week.

Example specification

Stepwise calculator

Spec: Implement a new function stepwise(e: Expr) that takes an expression and prints the result of evaluating e step by step (one reduction at a time, e.g. (7 + 1) * (4 - 2) → 8 * (4 - 2) → 8 * 2 → 16. Implement two versions and compare their efficiencies: one that works with Expr directly, and one that converts the expression to Polish notation, then repeatedly alternates between printing the expression and reducing the last operator of the expression.

Course concepts: Recursion, evaluation by substitution

Work distribution: V will implement the recursive version; C will implement the Polish-notation version.

© 2023, 2024 EPFL. All rights reserved.