New GitHub label system

[PaulRBerg]

New system

The default GitHub labels suck. We need a sane system that groups labels by:

• Effort: "epic", "high", "medium", or "low"
• Priority: 0, 1, 2, and 3
• Type: same as conventional commits
• Work: via the Cynefin framework (optional)

But there will still be some non-grouped labels, i.e., "backlog", "duplicate", "good first issue", and "help".

Notes

• I've opted out of Status labels because I consider the Kanban boards in our GitHub Projects to work better for triaging like this
• I've configured GitHub to apply these labels for any future GitHub repo we create in our organization.

Research

I've devised the system above by inspiring from the following articles:

• Sensible GitHub labels
• GitHub Labels that are logical, colorful and sensible
• Sane GitHub Labels
• GitHub Pro Tips For Your Development Team

[PaulRBerg]

Cc @sablier-labs/engineers

[razgraf]

Suggestion: for discussions, I'm finding it useful to have a dynamic "topic" label e.g. topic: fees, topic: v3 or topic: dependencies.

Sometimes the title of the discussion is not directly linked to the topic, while the discussion itself is contextually under that certain topic. As such, Github's search feature may not fully catch this when trying to search for "all threads related to a certain subject".

Any thoughts on adding a similar label, mostly for the Discussion tab?

[PaulRBerg]

Interesting idea, but I think that:

1. Discussions are naturally multi-faceted and multi-topic. We often conclude a discussion with something that has nothing to do with the OP.
2. Some topics would be rare (and this would pollute the label system)
3. The topics would be different across repos, which means that we couldn't put them in the organization-wide labels and in this repo
4. There would be an overlap with the type labels, e.g., what's the difference between topic: dependencies and type: dependencies?

Thus, I would prefer not to add these topics to all of our repos. But if you would like to try them in V2 Interfaces, feel free to fork my repo and add these extra labels so you can manage them yourself.

---

How about the others? do you like them?

[razgraf]

Generally yes.

The Cynefin framework as described by GPT sounds nice, but could you explain why a work label is needed?

This "domain" of a problem is usually something to be estimated throughout the conversation/discussion itself (either by the OP or by the team working on it). While it's definitely useful when qualifying work in our threads (or verbally), I'm not sure it's useful as a label:

1. can't see a case when I'd sort/search by that label
2. it would therefore make the issue classification more cumbersome

Would you mind mentioning some aspects that would make this valid as a label, and not just as a philosophy?

[PaulRBerg]

could you explain why a work label is needed?

I prefer to say "helpful" because most things are not "needed" in software. Since we can write code in binary, programming languages are not needed.

"work" is helpful because it gives a sense of the kind of problem situation we find ourselves in.

This "domain" of a problem is usually something to be estimated throughout the conversation/discussion itself

It's not meant to be used in discussions, only by issues (which I hope will get renamed to Tasks or Todos someday).

can't see a case when I'd sort/search by that label

It would make you think - for 20 seconds - about the kind of problem situation you are faced with. This would have downstream effects:

1. You'd want to work on the work: clear and work: complicated tasks first
2. You wouldn't give the work: complex/ work: chaotic tasks to an intern.
3. You'd want to ask for external advice on work: chaotic

it would therefore make the issue classification more cumbersome

You do not have to apply it if you don't like it. To each their own.

Would you mind mentioning some aspects that would make this valid as a label, and not just as a philosophy?

First - responded above.

Second - every bit of knowledge that gets created at Sablier is subject to an epistemological process; we cannot not have an epistemology. the epistemology might be explicit or implicit, but it's always there.

[PaulRBerg]

But anyway, I am happy to concede that it may be overkill for our purposes today. This sort of advanced project management may become more valuable as we scale up the team.

I will continue using it in the Solidity repos - ignoring it in V2 Interfaces and the other frontend repos is OK.

[IaroslavMazur]

A granular label system sounds nice, in general.

However, there's the risk of causing more confusion than clarity by transitioning to it, if there are "too many" (and this is a fairly subjective measure) labels to be working with right from the beginning.

Ideally, the new label set would be introduced gradually. e.g. by having just the several most important ones first - and labeling everything else with the "less important" label. Then, "less important" would be gradually split into more and more new labels, until every possible category is covered.

Though, this would not be the easiest thing to organize and adhere to.

[PaulRBerg]

I can show you the new labels on the all-hands call today. They are fairly easy to pick up besides the Cynefin stuff. The type: labels stem from conventional commits, which we have been using for many years now.