Issue Tagging for Blockstack

#1

I’ve done a bit work on finding some issue tagging strategies that work for larger projects. A couple of examples are below.

  1. Kubernetes - 4,700 open
    • Their system is to tag issues with area/* and kind/* to allow sorting and then priority/* once they have been prioritized
    • This gist gives a few examples
    • The category/instance tagging is used in a number of projects similarly to how Kubernetes uses it. (see Hashicorp, Docker)
  2. Lisk - 100 open
    • No use of category/.
    • Each issue tagged with “kind” (standards, bug, test, etc…) and “difficulty” (easy, medium, hard)
    • They also have a concept of “parent” and “child” issues. Child issues link back to parent and are marked as such
  3. React - 293 open
    • They have Component: , Type: , Status: , and Difficulty:
    • Most issues tagged with at least component and type

I would propose that we adopt the kind/*, area/*, and priority/* tagging. Each issue should have either kind/ or area/ and priority can be added as the issues are prioritized. What do you think @jude @aaron @larry @yukan.id? cc @vsund

3 Likes
#2

Thanks for tagging me on this, I think we’ll be able to gather some helpful ideas here :slight_smile:

Several things I have in mind:

  • it’s definitely worthwhile to have as little as possible open issues and as little as possible untagged issues
    • so it’s important to stay updated on open issues and tag them as soon as possible
      • maybe as a daily habit “checking for new issues in all my repositories in the morning”
    • helps also the owner of a repository to stay updated on what problems occur lately
    • helps also the issue creators who notice that their issue got read
    • when maintaining a good and durable hygiene of issues/PRs/branches/etc these new-year cleanings are much less extensive :slight_smile:
  • there are several ways to ensure an issue gets solved: prioritization, milestoning, due-to dates
    • all need constantly checking back to fulfill them
    • they may can be connected in a helpful way
      • prioritization for bugs and features, simply reflects the importance of them
      • milestones for yet-to-release features that should come with a certain version
      • due-to dates need a milestone (GitHub is able to do this), thereby we ensure that milestones get resolved

Important note on prioritization: It’s easy to only work on high-prioritized issues and forget about minor ones. Checking back and raising the prioritization on issues is extremely important. Working on issues beginning with the most important issue may have some effects on losing minor issues in the backlog (sooner or later in huge amounts :D).

I lately saw a (really) good talk about these patterns: https://media.ccc.de/v/34c3-9095-antipatterns_und_missverstandnisse_in_der_softwareentwicklung.
The original audio is German, but there’s an English transcription if somebody wants to watch it (didn’t checked the quality of the transcription, but normally they’re good).

2 Likes
#3

Will have some opinions. Not ready to share quite yet.

#4

Agree that this is a highly opinionated and very important part. Just want to note again that these are just opinions and take them as you need if they help.
In the end it’s your decision how to lay out these things :slight_smile: