47 lines
2.4 KiB
Markdown
47 lines
2.4 KiB
Markdown
|
### Project Regrade Requests
|
|||
|
|
#### CSCI 3081W Staff Fall 2017
|
|||
|
|
|
|||
|
|
The window for regrade requests is **__10 calendar days__** after grades are released in
|
|||
|
|
moodle (i.e. weekends count). To be considered, you must submit a formal request
|
|||
|
|
based on the feedback file provided with specific examples, as outlined below.
|
|||
|
|
Requests in the form of "Please regrade my project, I think you made a mistake
|
|||
|
|
or graded me unfairly," will not be considered.
|
|||
|
|
|
|||
|
|
- All regrade requests must be submitted in writing to
|
|||
|
|
csci3081f17-help@umn.edu. Do not contact individual TAs or Prof. Larson with
|
|||
|
|
regrade requests – they will be ignored.
|
|||
|
|
- Please include _Regrade Request_ in the subject line.
|
|||
|
|
- Please include a link to the home directory of your repo.
|
|||
|
|
or to the specific directory of the code/documentation in consideration.
|
|||
|
|
- Please include code files indicating the line numbers, screenshots, or some
|
|||
|
|
other form of documentation.
|
|||
|
|
|
|||
|
|
Once we have regraded an assignment/project iteration, **we will not accept
|
|||
|
|
additional regrade requests for that grade item**, and the updated grade will be
|
|||
|
|
final. Please include ALL requests at one time.
|
|||
|
|
|
|||
|
|
When regrading any item, there is NO guarantee that your grade will go up. It
|
|||
|
|
may go down if we find other issues we initially overlooked.
|
|||
|
|
|
|||
|
|
### Presenting Work for a Regrade
|
|||
|
|
|
|||
|
|
Requests in the form of "Please regrade my project, I think you made a mistake
|
|||
|
|
or graded me unfairly," will not be considered.
|
|||
|
|
|
|||
|
|
Please include with the request the specific item on the feedback that you think
|
|||
|
|
was graded incorrectly, along with specific information about why you think it
|
|||
|
|
was graded incorrectly. This might include a screenshot, a file with indicated
|
|||
|
|
line numbers, or directions on how to run the code to see exactly the functionality
|
|||
|
|
in question.
|
|||
|
|
|
|||
|
|
_Example 1_: I did not receive any points for X because my code did Y, but that
|
|||
|
|
was only under Z circumstances, and as you can see in the attached screenshots,
|
|||
|
|
it performs correctly in the majority of cases, so I do not think I should lose
|
|||
|
|
all the points for this item. And here is the link to my repo: W.
|
|||
|
|
|
|||
|
|
_Example 2_: I did not receive any points for X functionality, however that is
|
|||
|
|
implemented in my code. **__Go to the attached file Y.cc and look at lines ##-##__** to see the corresponding code. And here is the link to my repo: Z.
|
|||
|
|
|
|||
|
|
_Example 3_: I did not receive any points for documentation of X – perhaps you did
|
|||
|
|
not see it in the docs folder. It is titled Y: here is the link to the file in my repo.
|