Project Management Guide
Work is currently tracked in the following Github Project : https://github.com/orgs/RolnickLab/projects/8
Github Milestones in this project are used like epics and user-stories are used in Jira.
They represent groups of related issues that aim to solve a specific problem in a given time frame.
A Milestone in this project can be use to represent the following:
- Related group of issues around a specific theme/problem
- Improve performance of database queries
- A parent task for issues that implement a larger functionality or body of work
- Implement auto-deploy mechanism of new models
- An end goal from a user perspective
- Allow users to add datasets via new self-service module
All Milestones should have due dates. Milestones and their issues should always be part of ongoing or committed work efforts.
If you just want to group issues together or classify them, please consider using Labels instead.
We use sprints in this project simply to structure the work in a digestible way.
We strive for sprints that are achievable; it's better to complete a sprint and get a head start on the next one, than constantly dragging issues from sprint to sprint.
That being said, sprints are built on estimates, and estimates are not easy to get right.
- All Issues begin in the Issues list
- Add Backlog status if we want to address the ticket (can be tagged Backlog & prioritized at any time)
- Schedule in a Sprint when starting a sprint or planning ahead
- Assign person who needs to define the ticket
- Add "Ready to be picked up" tag
Once an issue is created and work is ready to start, you should either create the branch using the Create a branch option in the Development field, or manually link the branch to it's issue.
This is important in order to easily be able to track the work being done, especially when an issue is paused for a while and taken up by a different person later.
Issues represent a specific ideas, tasks or problems. They are the building blocks we use to keep track of what needs to be done in the project.
You are strongly encouraged to use the templates provided when creating new issues.
When creating a new issue:
- Fill the different sections of the issue template
- Fill the appropriate fields on the right side
- Assign the issue as soon as possible (when possible)
- Labels
- Projects
- Milestones
The labels field should be used whenever possible to help with the organisation of issues.
Labels can represent the kind of work required by an issue (new feature, bug, ect.), the platform components that are concerned (frontend, backend, infrastructure, etc.) or any other useful information or category (good first issue, needs elaboration, duplicate, etc.)
Please be mindful when creating new labels to avoid confusion or duplication with existing labels.
Labels are not limited to issues and can be used in Pull Requests and discussions too.
Link the issue to an appropriate Milestone, if applicable.
If you feel the need to add an issue to multiple milestones (which can't be done in Github anyway), your issue probably needs to be redefined or you are not using milestones appropriately (please see the Milestones section above).
The status of an issue should be updated accordingly. At the very least, when an issue is detailed enough, status should be set to Ready to be picked up.
Priority is a very important field and should always be set. Priority helps the team manage and select future issues to work on and allows the team to have more autonomy overall.
Priority should be in relation to how urgent an issue is in the context of current project goals.
Ex:
- An issue already committed to by the team and/or vital for a partner would be High priority.
- A feature that has been requested, but not a blocker for existing workflows would be Normal priority.
- A bug that prevents a core feature of the platform from working would be of Critical priority.
- A bug that is an annoyance or affects a only tiny part of the code base would be Low priority.
This is the first level of estimation and is required for all new issues. This estimate is a ball-park estimation and helps with initial scoping when planning sprints and milestones.
This should be filled after a preliminary analysis of the task has been done. Its usefulness is to help plan at the sprint level and help with timeline projections and project tracking.
The estimate should be in person-days and should include appropriate time for the applicable steps (analysis, implementation, tests, documentation, review and deployment).
An estimate that is larger than 6 person-days indicates that an issue might be too big and probably needs to be split into smaller issues. The bigger the estimate, the more likely the estimate is off.
Ex. a larger task split into 3 separate tasks:
- a first task that is purely analysis and exploration
- a second task that refactors existing code in preparation of the new feature
- a final task that implements the new feature itself
Estimates are NOT commitments and should be revised when needed (and as soon as needed); they are metrics to help us on one hand budget our capacity and on the other have a better idea of what we can achieve in a given span of time.