---
# System prepended metadata

title: Implementation Plan

---

# Implementation Plan

*Describe your plan for how to manage and prioritize the project that describes the APIs each team member plans to take primary and secondary responsibility for and a rough timeline of how the team will order the work to complete the program. Specifically, each person should take responsibility for specific features and use cases they intend to work on during each Sprint. This requires the team to agree on the feature priorities and set goals for what to complete at the end of each Sprint (i.e., each week).*

## API Assingments:

### Joshua

### Oliver

### Tinglong

### Jiyang

### Robert

### Liam


## Project Timeline

### Sprint 1 (Test) - April 8

### Sprint 2 (Basic) - April 15

### Sprint 3 (Complete) - April 25


## Git Lab issue Tracker:

**Bugs**:
If you encounter a bug send a message in the slack channel
but also 

**API Changes**:
If you want to request an API make an issue for it and assign
the people who would need to implement it for you. If there's
still confusions on the merit bring it up during the next meeting

## Branches
Two "main" branches. `backend` and `frontend`. 
People assigned to either branch will branch off of those and
create their own working branches called `<task-working-on>`
that is checkout out from either the backend or frontend 
(depending on which eam you're on). Not required but it may be
helpful to preappend the branches with something to help you keep
track. Maybe like `initials/fix-thing-blah`

The main advatage of having this is for code review. When a partner
finishes a task they can submit a merge request from their working branch
to (let's use backend branch for example) the backend branch. This will
let the other team memebers review it completely and make comments.
Then they can merge it into backend, This way frontend and backend
can consistently work and review each other separately from the other team!


Basically 2 things: Use the issue tracker and 