This repository has been archived by the owner on Apr 24, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 120
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
New member projects design document template (#595)
* Create new_member_project.md * Combine requirements and proposed solution sections I simplified the requirements section and turned it into the proposed solution section. This should make it easier to write the document. I also improved the wording of the Questions/Research section. * Schedule now follows subtasks instead of weeks Also fixed some typos
- Loading branch information
Showing
1 changed file
with
77 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,77 @@ | ||
# Project Title | ||
|
||
*Issue #Number* | ||
(What GitHub issue is associated with this project) | ||
|
||
**Author:** | ||
- Insert Name(s) here | ||
|
||
## The Problem | ||
|
||
What is the problem you are trying to solve? Why is it important to solve this problem? | ||
What is the end goal of this project? This section should similar to the body of the GitHub | ||
issue but include more details about it. This will be a qualitative description of the | ||
project. Use as many details you can to describe the requirements of the project. | ||
*(This is similar to the Motivation section of the other design documents.)* | ||
|
||
## Proposed Solution | ||
|
||
- How are you going to solve this problem? | ||
- What are the steps you need to take to complete the project? | ||
- Break down the problem above into smaller, individual components with specific metrics of success | ||
- You can think of this section as a quantitative description of the project | ||
- Each bullet should represent a single action | ||
- Use sub-bullets to provide more details and justifications for each step | ||
- *(Replace these bullet points with your own)* | ||
|
||
_It's OK if your approach changes later in the project as you learn more. Treat this like | ||
a road map that you can come back to to figure out what to work on next. If you aren't sure about the | ||
technical details, make sure your ideas are clear. It's also OK to come up with a couple solutions | ||
and decide which to pursue later. There should be some justification with your solution (i.e. how | ||
does each step address part of the problem above)._ | ||
|
||
## Questions & Research | ||
|
||
Are there things you are unsure about or don't know? What do you need to research to be able to | ||
complete this project? If you need information from the mechanical or electrical subteams, | ||
be sure to describe that here. If your solution requires more research to implement, descibe | ||
what kind of topics you need look at. Link any research papers/articles that you find here. | ||
|
||
**Of course, if you have _any_ questions or concerns, feel free to bring them up at any time. | ||
If you ever feel lost or don't know what to do or work on, Oswin or any old software member | ||
can help you out. You are not expected to know every technical detail about the project. Expressing | ||
what you don't know will make it easier to do research and ask for help.** | ||
|
||
## Overall Scope | ||
|
||
### Affected Packages | ||
|
||
- What parts of the software will you have to change (if any)? | ||
- Which packages are relevant to the success of the project? | ||
- Your first step of the project should be reviewing the relevant packages and code | ||
|
||
### Responsibilities | ||
|
||
- If you have more than one person working on this project, what will each person do? | ||
- My Name: one of actions described in the solution | ||
- *(Remove this section if you are doing this alone.)* | ||
|
||
### Schedule | ||
|
||
Subtask 1 (Date): How long will each step of the solution take? | ||
|
||
Subtask 2 (Date): Refer back to the bullets you made in the solution section | ||
|
||
Subtask 3 (Date): This will be used as a rough guide for keeping track of your progress, | ||
but it's ok if you fall behind schedule. | ||
|
||
Subtask 4 (Date): Remember, with 2 meetings per week, you can expect to have 5 to 6 hours to work | ||
on your project during meetings. If you want to work outside of meetings, you're free to, but | ||
keep that in mind when planning out your goals. | ||
|
||
*(Your project may have more or less subtasks than this)* | ||
|
||
Code Review (Date): Include an estimate for when your code/result will be ready to review | ||
|
||
*(School work will change over the semester and software often takes longer than you expect to write, | ||
so don't worry if you fall behind. Just be sure to update this document with your progress.)* |