Skip to content

Best Practices: Github Labels

Ashley Kolodziej edited this page Apr 23, 2020 · 7 revisions

Note: This is a proposed process, and is still under review.

Labels

We base our label structure on the fine principles proposed here. We start with groups of labels for the following:

  • Status: Can progress be made on this issue right now? Why or why not?
  • Type: What type of work is this? This is for helping to track what is billable, and when.
  • To Do: What will someone need to do to accomplish this task? The starter labels are organized by skillset.
  • Priority: How important is this task? You can choose anything from Critical (prevents launch) to Not Addressing.
  • Needs: Who are the stakeholders for this task - the people it affects? These are the people that need to be looped in, whether they work on the task, or need to provide feedback on it.

You can see an example of these labels in practice in the Responsive Foundation repository.

The design system

Each label group has a color scheme and is always prefixed with the group name and a certain emoji that represents that group except for Status, which uses the traffic light colors to quickly communicate whether you can stop, proceed with caution, or go on a task.

Screen Shot 2020-04-23 at 5 05 39 PM

We tie certain colors, such as red, to the groups of information that match closest:

  • Red: the Blocked status, and the Priority group, as in "Hey, stop! This is important."
  • Yellow: the Needs Review status, and the Needs group, as in "Hey, quick warning - this needs feedback from someone still."
  • Green: the Ready for Work status, and the To Do group, as in "Go go go!"
  • Blue: the Type labels, which help us understand how to track our time. Blue is for billing!

Why these labels? What about _____?

Not all projects we take on are built the same way. Some will be very complex child themes and plugins. Others might be as simple as custom CSS. These labels represent the common needs all types of projects share, from the very simple to the very complex. Keeping the standard set of labels as simple as possible creates a lower barrier of entry for new folks. It also allows flexibility for the more complex projects to add their own labels. We think these groups will be a good starting point for your individual project needs 95% of the time - and for those edge cases, you can and should add your own labels!