Task Tracking & Lifecycle
Our methodology for keeping track of development work.
We try to keep the number of tools we use to a minimum for simplicity and ease of onboarding. The new features of Github make it possible to keep most of the project management next to the code, and this is our approach:
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:
- 1.An issue is raised with the description of what needs to be done.
- 2.Discussion takes place and someone is assigned to the issue.
- 3.The issue is added to a project and/or milestone, if applicable.
- 4.The assignee branches off
developto work and submits a pull request when ready.
- 5.Our CI/CD process lints, formats, and tests the code.
- 6.The pull request is merged after all the changes are reviewed and accepted, and any requested changes are made.