Final Project Checkpoint Guide

Due Date: Thursday, May 23

The checkpoint for your final project will be worth 10% of your group project grade. By the time of this checkpoint, we will expect your team to have finished some of your core implementation. Remember that for the final submission, we expect to see a thorough set of new unit tests accompanying your code changes, so make sure to also save a good amount of time to work on unit testing.

Please make a comment under the Github issue for your project proposal with the following headers:

  • Progress Report
  • Challenges
  • Design Document

Basic Progress Check (1 pt)

We will be inspecting the history of pull requests in your group’s repository to examine the implementation process, as well as to check if your team has been following the workflow we introduced in class (particularly code reviews). If your team have been struggling with meeting your set targets due to some unforeseen challenges, technical or otherwise, please meet with the course staff and we would be happy to help. Aside from this basic progress check, you should have a comment in the Github issue with the following 3 headers.

I. Progress Report (5 pts)

This progress report is different from what you did for your individual projects. We would like to see in this report a breakdown of how your team has been incrementally developing your feature.

Write your progress report as a comment under your proposal GitHub issue. The following sections are required:

A brief description of how far you are into the implementation. A checklist of all the small feature milestones that the group has finished, and which ones remain. For each of the milestones, please link the corresponding pull requests that contributed to it. You can link pull requests that have already been reviewed and merged, or draft pull requests for milestones that are still being worked on. E.g.,

  • Created basic status bar to show Git status. (#3, #6)
  • Added menu buttons. (#4)
  • Created basic API wrappers for git-add, git-commit, and git-push. (#5, #7, #10)
  • Created basic dialog windows for git-add, git-commit, and git-push. (#8, #9)
  • Implement color highlighting based on git diff in the editor.
  • Implement git-checkout support. (WIP #11)
  • …
  • Unit tests.

Linking pull requests (Image: linking to a pull request in GitHub markdown.)

This is how you can create checkboxes in GitHub markdown:

- [x] Completed item 1.
- [x] Completed item 2.
- [ ] TODO 1.
- [ ] TODO 2.

II. Challenges

It is perfectly normal in large projects like this for unforeseen difficulties to arise during implementation. If your team has encountered any particular difficulties, please document each one in this section, and elaborate on how you solved them, as well as how it impacted your project (if the expectations in your original proposal would need to be adjusted as a result.)

III. Design Document

Describe how you plan to approach the remaining milestones listed in the first section. Do not forget to allocate some time and resources for adding unit tests.

Since this project is not assigned by the course staff, we expect a detailed and comprehensive design document at the end.

Of course, as the project is still ongoing, this will only be an initial draft of the design that will continue to evolve as you keep working towards the final product.

You should include the following in your design documents:

  1. What your project does (which may have changed from your original proposal).
  2. What your project looks like (you might have already implemented some UI components).
  3. How you implemented your project. Feel free to make liberal use of diagrams here. Unlike the individual projects, this time the course staff have no idea how your project proposals should be implemented, so please be as detailed as you can (but stay at a high level).