Skip to content
This repository has been archived by the owner on Apr 24, 2023. It is now read-only.

Commit

Permalink
New member projects design document template (#595)
Browse files Browse the repository at this point in the history
* 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
Dallas-D authored Nov 17, 2019
1 parent a94ac01 commit caccb64
Showing 1 changed file with 77 additions and 0 deletions.
77 changes: 77 additions & 0 deletions documents/design/new_member_project.md
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.)*

0 comments on commit caccb64

Please sign in to comment.