Labels

📜 Archive 🌱 Development
1

So I think the way labels traditionally work is kind of dumb. :speak_no_evil: I do like that they’re a super open-format tagging feature that people can use for whatever they want, but it seems in a lot of cases, people use them for things that should actually just be features. For example teams sometimes use labels to denote priority, as in Priority: High or Priority: Low. That should just be a feature where users can choose the priority of an issue. Similarly, teams sometimes use labels to identify Type, as in Type: Bug or Type: Question. I also think this should just be a feature where users can assign a type to an issue.

Maybe we can build a solution that looks like normal labels, but it’s like … :woman_superhero:Super Labels. Similar to traditional labels, but they are just holders of Sub Labels and they can be less “dumb.”

So what do we build? Here’s my proposal for a lil :motorway: Labels Roadmap:

V1.1 Instead of launching labels, we start with the most common Super Label: Type. So when a user goes to add a label, they’re prompted with a type selector. I guess the first types would be bug, enhancement, and question.

V1.1 Then we launch the second most common use case, maybe that Super Label is Resolution. And you can select duplicate, invalid, and wontfix.

V1.2 I can also see help wanted and good first issue being in another related category that is about reaching out to users outside the core team.

V2. Build a “dumb label” feature that allows teams to use labels as complex as they want, but with no color customization. I would be a bit concerned that launching this would teach users to use labels in the same “dumb” way they’ve always used them? Although I think that if we design the “dumb labels” in the right way (maybe they’re grey or they just look like hashtags) then people will understand they aren’t supposed to be used in such complex ways.

V3. Allow users to add custom labels within the existing structure of Super Labels.

What does everyone think? Do teams typically rely heavily on custom labels? Are they a necessity in V1? Maybe this plan sparks some other ideas?

1 Like
2

This is an interesting idea. I was playing around with limiting what issue submitters would be able to add when they create an issue to alleviate the noise that maintainers have to deal with. It could be interesting to limit them to only choose the type, and maintainers would then be able to add the other ones when they triage the issues. It would also allow maintainers to focus their work, what I mean with that is that they could be able to just focus on “bug fixes” and with that only look at issues of that type. Which might be a light weight to manage with maintainer fatigue.

3

I kind of like the idea, but I also hate JIRA with a passion, which comes with all these baked-in toggles and bobbles and lifecycles and multi-selects and oh my.

Afaiu, your criticism of flat ontologies is basically that they don’t express hierarchical information very well (well, by definition). What’s nice about them, though, is that they compose very well – not that GH’s interface is very good at this, but being able to filter by any combination of labels is a very valuable way of tailoring the view of a list-of-things to the task at hand (at least for me). In your example, I would most likely want to look at duplicate and invalid at the same time, and may even be unable to classify something as invalid or wontfix (I want and).

I do like the idea though of having an additional, richer type for categorising things. Essentially, an enum (key: {A,B,C}). I would want to be able to choose what the values are, however.

4

I think it’s a slippery slope. Although in theory I prefer a richer metadata for expressing information about an issue, I also don’t like the idea of limiting it to what we think will fit all users. Labels are dumb, but that’s also in a way their strength, in the same way that plaintext is dumb, and that’s why it’s so powerful.

If we look at an example of more of a structured metadata system:

https://trac.edgewall.org/report/1

We see a bunch of things that make sense, in fact most of this makes sense, but now we’ve entered the burreaucracy stage of issue management, where you have to fill in all these fields.

So I kind of see the extremes as being viable, but not the inbetween. Let me explain what these are:

  • Extreme 1: Free-form dumb labels, with the ability to filter.
  • Extreme 2: Fully customizable issue metadata: ability to add fields to issues and define their type (multi-select, text-field, checkbox, etc.)

Both extremes offer unlimited power in a sense, but the second one offers structure too, for those who want it. In the Trac example above, the columns are the fields, and these would be customizable. By default, the only field would be Labels. If a user wants issue priority, they would add a Priority field with a dropdown selector.

There’s perhaps also a sort of hybrid solution that could be interesting:

A label is composed of two parts: a type, and a value. Both of these are editable/free-form. Example: { type: "Priotity", value: "High" }, this would add a little structure for those who want it, without limiting users: you could still just do { type: null, value: "Bug" }. These would be displayed in the UI like [Priority | High].

5

I’m way into Extreme 2, which is basically how Notion databases work, which I’m obsessed with. Happy to run with this concept into the design phase…

@kim what do you think about Extreme 2?

6

Yeah I mean that is maybe the ideal – but I would devise a plan then for what V1 will look like, and how we upgrade to V2. For example:

  1. Fields are not editable. There is only one field called Labels, of type label-list, which is a list of free-form labels.
  2. Fields are editable. You can add new fields (and remove the Labels field), and choose the field types from a limited choice: [label-list, checkbox].
  3. More field types are available: [radio, text, etc.]
1 Like
7

@brandonhaslegs for a long time I was into extreme 2, today I’d definitely go for extreme 1. In my opinion you exchange flexibility for convenience and I would go for flexibility in this case. I’d rather have something like a template gallery for labels that solve specific problems (categorization, prioritization) without being too opinionated or dictating a certain workflow. This way we could have best of both worlds. The template gallery could be a convenient way to adding a set of labels, without making them static metadata.

From an analytics perspective extreme 2 is much better as we have more insights on the usage but since we’re not optimizing for that, I don’t see a strong reason rather than convenience.

2 Likes
8

I’m quite onboard with the idea that spreadsheets are the essence and pinnacle of computing and HCI :joy:

It does get quite complicated though in a decentralised, eventually consistent setting – technically, but also UI-wise: changes by others may pop up in unexpected moments (I’m sure you read https://www.inkandswitch.com/local-first.html#findings). While I agree that spreadsheets are the probably most general metaphor for that, I’m wondering: are we trying to create a project management tool?

For me, this is not the main pain point with OSS development. I’m a big fan of notmuch and also sourcehut , because they are really good tools for managing the (for me) typical workflow: there’s maybe two handful of projects I maintain, and perhaps the same number I contribute to. Updates from all of them come in in arbitrary order, and it’s quite important to keep track of the conversational nature of issues and patches. I feel like the mailbox metaphor in combination with tagging (keywords) and search actually works quite well for this.

Of course, I’m creating my personal taxonomy there, not a “folksonomy” - but for the solo maintainer demographic, is there a difference really? What if contributors are just asked to add keywords from a set I chose to help me organise my inbox (they want me to look at it, after all)? What if there was a good local indexer and tagger a la notmuch, which classifies stuff automatically (also compare to CODEOWNERS)?