You should continue working on your implementation this week. Part of your work this week will be making sure that other developers can build and test your project.
As always, you will submit a revision of your project report, incorporating all feedback you have received so far.
Commit, to the week7 directory,
a single PDF named
report.pdf. Submit the same
document via Canvas.
You should continue making progress on your implementation, working in your repository. As you make changes to the project, make sure that they are documented in the user manual.
There are two (related) milestones that you should reach this week: your project should be buildable and your project should be tested using continuous integration.
Any developer who happens upon your repository should be able to clone the repository and build your project on their machine (given some preconditions, all of which must be clear). In particular, your repository must contain reproducible instructions on how to clone the source, what dependencies or requirements are necessary, and how to invoke the build system. These instructions must be easily discoverable (they may be part of your user manual).
You must set up continuous integration for your project — whenever a change is merged into the master branch of your repository, the project should be built and tested. We suggest using Travis CI to automate this process, since it is free for open-source projects, is tightly integrated into GitHub, and is familiar to the course staff. You may also use a different tool if you prefer it. Regardless of the CI tooling you use, your build history must be visible to the course staff, and must include at least one passing build and at least one failing build. A good way to meet this requirement is to write a test that fails, commit it to your repository, and then fix the bug that caused it to fail.
Include a section at the end of the report, title "Feedback", describing any feedback you did NOT take action on, with a brief justification for why (for example, if the staff suggested some other project was related to your proposal, but it is not, this is where you should inform the staff why it is not related). Include ALL feedback you have received on the project at any point, whether from the staff or from your peers. Or, if you have addressed every piece of feedback and made changes in response, write "We have addressed all feedback." You will update this section every week; once an item appears here once, it need not appear again.
Be prepared to demo your initial implementation during your TA meeting this week and each subsequent week.
As usual, your team will act as another team's customer.
Peer review rubric