Project management

We will likely have to produce very meticulous summaries of how we designed our product for regulatory purposes. We want to make it easy for ourselves at a later time to go back and see exactly how solutions were arrived at, on the basis of what requirements work was undertaken. The best way to do that is to track our work now and cross-link relevant information as much as possible.

How to use issue/tickets

• An issue (also referred to as ticket) is the main unit for tracking tasks and decisions. An issue is opened or closed from the issue interface. Project boards are only helper tools for having a "big picture" view. Follow the actual status of the issue in categorizing it.
• All tickets should have appropriate labels for categorizing them. Periodically check that the labels are appropriate.
• All tickets should be assigned to at least one project board. Some may straddle a few domains and thus be assigned to multiple projects. Periodically check that they are assigned.
• Never delete tickets.
• Tickets should never be closed without a comment. If you are closing a ticket you must understand the technical details of the solution and explain them in your closing comment.
• A ticket should only be closed by someone who actually worked on solving that particular ticket, preferably whoever was assigned to that ticket. This means that engineering related tickets shall only be closed by engineers. Administrative or general-documentation tickets may be closed by whoever worked on updating the appropriate pages.
• We want PRs to trace back to tickets. Link PRs to the originating issue. If someone claims that the ticket was closed by a PR, they should identify which PR and link to it from the ticket.

How to use a project board

• Project boards are thematic, i.e. a project is related to the team that will use it or set of technical disciplines that it encompasses.
• Project are not milestones. New projects shall not be created for time-constrained milestones. The milestones feature is to be used for that purpose.
• Projects may be accessed and created in the Projects tab.
• New projects should use the Basic Kanban as the template.
• Change the column names to mirror other boards in the project, unless yours has to be designed differently.
• When creating columns in projects, do not automate anything with regard to PRs. PRs may be related to software, hardware, PCB, or anything else, i.e. issues that are already handled by different boards. They should not end up on the same board.

Project columns

The columns in our boards shall be used as follows:

1. Backlog - is automated to claim all new tickets. As such, new tickets are not prioritized for immediate work. No tickets marked with the PRIORITY label should be here. Any BLOCKED tickets should likely be here, unless they are PRIORITY.
2. Up next - these are tickets that are (moderately) prioritized to be worked on next. All previously closed but re-opened tickets are automated to end up here. PRIORITY tickets should be here and should be periodically brought up in meetings to encourage appropriate action.
3. In progress - any tickets actively worked on should be in this column. The column has no automation. If someone has begun working on an issue, the appropriate ticket should be manually moved here. If a ticket history has commits that reference this ticket, this is a sign that is being worked on. If a someone mentions working on a particular task in a meeting, there might be an affected ticket that needs to be moved here. People might be working on an issue that is not being tracked, in which case an issue might have to be created to track it.
4. Done - is automated to claim closed issues. Only closed tickets should be in this column. Do not move unclosed issues to this column. If an open issue ends up in this column, it should not be closed, but rather moved back to one of the other columns and brought to the attention of appropriate owners/stakeholders.