Project plan
To kick off your work on your term-long project, you are going to write a short project plan.
The preparation of this document is intended to help you organize your thoughts and your work. Yes, I want to read it, but I mainly want you to go through the process of putting it together. Assembling this kind of planning document is a great way to discover gaps in your understanding, potential pitfalls in scheduling your work, etc.
How to submit your plan
- Create a GitHub repository in one teammate's GitHub account. Name the repo something sensible that suits the naming conventions the repo's owner prefers. Make sure to make the repo public, with a README file and a .gitignore file. (I recommend using the .gitignore starter file corresponding to whatever programming language you expect to use as your main language for the project.)
- The owner of the project repo should add the other teammates as collaborators on the repo.
- Write your as a markdown document named
plan.md. - Put plan.md in a top-level folder named
doc. I'll ask for more documents in the future (e.g., a testing plan), so you'll want a place to put them. - Post a link to plan.md on Slack in #general.
What your document should include
- A short description of the project. I'm thinking 1-4 sentences, but whatever works for you.
- A short list of learning goals—what do you want to end up understanding that you don't understand yet?
- A list of feature goals. Organize these into three lists: essential features, nice-to-have features, and stretch goals.
- A description of your project's architecture. This could be just a diagram of your expected code organization, but it could also include things like the setup of a target server, the data you're going to need for testing, a build system (e.g., Makefile or something similar), etc.
- A rough schedule of development. What steps will you take, in what approximate order, to complete your project. For this, think about which pieces of the project can be done in parallel, and how work might be allocated between team members.
- A list of things one or more of you are worried about. This could be stuff you don't understand yet, things you think might take too long, etc.
- A brief explanation of how you're going to communicate with one another and when you're going to meet to work together.
- A brief explanation of how you're going to ensure that all team members contribute substantially to the end product. (It is shockingly easy for one team member to ride the wave of the rest of the team's work, and end up with no contributions to show for themselves, and even less understanding of the project as a whole. Let's make sure this doesn't happen.)