Continuing the discussion from How we manage things in GitHub - milestones and also GitHub Gardening - Part 1 - Labels:
Last week @oeoeaio and I had a great session planning out how we’d like to use milestones and labels, and came up with a process for moving things through the pipe to released.
This is the second of 3 topics that I’ll add, and it covers off how we’d like to use labels (other topics: wow we manage milestones and how we manage PRs).
CURRENT LABEL SET
THOUGHTS & QUESTIONS & IDEAS
I’ve used a 
or 
or 
to highlight whether @oeoeaio and I thought each type of label was needed or not.
COUNTRY LABELS
- We now have local instances represented via GitHub projects, which means if you’re interested in an issue you can add it to your backlog.
- However, perhaps it’s helpful for whoever is picking up and developing an issue to understand which instances have a particular interest in it, so they can include them in it’s design?
FUNCTION/FEATURE LABELS
- We’ve been labelling things “payment methods” or “spree upgrade”, but do we need to? Do we use them? All the spree upgrade issues can go into a GitHub Project, and how may times have you used the “payment methods” label (or any of the others) to search for issues? Would it be just as easy to do a search for “stripe” or “spree” or “directory” or “standing orders” or “tagging”? Do we need to explicitly use a label?
REFACTOR/TECH DEBT LABELS
- Are we better off putting things like this into a project specifically dedicated to tech debt?
SKIP CODE REVIEW LABEL
- Only used one, on a transifex PR that goes through with a release. Do we need it at all if it’s so rarely used?
AVAILABLE LABEL
- What are we using this for? I think it was to make it easy for us to find issues that newbies could work on, but now that we’re using other labels for this it seems this label is now obsolete?
HACKATHON LABEL (ie. labels for specific temporary events)
- This label was created for a Hackathon run in Berlin by Anselm quite a long time ago. Is there value in keeping the things that were touched in that hackathon labelled as such, or can we retire the label now? Given we’ve now also got a “Hacktoberfest” label as well, can we consider labels like this to be temporary and remove them once they are no longer valid?
SECURITY
- Do we use this label, or mark anything security-related as ‘p-critical’ because they should be done as a priority? Or is the security label useful?
WIP
- We don’t use this in the AU team, and weren’t sure what the value was in having it? It’s currently on 3 issues, but we’re not sure what it means? @sauloperez @enricostn perhaps you can explain the use for it to us?
PRIORITY LABELS
- We do still use these p-critical/important/low labels, and they come in handy.
BUG / BUGSNAG
- We do still use these labels, either manually added by us when there is a bug or by BugSnag when it automatically creates an issue.
RUBIES/ANGULAR FOR NEWBIES / GOOD FIRST ISSUE
- These labels are super dooper useful!
AUS REVIEW
- This label is what helps you get the attention of the AU team, and what helps the AU team manage their backlog of requests.
BLOCKED
EPIC
- Zenhub label, can be used if you’d like to group issues under an epic and you have Zenhub.
LABELS WE WOULD LIKE TO INTRODUCE
-
PR test ready - this will make it easy to filter the PRs that are ready for testing, and for devs to be able to request testing when their PRs are reviewed and ready. As we build a pool of testers across different countries they (or the devs they work with) will be able to look at any PRs labelled with this and stage/test them.
-
PR no test - some PRs don’t impact any functionality and therefore don’t require manual testing. When this is the case using this label means that pesky people like me who can’t tell by looking at the contents of the PR will know not to expect it to be tested before it’s merged.
OK, so now it’s over to you all for comment. Ping @MyriamBoure @sigmundpetersen @lin_d_hop @Matt-Yorkley @sstead @NickWeir @Kirsten @enricostn @sauloperez. I’ll give this more time for comment, and will look to implement the results of our discussion into GitHub in the week commencing November 6 
Agree on the icons you added on each item, except for the ones below:
COUNTRY LABELS
We never used them and I haven’t found the value of adding those. What we do in Katuma now: If we plan to work on something we first look it up among the existing issues. If there’s none, we create it. We then move the issue, regardless of the country label, to our GH project unless we see someone has it in WIP in another project. So to me, it looks like a way to signal which instance raised the issue, which doesn’t add much value.
HACKATON LABEL
Agree. Once Hacktoberfest is over I’ll remove the labels. In this case it was required to participate in the event. People actively search for issues labeled like this and only those count for the challenge.
SECURITY
Labeling with “p-critical” seems good. However as there are experts on security and it is a discrete field of expertise, might be worth adding the distinction. I would remove the label however and just add it if we have the need. Let’s say some security expert joins OFN or offers a contribution.
WIP
This is meant to show when a PR, although opened, is not yet ready for review because is still a work in progress. You normally do this to trigger a CI build or for someone in particular to take a look, or maybe just for yourself to not forget about it.
My 2c. I also think we could update the spreadsheet while discussing this (and add it to the global drive ;))
COUNTRY LABELS
Used as a stakeholder mark today vs. local instance project which shows what each dev group is working on, no?
The way I see it a democratic way of deciding the priority of an issue 
FUNCTION/FEATURE LABELS
Mostly covered by projects but could be another grouping level, e.g. “stripe” is a project but is a kind of a “payment method”. Searching for the term would not include terms spelled a bit different/typos.
SKIP CODE REVIEW LABEL
No strong feelings against removing, but could be the other PR labels like PR no review. This could also be there on the 1 issue as a motivation for us to automate the Transifex process 
SECURITY
This is a function/feature label vs. priority labels which have a different nature. Keeping the label on the current 2 open issues also helps our shiny future security expert when he/she arrives 
WIP
Suggest renaming to PR wip in line with new suggestions PR test ready and PR no test
PR test ready
Kind of duplicate of (Zenhub) Pipeline column ‘Test ready’, but as this is not working optimally with GH projects I agree on adding.
PR no test
Agree. Same nature as a potential PR no review
That’s very true @sigmundpetersen which is why we had a question mark rather than a cross. @MyriamBoure, @lin_d_hop and @NickWeir, do you agree with this reading of the use of the country label?
Kind of duplicate of (Zenhub) Pipeline column ‘Test ready’, but as this is not working optimally with GH projects I agree on adding.
Rob doesn’t use Zenhub, and some others don’t either, so he doesn’t get to see the test ready status. And because we’re reviewing things in multiple projects it’s quite hard for us to filter down across all the projects to just show those things that need to be staged and tested. The disparity between zenhub and github is really annoying!
Yes they should collaborate and merge, and become a platform cooperative 
1 Like
Yes I am happy with this use of ‘Country’
3 Likes
Hey @sauloperez @enricostn @sigmundpetersen @MyriamBoure I’m wondering whether it helps to have issues and PRs labelled with ‘i18n’? Of all the feature or functionality labels I wonder whether this one is actually useful to find all the things related to transifex/translation? Other than attaching the label do you use it for filtering issues and PRs, or for any other reason?
Spreadsheet updated with a new tab 
I’ve no idea how to add this to the global drive - do you know how to do it @sigmundpetersen?
Sure @danielle give me access on sigmund.petersen at gmail.com and I can move it.
Just to wade in, I agree with the suggestions and the way the spreadsheet is laid out.
Having countries I think it useful too, helps also from a tracking perspective too to see what issues etc are coming from which regions - might give us insight into usage etc (might just be me that finds this an interesting insight however!..)
My one question (and sorry for not being up to tech speed), the separation between rubies for newbies and angular for newbies. For someone who isn’t necessarily from a dev background using this process, how would I go about differentiating and tagging these accordingly?
No need to be an expert but you definitely need to see what belongs to frontend and what to backend 
Hey @SineadOFNUK I have no idea mostly either, my days of being a front end developer are far far in the past. So I ask either the devs here in Australia or I @mention someone on the issue to get them to add it (@sigmundpetersen is super helpful with this, and always quick to help!).
I do not understand fully either. Is it as simple as
- Back end -> rubies
- Front end -> angular
?
1 Like
It is as simple as that…I’m 87.9% sure
The reason we did both was so that when devs came along they would be able to see whether something was more front-end centric or more back-end. We’ve found that there are some people with good angular knowledge but no rails, and vice versa.
Okay @SineadOFNUK we can just follow that then, and we’ll get an 87.9% success rate. Not bad
1 Like
My 2 cts on this:
Country label:
Today as French PO I use them to tag an issue which concerns France and is kind of prioritary for us (it has been requested for our users, etc.) As there are many issues, I only put in the French project board backlog issues we plan to work on in the coming weeks / months.
So I use the “french” label to filter issues today, but sincerely I could also put all the French labelled issues in the French backlog in our project board and remove the french label… that would also be efficient to filter them and order them by priority… (side note : we need somehow to agree when planing work in local instance, when a priority is common for two instance, who is gonna work on it. It happens with Katuma, they put some translation work their backlog and we put other in the French one)
So this conversation for me is more generally linked to how we are going to prioritize issues in the global roadmap.
From what I have started to imagine, I thought we could use the country label for an instance PO to tag the issues prioritary for them.
When the product curation team organize some global prioritization in a common backlog, then each instance dev take the “most priority task in the global backlog with his/her instance label” on it. So I would suggest to keep it for now and see in the global product curation / prioritization process that we are going to work on in Aus if that makes sense or not to keep them.
Features labels:
No objection for me to delete them, I sometimes don’t know which ones to use anyway…
i18n:
I think we use that now more generally for translations / localization issues. But it’s kind of same as other features label, not sure it’s needed, if that’s a priority for France I’ll put the French label and put it in my project backlog
Hey! What do you think about removing countries labels now that we are just one global team? They don’t add much value to me… we can write in the “context” zone in the GH issue where the issue was hit, but we don’t filter issues by country tag as we have one single pipe. Any objection @danielle @enricostn @lin_d_hop @Kirsten @sstead and all? If no objection I’ll just delete them and add a note in the context zone when needed. (that comes from a previous discussion with Enrico ;-))
1 Like
COUNTRY LABELS
WIP