How we manage things in GitHub - labels

Agree on the icons you added on each item, except for the ones below:


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.

:white_check_mark: 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.


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.

:white_check_mark: 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 ;))


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 :slight_smile:


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.


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 :wink:

:question: 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 :stuck_out_tongue_closed_eyes:

:white_check_mark: WIP

Suggest renaming to PR wip in line with new suggestions PR test ready and PR no test

:white_check_mark: 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.

:white_check_mark: 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 :wink:

1 Like

Yes I am happy with this use of ‘Country’


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 :smiley:

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 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 :sweat:

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 :wink:

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 :slight_smile:

1 Like

Moved it here

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…

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 :wink:

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

Absolutely no objections :slight_smile:

no objections at all

No objections from Australia