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

this is an amazing script. I just would not use all these labels. Seems a lot to me. On the other hand I would add admin, mobile, desktop, application or main_app

Still need to add colours, but sounds more accurate with our process IMHO

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

# Application
LABELS["main-application"]=""
LABELS["admin"]=""

# Problems
LABELS["bug"]="EE3F46"
LABELS["security"]="EE3F46"

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

# Environment
LABELS["env-production"]="F45D43"
LABELS["env-staging"]="FAD8C7"

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

# Improvements
LABELS["enhancement"]="5EBEFF"
LABELS["optimization"]="5EBEFF"
LABELS["refactoring"]=""
LABELS["feature"]="91CA55"
LABELS["technical debt"]="5319E7"

# Workflow
LABELS["in progress"]="FBCA04"
LABELS["in review"]="FBCA04"
LABELS["in staging"]="FBCA04"
LABELS["blocked"]="000000"

# Inactive
LABELS["invalid"]="D2DAE1"
LABELS["wontfix"]="D2DAE1"
LABELS["duplicate"]="D2DAE1"
LABELS["on hold"]="AFAFAF"

Commenting @vnegrisolo suggestions:

• Application section: I think we don't need this, we'll have applications merged in a shot term
• Environment section: do we really need this? PRs can only go to staging, and everything that is merged is assumed to be in production...

# Platform
LABELS["ruby"]="BFD4F2"
# LABELS["rails"]="BFD4F2" We can stick with Ruby only, Rails is Ruby (and we don't have other applications Ruby only)
LABELS["javascript"]="BFD4F2"
LABELS["html-css"]="BFD4F2"

# Problems
LABELS["bug"]="EE3F46"
LABELS["security"]="EE3F46"
LABELS["rollbar"]="EE3F46" # I think this one will be interesting
# LABELS["production"]="F45D43" I didn't get this one, bug are in production, right?

# Mindless
LABELS["chore"]="FEF2C0"
LABELS["code-style"]="FEF2C0"

# Experience
LABELS["copy"]="FFC274"
LABELS["ui"]="FFC274" # UI instead design ;)
LABELS["ux"]="FFC274"

# Environment
LABELS["staging"]="FAD8C7"
# LABELS["test"]="FAD8C7" # Do we need this one?

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

# Improvements
LABELS["enhancement"]="5EBEFF"
LABELS["optimization"]="5EBEFF"
LABELS["preformance"]="5EBEFF" # Added this one
LABELS["documentation"]="5EBEFF"

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

# Pending
LABELS["in-progress"]="FBCA04"
LABELS["in-review"]="FBCA04" # Adding our workflow step (stole from cotonete)
# LABELS["watchlist"]="FBCA04" # We can skip this one, cannot we?

# 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"

@brennovich:

• I meant the Application section chiefly because of the admin. This has its own features and priorities. I think this help us to fast understand what it is the issue and also helps in the prioritisation.
• rollbar I do not understand how it will help us in labels. In description for sure, but in labels I do not know yet.
• Mindless section I still do not understand what this means, I would not use it.
• Experience I stand with just one label: design-ux
• Environment I am with Brenno, just staging
• Feedback we do not have rfc in our process and I see no much difference between question and discussion in this context. I would keep just the question
• Improvements I am with Brenno but I would type performance in the correct way 👊

The rest I agree with Brenno. 😄

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