GitHub Gardening - Part 1 - Labels

Product Development Process
1

The overall goal of this exercise

Is to make it easier to identify, sort, and manage issues within GitHub. And to use the GitHub repository only for identifying and managing changes to the OFN master codebase, and nothing else (all other things like changes to the WordPress site or to the user guides can be managed here).

Part 1 - Labelling

We need to come up with a set of label types and the labels within that type that we can use in GitHub. These labels will work alongside of Milestones and the ZenHub boards (a Chrome & FF GitHub plugin to manage all issues in your milestone as they are done - https://www.zenhub.io/).

View the current list of labels.

Proposed categories and labels

A google spreadsheet has been created with a strawman version of the labels that you can view and comment on.

However, I’ve added some detail here for you to get an understanding of this strawman. If you use GitHub and have some thoughts please add them below. Eventually we’ll have a final version, which we’ll then implement into GitHub.

Type #1 - PRIORITY

This type of label already exists, and is working well.

Critical = highest priority, if a feature/function it must be done ASAP or if a bug fixed immediately (fatal error, direct impact on revenue, high risk).
Important = still fairly high priority, however can be looked at after all critical issues.
Low = not needed, likely to be put into the Icebox milestone as it isn’t important or critical.

Type #2 - STAKEHOLDER

This type of label already exists, and is working well.

It is used to demonstrate who is a particular stakeholder for an issue. An example of this would be the current work being done by Rob on tax issues. The UK and Scandinavia both have a direct interest (either financially or supportively :relaxed:) in having this work done, and so those issues should be labelled to demonstrate this.

So this means there will be one label per local instance. At the moment the labels of this type that exist are france, scandinavia and the uk, all others can be created if we agree this is needed.

Question for the crowd: is it also worth having labels for enterprises who have a vested interest in issues, such as StroudCo (UK) or FoodConnect (AU)? Is there any value in this?

Type #3 - REVIEW REQUIRED

This type of label already exists, and is working well.

It is used primarily to identify when a code review, or a pull request, or a general review of what has been built (e.g. by Sally, tester extraordinaire) is required of the dev team in Australia (and therefore the label is ‘aus review’. At the moment it’s used as a way to get the team’s attention by the UK team, and it works really well.

Type #4 - FEATURE GROUPING

These types of labels exists to a certain extent, but has some room for improvement.

These labels identify issues as part of a bigger piece of work around a function or a feature (e.g. ‘groups’, ‘order cycles’, ‘API’, ‘reports’, ‘i18n’). They work well to group issues within a subject matter.

Type #5 - ISSUE TYPE

These types of labels exists to a certain extent, but has some room for improvement.

These labels identify issues that are bugs (or to identify those that have been found via bugsnag), or are technical in nature (originally called ‘refactor’, but propose changing this label to be ‘technical’)

Question for the crowd: Is ‘technical’ the right label for all things that don’t fit within a particular feature group or that impact on a number of feature groups (issue example here)? Better way to describe it?

Proposed labels to be deleted

international :negative_squared_cross_mark:
core :negative_squared_cross_mark:
hub
WordPress
task
story
tweak
bitesize
available
done
wontfix

:negative_squared_cross_mark: deleted in Github

Note: Reasons why are listed in the Google spreadsheet (link above)

2

My grouping exercise with existing labels. You can see where my thinking was going with the proposed draft based on this.

labels-gh.jpg3990×1435 638 KB

3

OK, over to y’all to contribute your thoughts about how we can improve labels in GitHub. Ping @pmackay, @MyriamBoure, and @NickWeir, and @Selmo, please share this with your OFN peeps that use GitHub :smiley:

4

Thank you @danielle for this work and opening the conversation :smile:
I have commented directly in the google spreadsheet (I saw @sigmundpetersen did the same)

I don’t think so, I think as soon as a big stakeholder for a locl instance have an issue, it becomes an instance issue :slight_smile: [quote=“danielle, post:1, topic:520”]
Question for the crowd: Is ‘technical’ the right label for all things that don’t fit within a particular feature group or that impact on a number of feature groups (issue example here)? Better way to describe it?
[/quote]

I agree that “technical” is not very clear, for me everything is technical :wink: Maybe something like “transversal”, or “general”, or “performance”? @sigmundpetersen and I also proposed to have a “whish” tag here.

Ping @marito59 and @nickwhite, I think you have a word to say here :slight_smile:

5

Well if this is meant to describe code performance improvements, it really is refactoring so current label can work. Else maybe ‘performance’ or similar could work.

6

thanks Danni - good work.
this looks good to me.
i agree with Myriam - i dont think we need enterprise specific labels such as ‘stroudco’ - most of the issues stroudco has come up with have been relevant to several other users.
i have follwed Sigmund’s lead and added a comment suggestion under ‘issue type’ in the google doc.

7

I vote for Technical as a basket for issues that cannot attributed to something and that are not functional improvement. Performance and Refactor are both more specific, and I guess that we may find other technical sub categories.

I think we can wait to see if the Technical category is not growing too much and then decide to split based on actual issues.

8

I’m not sure technical is a particularly well defined label, wonder if its really needed at all?

I quite like international for stuff related to internationalisation but not necessarily specific to one country.

9

I agree with you @marito59, we can always include the technical label and if it’s not used well, doesn’t serve a purpose we could always remove it.

@pmackay, I’d be keen to know how you would label the issue (and any equivalent issues that may exist and not be labelled) sitting with the current refactor label? Also, I added a comment on the Google spreadsheet about internationalisation and included you in the comment - am wondering if the label in D5 covers your thoughts on international or is a different thing?