create_labels.sh

#!/usr/bin/env bash

# Colours picked from https://robinpowered.com/blog/best-practice-system-for-organizing-and-tagging-github-issues/

###
# Label definitions
###
declare -A LABELS

# Platform
LABELS["ruby"]="BFD4F2"
# LABELS["rails"]="BFD4F2"
LABELS["javascript"]="BFD4F2"
LABELS["html-css"]="BFD4F2"

# Problems
LABELS["bug"]="EE3F46"
LABELS["security"]="EE3F46"
# LABELS["production"]="F45D43"
LABELS["admin"]="F45D43"

# Mindless
LABELS["chore"]="FEF2C0"
# LABELS["legal"]="FFF2C1"

# Experience
LABELS["copy"]="FFC274"
LABELS["design"]="FFC274"
LABELS["ux"]="FFC274"

# Environment
LABELS["staging"]="FAD8C7"
# LABELS["test"]="FAD8C7"

# Feedback
LABELS["discussion"]="CC317C"
LABELS["rfc"]="CC317C"
LABELS["question"]="CC317C"

# Improvements
LABELS["enhancement"]="5EBEFF"
LABELS["optimization"]="5EBEFF"
LABELS["documentation"]="5EBEFF"
LABELS["performance"]="5EBEFF"

# Additions
LABELS["feature"]="91CA55"

# Pending
LABELS["in progress"]="FBCA04"
LABELS["watchlist"]="FBCA04"
LABELS["in review"]="009800"

# Blocked
LABELS["blocked"]="000000"

# Inactive
LABELS["invalid"]="D2DAE1"
LABELS["wontfix"]="D2DAE1"
LABELS["duplicate"]="D2DAE1"

# On hold
LABELS["on hold"]="AFAFAF"

# Technical Debt
LABELS["technical debt"]="5319E7"

###
# Get a token from Github
###
if [ ! -f ".token" ]; then
  read -p "Please enter your Github username: " user
  read -p "Please enter your 6 digit two-factor-authentication code: " otp_code

  curl -u "$user" -H "X-Github-OTP: $otp_code" -d '{"scopes":["repo", "public_repo"], "note":"Creating Labels"}' "https://api.github.com/authorizations" | jq -r '.token' > .token
fi

TOKEN=$(cat .token)

read -p "Who owns the repo you want labels on?: " owner
read -p "What repo do you want labels on?: " repo

for K in "${!LABELS[@]}"; do
  CURL_OUTPUT=$(curl -s -H "Authorization: token $TOKEN" -X POST "https://api.github.com/repos/$owner/$repo/labels" -d "{\"name\":\"$K\", \"color\":\"${LABELS[$K]}\"}")
  HAS_ERROR=$(echo "$CURL_OUTPUT" | jq -r '.errors')

  if [[ (! -z "$HAS_ERROR") && !("$HAS_ERROR" == "null") ]]; then
    ERROR=$(echo "$CURL_OUTPUT" | jq -r '.errors[0].code')

    if [ "$ERROR" == "already_exists" ]; then
      # We update
      echo "'$K' already exists. Updating..."
      CURL_OUTPUT=$(curl -s -H "Authorization: token $TOKEN" -X PATCH "https://api.github.com/repos/$owner/$repo/labels/${K/ /%20}" -d "{\"name\":\"$K\", \"color\":\"${LABELS[$K]}\"}")
    else
      echo "Unknown error: $ERROR"
      echo "Output from curl: "
      echo "$CURL_OUTPUT"
      echo "Exiting..."
      exit;
    fi
  else
    echo "Created '$K'."
  fi
done

My thoughts: 💭

• I agree that admin is useful for us - I will replace production with it.
• I don't think rollbar will be useful, as it's already covered by bug
• Mindless are chore type tasks. e.g. code style cleanup, removing old files, refactoring or rearranging code (e.g. moving a component from one directory to another), etc. I don't think we need to add code-style here since it's too specific.
• I think we should try to use design and ux for the first while, and see how it goes. I prefer design to ui because it's easier to visually distinguish between them (due to word size). I see these being used mainly for bug reports. design would be visual only whereas ux would encompass the entire user experience.
• Agree that Environment should only be staging for now.
• Agree that we should add performance to the Improvements section.
• Feedback is a bit of a special case. I think this would be our Backlog section and would be for proposals (rfc), queries about what and why we do things (question) and further discussion/development (discussion). In other words, Feedback is for talking and fleshing out issues, rather than issues that are being worked on.

Labels are designed to be mixed and matched, e.g.[ design, bug], [ rfc,optimization], [rfc,ux,enhancement].

Also we should start writing issues much better and not tolerate one line issues, or ones that are placeholders (especially since GH Issues is our de-facto task management system).

Pull Requests

I don't agree with using labels for Pull Requests, I don't think it has served us well at all, and can be confusing to figure out what is ready to merge. My suggestion for Pull Requests is that we open PRs early, with a prefix of [WIP], read this post for reasons, and then edit and remove the prefix when the PR is ready.
I suggest that we move to a :+1 type of model for PRs and use something like https://github.com/robinpowered/commodus to handle the required approvals automatically, and thus we know when the PRs is green we can merge it.

I agree with a lot of things all you guys mentioned. About our tool we have to remember that we are going to be forced to use milestones and this is also visible.
About the labels in the workflow, in issues and pull requests, the tool add labels to mark the process. But I think that we have to run one week with the new tool to check how the things are going to happen.
Shane I think that you should to implement the things discussed to test on the next week. 👍

Will do 👍

Awesome! @shaneog sumarized everything regading labels. Regarding PRs, I agree when you said labels aren't helping, also agree with [WIP] convention, not sure about :+1:, tought