The purpose of this document is to spell out the general workflow and procedures that shall be followed by software developers on the CS team (and microcontroller developers on the EE team). This workflow is a slimmed-down variation of the Agile workflow. We primarily use Github's issue tracking and pull request features to keep track of our work. All software tasks that need to be performed are created into issues on Github. Collectively these issues are a list of all work that needs to get done, is in progress, or completed. Issues are usually created by the team lead. The word “issue” and “task” are used interchangeably for the rest of this document. For git, we'll be using the rebase model as described in the “Git Policies” documentation.
Issues on github can be assigned to something called a “milestone” in github. When a task is first created, it typically will be added to the “Backlog” milestone on Github. When we write software, we will perform 1-3 week (TBD) “sprints”. Before the sprint begins, tasks are created or pulled from the backlog, and then assigned to developers. The goal is that all issues are completed by the end of the sprint, therefore we try to be realistic when decided what tasks will be in the sprint. Any tasks not completed by the end of the sprint typically are placed in the next sprint, but again, we try to make sure we never have any uncompleted tasks.
When you click on an issue in Github, you'll see a new window with more information about the issue. Here you can have an extended description of an issue, and people add comments to the issue so a discussion can occur about the task. These comments can reference specific lines of code on a specific commit (File Links), which is great for showing what you're talking about.
The team lead will be the head of all code reviews, but anybody can participate. The more people looking at the code, the more likely we are to discover bugs before we do a pool test. All code should undergo review before being integrated to the master branch. Exceptions are allowed at the discretion of the team lead for small, quick fixes where the overhead of a review is not necessary.
Issues can also be flagged with labels that we can use for filtering issues. One such label is “impeded”, which should get flagged if the primary developer is stuck for some reason and needs help.