Each project grade is split into two components: functionality and code review. This guide details the process for verifying and grading the functionality of your projects. See the other project guides guides for other details.
Associated Assignments
Project 1 Functionality
Project 2 Functionality
Project 3 Functionality
Project 4 Functionality (Web Crawler Only)
The project verification process is required to earn the functionality grade for each project and prior to every code review. Only request project verification if all of the following are true:
Your project passes all of the project tests locally in Eclipse.
Your latest project release passes all of the project tests remotely on the lab computers. Do not request verification until you have completed this step; repeated requests for non-passing code will result in a point deduction to the functionality grade.
You do not have an open verification request issue on Github. If you have an open verification issue but want to verify a different release, edit the issue rather than close or delete it. You want to preserve the issue timestamp, which affects the order requests are processed.
You have already passed the functionality for the previous projects. For example, you may not request verification for project 3 until completing the functionality for project 2 and may not request verification for project 2 until completing functionality for project 1.
If all of the above is true, follow the steps below to request project verification.
To request project verification, create an issue on your Github project repository. See the Issues guide on Github for details.
Several issue templates have already been provided for you. Select the “Project Verification” template to get started.
Change the issue title to “Project [VERSION] Verification” where [VERSION] is the release you want verified. For example, “Project v1.0.0 Verification” for release v1.0.0 of Project 1.
Replace [FULLNAME] in the issue body with your full name. For example, “Sophie Engle”.
Replace [RELEASE] in the issue body with the release. For example, “v1.0.0”.
If you need your functionality grade updated, make sure to check the box next to “I need my functionality grade updated on Canvas” in the issue body. To do this, change the [ ] text to [x] instead. Your grade will not be updated unless this is selected!
Assign the issue to our TA Olivia (oliviakumar). This should happen automatically if you are using the correct issue template.
Label the issue with the verification label. This should happen automatically if you are using the correct issue template.
Label the issue with the appropriate project label. For example, add the “project 1” label for project 1 verification.
Add the issue to the appropriate project milestone. The milestones should be either “Project 1”, “Project 2”, “Project 3”, and “Project 4”. You will have to create the milestone if this is your first issue for the project.
Verify you have followed all of the necessary steps in the “Verification” section. To check a box, change the text [ ] to [x] instead. Do not create the issue unless you are able to check all of these boxes.
There is an example project verification issue in the project template repository:
If you make a mistake, please edit the issue. Do not delete the issue or close the issue and create a new one.
Your functionality grade will be based on the date you created the issue that passed verification. If the issue date is before the checkpoint deadline, you will earn 100% on the project functionality. If the issue date is after the checkpoint deadline, your grade will be deducted 10% (up to a maximum of 30%) per week.
The functionality deadline schedule is below (assume all deadlines are at 11:59pm): Updated
| Grade | Project 1 | Project 2 | Project 3 | Project 4 | Description |
|---|---|---|---|---|---|
| 105% | ≤ 02/19 | ≤ 03/12 | ≤ |
≤ |
Extra Credit*See Below |
| 100% | ≤ 02/26 | ≤ 03/19 | ≤ |
≤ |
Checkpoint |
| 90% | ≤ 03/05 | ≤ 03/26 | ≤ |
> 05/07 | 1 Week Late |
| 80% | ≤ 03/12 | ≤ 04/02 | ≤ |
2 Weeks Late | |
| 70% | ≤ 03/19 | ≤ |
3 Weeks Late | ||
| 0% | > 04/05 | > 04/05 | > 05/10 | Project Cutoff |
Keep in mind the project pass requirements for projects 1 and 2. All of your grades default to 0% if you do not pass the functionality of projects 1 and 2 by the project cutoff deadline on Friday, April 5, 2019. You must also pass the functionality of project 3 by the last day of the semester (before finals) on Friday, May 10, 2019.
The final project grade (for the entire category) will be capped at 115% at the end of the semester. For example, if you completed enough extra credit to earn a 125% in the project category by the end of the semester, your project grade will be capped to 115% instead.
Worried about the deadline schedule and how slow code reviews progress?
You can work ahead on the functionality of the next project after passing verification, just not in the master branch used for the current project and code reviews. If you want to work ahead, create a separate branch for the next project. You can even create releases from that branch, allowing you to pass functionality for the next project while still undergoing code review for the current project.
However, you have to be comfortable with branching and merging in git if you choose this route. It is very easy to cause merge conflicts that can be difficult to resolve, and we can only provide so much assistance.
You cannot work two projects ahead than the project currently under code review.
If your
master branch includes functionality for the next project, you'll be asked to remove it and reschedule the code review. This could cost you a week, and undo your efforts to work ahead!