Skip to content

Instantly share code, notes, and snippets.

@towerofnix
Created August 17, 2018 03:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save towerofnix/f6d179302e5440b3b24f4f9165020fce to your computer and use it in GitHub Desktop.
Save towerofnix/f6d179302e5440b3b24f4f9165020fce to your computer and use it in GitHub Desktop.
How scratch-* issues work

Btw, the basic rundown of scratch-* issues - typically they are each in one of these states:

  1. Has the "needs-triage" label, meaning it is to be updated within the near future. You should probably not work on these since you don't know what'll happen with them. Needs-triage issues are usually turned into one of the other options below.
  2. Is assigned to a particular Scratch Team member within a particular milestone. Don't ever work on these since they are assigned to a particular ST member (although you can still leave comments on the issue/ST-made PR).
  3. Has the "help-wanted" label, meaning that the issue is open to virtually anybody in the world who wants to make a PR for it. You can work on this if you want. If it's a recent issue and you're fairly confident in your ability to make a PR quickly, you might want to comment "I'll work on this" to deter other people from immediately working on it (so that there's not multiple PRs, which is probably a pain to handle but doesn't happen very often). If the issue is pretty old or inactive, it's probably okay to just make a PR without commenting anything like that.
  4. Is in the "backlog" milestone (and is not labelled help-wanted). It is probably best not to create a PR for these. Backlogged issues are basically in the "long-term triage", meaning the ST will eventually get back to them, but not for a while; they are more focused on other important things like what needs to get done before release.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment