Proposal - Label Changes

Technical Feedback
1

This devtalk post is intended to solicit opinions from fellow developers / maintainers / people that frequently browse the issue tracker on projects.blender.org. The goal is to provide better management and querying of issues via labels on the platform.

As a note, many of these ideas are taken from other open source repos on github, such as Bevy and rust-lang.

I’ve organized these in order from what I believe is the least contentious ideas to the most contentious.

Crashes

Problem: When crashes are discovered, they are labeled as Priority: High; individual modules are then free to lower this priority if they have a justification. While issues like this are frequently prefixed with Crash in the title, searching specifically for this string only in the title is not possible and results in false positives.

Proposal: Add a new label Type: Crash that should be added when initially triaging an issue.

Complexity

Problem: We have no way of labeling the estimated amount of effort that a given To-Do or Bug will take to fix. The closest that we have to this is Meta: Good First Issue which can be considered the easiest level of difficulty a task can be. Without extensive knowledge and reading of individual issues, it is difficult for someone not directly connected to the area of development to get a basic understanding of a task’s complexity, which has the following issues:

  • New contributors who are looking for a non-trivial amount of work to do have no easy way to look at issues that they may be interested in.
  • Module members looking to plan upcoming work need to either remember or frequently rescan existing issues to find areas to work on.
  • From an outsider’s perspective, it is difficult to gauge how long something may take, even if something is in progress.

Proposal: Add a new set of labels: Effort: Trivial, Effort: Straightforward, Effort: Modest, Effort: Huge that may be added when making To-Dos, or at any point in an issue’s lifetime.

Interest

Problem: Currently, we have multiple different usages of the Interest category of labels.

  • For every Module label, we have a corresponding Interest label (e.g. Module: Sculpt, Paint & Texture, Interest: Sculpt, Paint & Texture)
  • For some subareas / shared categories, we have individual areas of interest (e.g. Interest: Undo, Interest: USD )

We currently use the “Module” category of labels to indicate ownership - i.e. who should be the one fixing or looking into an issue. The duplicated “Interest” label for modules is currently used to indicate that a given module may be interested in an area.

When triaging an issue of ambiguous ownership, members need to remember which modules are interested or affected. For a concrete example, if there was a issue with Weight Painting overlays, it is feasible that this would involve the following Interest tags: Sculpt, Paint & Texture, Animation & Rigging, Viewport & EEVEE.

For contributors looking to work on a certain area, having interest labels that more clearly match features from a user point of view makes them easier to find.

Proposal: Slowly phase out module-level interest labels. Introduce more labels underneath the Interest category to indicate “area of interest”. Triagers then only need to know the area that a given report is affecting, and modules can track or otherwise know to follow certain labels.

Status

Problem: An issue that has been Confirmed can actually be in various different sub-states. Members may need to do further investigation to figure out what the actual issue is, or an issue may have been investigated previously and only needs a change to be proposed

While in many cases, especially for recent regressions, issues will go from confirmed to resolved fast, when an issue is longer-lasting and has no easy fix, having separation is helpful from a high-level view of the issue queue.

Proposal: Add Needs Investigation and Ready for Implementation as labels that indicate at a more granular level what the next step is. This may be added when an issue is confirmed, or at any point while it is still active.

3 Likes
2

Crashes

Problem: When crashes are discovered, they are labeled as Priority: High; individual modules are then free to lower this priority if they have a justification. While issues like this are frequently prefixed with Crash in the title, searching specifically for this string only in the title is not possible and results in false positives.

Why is this a problem? i mean yeah… it be neat if we could search on many things better, why should crashes get a special treatment? Are they more important than other things? perhaps… depends on the crash really (ie this crash always happens for all users on all platforms, and it’s easy to trigger is worse than one that’s hard to trigger on for a specific group of people on a single platforms), the prio field makes this distinction already so it’s not entirely clear what a crash tag would bring to the party beyond more work for the triage crew.

3

Overall I think, that this proposal would be an improvement.

For complexity, it’s very subjective, but I guess this is from viewpoint of maintainers, which is still subjective. So that still may not help others too much.

Also these things can change over time. For example after years of gradual refactoring, code gets into a state, where previously “huge” effort becomes “modest” to “straightforward”.

I was thinking about classification would be from perspective of skill/knowledge requirement, but it’s hard to make labels for that.

We do edit report titles to specify whether this is high prio due to crash or regression. To me it’s more user friendly to type this into label field (if I disregard the fact, that arrow keys sometimes don’t work there).

4

I’ve been looking into ways to organize a roadmap in Gitea recently so it’s good to see some discussion about labels.

Effort estimation is generally hard and estimating effort for other developers is even harder. So I’m afraid the labels will just end up being random guesses in most cases.

  • From an outsider’s perspective, it is difficult to gauge how long something may take, even if something is in progress.

I don’t see how such labels would solve this. They don’t really say how many days each label corresponds to.

  • New contributors who are looking for a non-trivial amount of work to do have no easy way to look at issues that they may be interested in.

This is a good point I think, we use something similar in the ideas page of GSoC to give potential contributor an idea of the difficulty. But this alone doesn’t seem convincing enough for me to introduce the label for all issues.

I would go with what makes triagers more happy here, so this sounds good to me.
However for planning bigger projects I find labels hard to work with. Project boards show the overall plan much better I think.

1 Like
5

This is something that was brought up in the triaging meeting when this idea was first proposed:
Although some of these changes to labels are good ideas, we will run into a issue where we have ~6000 open reports that are using the “old” labels. What would be the best way to handle this?

  • Go through the old reports and update the labels to use the new ones?
  • Leave them as is, resulting in those tasks not showing up when you try and search for them (E.g. If you’re looking for crashes, you would now use Label|Crash to find them, but old crash reports won’t have those labels)
  • Something else?

This doesn’t mean we shouldn’t switch. In fact the sooner we switch the less of a issue this is (It’s better to switch at 6000 rather than 7000 reports). But it’s still a factor that should be considered.

As long as developers find it useful, I’m personally fine with that.

As pointed out by others, guessing complexity can be hard, especially for other people. So I’m not sure how useful/accurate this would be.

I generally agree with this, but I wonder if the first step would be to split up some larger modules into smaller modules then go further down with the “area of interest” labels?

For example I personally feel like the Nodes & Physics module is too large, or the name is too broard. Here are some examples:

  • The Nodes part of the module name suggests it handles all nodes. When it only fully manages Geometry Nodes. Compositing and shading nodes are mostly handled by other modules.
  • At this current point in time the Physics part refers to a lot of legacy systems like rigid bodies, fluid simulation, cloth simulation, particles, etc. This is a completely different project from geometry nodes, and doesn’t really make sense to bundle in with geometry nodes.
    • Although I have seen various experiements from the module suggesting physics nodes may be coming to geometry nodes in the near future.
6

Generally I think trying to make the labels more useful is a good idea.

Re crashes:
I too don’t quite understand the need for a Crash label. Why would you need to search for crashes specifically? Why are they different from other issues, especially things like data-corruptions, system freezes or issues leading to data-loss?

Re Complexity:
The more I think about this the more I like the idea, mostly as a way for devs to indicate complexity to the issue author, other devs and anyone else interested. Sure, it can only ever be a rough guesstimate, but in most cases I’d say it’s pretty clear for devs familiar with the area. Just don’t add the label if you’re not sure.

I’d suggest the term “complexity”, since “effort” depends a lot on the developer’s previous experience, “complexity” is more neutral. And use 3 levels only, to keep estimating simple: Complexity: Low , Complexity: Medium, Complexity: High. Could also say Estimated Complexity: Low, etc.

The main thing I worry about it, people might not look for simpler solutions when an issue is already marked as complex. We devs often think something needs a complex solution, when there are simpler, albeit less “perfect” shortcuts possible. (I see this happen all the time, and I’m guilty too. We want to do things well, and it’s difficult to accept more limited solutions, even if users would be happy with it.) Or, devs just don’t have the fresh eyes needed to see the more simple solution.

Re Interest:
+1, I proposed doing this for the UI module as well. And I think we can add a lot of labels per module. Labels like Outliner, Keymap, Workspaces, etc would help us identify weak areas, find related issues, or make it easier for devs to find issues in their area of expertise.

My main question is who sets these tags? Triagers can hardly know about them all, so I guess it’s up to the module mostly.

Re Status:
No strong opinion. In my experience it’s usually best if I do my own brief investigation before making conclusions on issues, or after not having looked at it for a while. People submit PRs all the time that at first seem like reasonable solutions, but then looking into the issue myself I quickly find that there are better/different ways to solve it. So to me any kind of “investigated” indicator means nothing, although I’m not against it for higher-level overviews.