We try to keep the number of tools we use to a minimum for simplicity and ease of on-boarding. The new features of Github make it possible to keep most of the project management next to the code, and this is our approach:
Reference a specific task and keep track of its status.
Reference a long term project or goal.
Are used to group issues into time controlled sprints.
We also have a very comprehensive set of labels that can be automatically added to a repo using Kathari. It's important that all issues and pull requests have a priority, status, and type, and that they keep track of who is working and who is reviewing, if anyone.
duplicate 2️⃣ - Is a duplicate.
starter 🍼 - Good for new contributors.
Critical 🔥 - Mission critical.
High - Top of to-do list.
Low - Bottom of to-do list.
Medium - Somewhere in the middle of to-do list.
Abandoned - The assigned contributor gave up.
Available - Open for anyone to work on.
Blocked - Blocked by another issue.
In Progress - Someone is already working on it.
On Hold - Purposely paused.
Proposal - Don't work on it until accepted.
Review Needed - Pending reviews.
Bug 🐛 - Bugs.
Documentation 📚 - Documentation work.
Enhancement ✨ - Enhancements.
Maintenance 🚧 - Chores.
Question ❔ - Queries about the project.
The lifecycle of a task goes like this:
An issue is raised with the description of what needs to be done.
Discussion takes place and someone is assigned to the issue.
The issue is added to a project and/or milestone, if applicable.
The assignee branches off
develop to work and submits a pull request when ready.
Our CI/CD process lints, formats, and tests the code.
The pull request is merged after all the changes are reviewed and accepted, and any requested changes are made.