Wanted to find out what stages/labels we were currently using and how these can be better ported over to out github projects in a clean way, and a CONSISTENT way so that potential contributors know their way around our projects, and equally so do we :)
This started life as https://mofowebdev.etherpad.mozilla.org/github-webmaker-tags but after some lively debate think we the agreement was around this:
- popcorn.js - https://webmademovies.lighthouseapp.com/projects/63272/milestones/139943-14
- popcornmaker - https://webmademovies.lighthouseapp.com/projects/65733/milestones/167822-1013
- thimble - https://github.com/mozilla/webpagemaker/issues
- openbadger - https://github.com/mozilla/openbadger/issues
- openbadges - https://github.com/mozilla/openbadges/issues
After looking at the labels that we're currently using over a number of projects and sorting them into categories of label type (https://mofowebdev.etherpad.mozilla.org/possible-webmaker-tags) I did some thinking on how we can use what we have to make something that is easy to scan and easy to understand for people coming new into the projects.
One thing I found is that we didn't hold a whole lot of these (so have created some new ones) but these are what I think will bring in our contributors. From what I've seen in the #webdev and #www channels people will come in and say 'I want to fix front-end problems' or 'I like fixing accessibility bugs' so having a way that they can easily scan (and we can easily extract) these kind of bugs seems a good idea.
- good-first-bug (changed from the openbadges 'volunter on-ramp') as this is a mozilla standard
- ux
- visual-design
- content
- front-end
- back-end
- documentation
- localisation
- accessibility
- performance
It's crucial that when bugs come in we know they're valid and if there are further things needed in order to get them up and running. For the casual contributor it also seems nice to be able to say what kind of issue this is (bug or feature) as it will help people judge the possible level of work.
One thing that I've tried to do here is come up with a bunch of commen prefixes that will help us be able to see what input or conclusion are being made to the bugs. The suffix could equally be removed to make it easier to find all bugs that 'need' stuff - I'm not too sure which is best as different people will be required possibly to provide each specific kind of need.
- new - but we need a way to ensure that this can be applied automatically/automagically as otherwise it's a bit of an anying step for contributors
- bug
- feature
- enhancement
- refactor
- needs-comps
- needs-design-assets
- resolved-wont-fix
- resolved-duplicate
- resolved-invalid
- hold
- blocked
When we're in sprint issues should be assigned to a milestone so that we know what issues should hold priority over others. And as not all issues are the same we should allow project managers/leads to highlight priorities (either high or low) on particular tickets.
- release-blocking
- nice-to-have
Labels required to highlight the stage a pull request is in the code review process.
- needs-review - likewise to the 'new' label can we find a way to automate this for all new pull requests coming in?
- needs-design-review
- review-needs-work
- review-pass
- review-super-pass
- confirm-dev
- confirm-stage
- confirm-live
I don't know what these are, but I don't mind, each project will be different and should have their own project specific labels that help it move along efficiently.