As announced last week, we have decided to move to GitHub Issues, making it easier for us to manage incoming bugs and features and removing the dissonance of having a completely separate issue tracker. The moving process is now complete and I wanted to take a moment to go into some more detail about our process, archived issues and our new tracker.
With a new tracker comes an improved process for incoming issues. Let me show you!
- A bug is filed, and has the state "Inbox".
- A maintainer periodically reviews and triages bugs. Bugs are typically triaged in one of 2 states: Closed, or Open (for HQ or community to help fix).
- Bugs marked with a "release" label will eventually be included in the specified release.
- A feature idea is filed, and has the state "Inbox".
- A team at HQ periodically reviews feature ideas. Ideas are triaged in one of 2 states: closed or open - both requiring feedback from HQ.
- When the feature idea is accepted it can go in one of 3 buckets: PR (a PR exists already), up for grabs or it into future planning sessions for HQ to work on.
- Any closed idea can be reopened for new evaluation should new details emerge
- Features marked with a "release" label will eventually be included in the specified release.
The ideas list
Umbraco CMS is a mature product with a large community around it, a community who comes up with awesome ideas all the time. We love it!
Unfortunately, there isn't always someone available to implement these great ideas we have. In order to not end up with an endless list of open issues, we'll close issues periodically and apply the "idea" label on them so we can easily find and reopen them at a later time as soon as either the community or HQ can work on them.
That way, good ideas don't get lost and the list of open issues does not become overwhelming.
The old issue tracker has been archived and we’re in the process of moving old issues over where needed. All the existing data is still available on the original URLs for easy reference, preserving existing links from (for example) forum posts, blogs posts, Umbraco source code, etc.
Apart from that, we have preserved a few of the more popular search options like searching only for resolved or open issues, searching by project and searching by tag. If it turns out that we have a need for more search options we’ll look into adding those as well. And as you will notice, I have absolutely no design skills, enjoy! 😉
Thank you for already embracing the new issue tracker! Within a few hours, Asbjørn added a new issue to the tracker, Marcel picked it up and sent a pull request to fix the reported bug. #H5YR to both of you!
We’re happy to hear that people actually enjoy creating issues, let’s face it, it’s not the most glamorous thing in the world to file an issue.
At Umbraco HQ we’ve also held our first feature review session to talk about new incoming feature requests and give some guidance on whether we think the feature is a good fit for Umbraco and how we envision it being implemented. One of the features discussed was to get right-to-left support into the Umbraco backoffice. If you can help, that would be awesome!
At Umbraco HQ we have 40+ repositories on which we are tracking issues. We had a labeling system in place for tracking these issues but we wanted to rethink it so it would work for all repositories including the open ones. We think we’ve found a good way that works for us.
The inspiration actually came from a tweet I saw flying by:
The blog post Katrina links to made a lot of sense for our needs, we want to be able to classify issues easily and we had plenty of labels that were of a certain “type”.
So today, we have a few types of labels:
✔️ Category. For example: translation, logging or UX.
✔️ Community. For community contributions, like a PR or “up for grabs”.
✔️ Project. To be able to group certain projects we’re working on, like Infinite Editing or Content Apps (make sure to watch this week’s Unicorner to learn more).
✔️ Release. To indicate in which release this issue will be included, this can be more than 1 release.
✔️ State. To track the progress in the issue on our Scrum board.
✔️ Status. Sometimes we need to get some feedback or we’re blocked, we can indicate the relevant status with this label.
✔️ Type. Issues are either considered to be a bug or a feature.
Against my OCD instincts, we’re keeping “good first issue” and “help wanted” available, even though they do not follow this structured approach. GitHub promotes these labels to new contributors and we really like that they’re highlighted when named that way.
GitHub offers a way for us to make a few issue templates available, this is a fantastic way for us to guide people who are creating new issues. Importantly, it also helps guide people to other resources like the forum or our email address to report security issues responsibly.
As you can see in the overview below, we welcome bug reports and feature requests. Support questions, documentation issues and security issues should be directed elsewhere. Clicking on each “Get started” button will give you more specific details.
- We’re looking forward to a new era of making issues flow through our new process and making sure all issues get the attention they deserve.
- We’re working on making sure that issues get migrated from the old tracker to the new where it makes sense.
- We’re excited that the community is just as excited as we are to start using GitHub Issues! 🎉