All your code must be hosted in GitHub. You should follow our coding standards.
You should follow the philosophy of “commit early and often”. I will be evaluating your team in part by the representation of development shown in the commit history.
Your commit messages must be informative and useful. I will be reading them to better understand how you developed the system.
Consider the following hypothetical situation where two teams both implement everything but the “expiration date” functionality. Team A starts work on the system Friday evening and makes several commits, then makes significant progress on Saturday with more commits throughout the day, and finally finishes on Sunday early afternoon. By looking at the commit history, it is clear that both members of Team A have made significant contributions to the code. In contrast, Team B has no commits until early Sunday but works frantically right up until 5:00pm. Furthermore, 90% of the commits are made by only one person on Team B.
In this situation, Team A would get more credit for the system because they have employed a higher quality software engineering process (i.e. they did not wait until the last minute to begin). In addition, different amounts of credit would be given to the two team B members due to the fact that the commit history indicates that one member did the lion’s share of the work.
Your system should include a well-written README.md file (published using GitHub pages) that provides an explanation of how to install and use the system. It should not duplicate the information provided in the Help page of the running app.
You might find it useful to meet with your team immediately and start defining tasks according to our Issue Driven Project Management technique.
You should plan for three milestones. Each milestone should result in a “releasable” version of the system.
You should create a private Slack channel to support communication among your team members.
GitHub issues must provide a complete representation of how the work was divided up, when various components of the system were implemented, and who was primarily responsible. You must use HuBoard to manage the workflow of issues.
A team could implement a complete functioning version of the system, but if the process by which the system was created is not documented at all (or poorly documented) through GitHub issues, then the team will receive only 50% credit.