+
Please respect the following rules:
- Remain polite, courteous, respectful and constructive
throughout the correction process. The well-being of the community
depends on it.
- Identify with the person (or the group) graded the eventual
dysfunctions of the work. Take the time to discuss
and debate the problems you have identified.
- You must consider that there might be some difference in how your
peers might have understood the project's instructions and the
scope of its functionalities. Always keep an open mind and grade
him/her as honestly as possible. The pedagogy is valid only and
only if peer-evaluation is conducted seriously.
+
+
- Only grade the work that is in the student or group's
GiT repository.
- Double-check that the GiT repository belongs to the student
or the group. Ensure that the work is for the relevant project
and also check that "git clone" is used in an empty folder.
- Check carefully that no malicious aliases was used to fool you
and make you evaluate something other than the content of the
official repository.
- To avoid any surprises, carefully check that both the correcting
and the corrected students have reviewed the possible scripts used
to facilitate the grading.
- If the correcting student has not completed that particular
project yet, it is mandatory for this student to read the
entire subject prior to starting the defence.
- Use the flags available on this scale to signal an empty repository,
non-functioning program, a norm error, cheating etc. In these cases,
the grading is over and the final grade is 0 (or -42 in case of
cheating). However, with the exception of cheating, you are
encouraged to continue to discuss your work (even if you have not
finished it) in order to identify any issues that may have caused
this failure and avoid repeating the same mistake in the future.
+
+
For the smooth running of this evaluation, please respect the following rules:
- Remain polite, kind, respectful and constructive whatever happens during
this conversation. It's a matter of confidence between you and the
42 community.
- Highlight the potential problems you ‘ve had with the work you're presented
to the person or the group you're grading, and take the time to talk about
and discuss those issues.
- Accept the fact that the exam subject or required functions might lead
to different interpretations. Listen to your discussion partner's
perspective with an open mind (are they right or wrong ?) and grade them as
fairly as possible.
42's teaching methods can make sense only if peer-evaluation is
taken seriously.
+
+
- You must only evaluate what you will find in the student's or group's
GiT repository.
- Take the time to check that the GiT repository matches the student or
group and the project.
- Double check that no malicious alias was used to mislead you and make you
grade something different from the official repository content.
- If a script supposed to help evaluate the exam is supplied by either side, the
other side will have to strictly check it to avoid nasty surprises.
- If the evaluating student has not yet taken this project, they will have to
read the exam subject in its entirety before starting the evaluation.
- Use the flags available on this grading system to signal an empty or non-
funcional project, a norm flaw, cheating, etc. In that case, evaluation stops
and final grade is 0 (or -42 if it's a cheating problem). However, if it's
not a cheating problem, you are invited to keep talking about the work that
has been done (or not done, as a matter of fact) in order to identify the
issues that lead to this stalemate and avoid it next time.
+