In recent Triaging module meetings, there has been discussion around adding extra labels to the Blender issue tracker. Labels being the tags attached to reports, like: Status|Confirmed, Type|Report, Module|EEVEE & Viewport, Interest|Metal. We would love input from developers on the topic of adding new labels, so we have a few questions we’d like to ask:
As a developer, outside of the Module and Status labels, do you regularly look at, or search/sort by labels? If not, then is there a reason you aren’t using them, and what could be done to improve the label system so you will use it more often? This is to gauge if it’s worth investing time in the area of labels.
Do you think there are any areas labels need to be improved in? Whether that’s the labels their self, or how triagers and developers are using the labels.
The triaging module would like to add hardware labels for major CPU and GPU vendors (E.g. Hardware|Intel, Hardware|AMD) to help triagers and potentially developers find hardware specific issues. How do people feel about this?
For large rewrites of systems where both features available at once (E.g. Grease Pencil to Grease Pencil v3), would adding labels for these rewrites be helpful for developers?
This can be done in phases. Start by adding a Interest|Grease Pencil v3 and Interest|Grease Pencil label, then once Grease Pencil v3 replaces Grease Pencil, rename Interest|Grease Pencil to Interest|Grease Pencil Legacy (for LTS releases that have Grease Pencil Legacy) and rename Interest|Grease Pencil v3 to Interest|Grease Pencil.
Some modules cover many areas of Blender, and there’s no easy way to direct a bug report to the people working on subprojects inside a large module using just labels. For example, there’s no Interest|Transform label for the transform subproject of the Modelling module. Would adding more interest labels that correspond to these “subprojects” and other areas of Blender be useful to developers? This can be decided upon on a module-by-module basis if desired.
I don’t actively search for those, but I do find them useful. It helps to quickly see that someone thinks things are related to my module, even when it’s not the direct responsibility. It helps to give some perspective on the scope of the issue, without having to read through the description & the comments.
Not super necessary. Some visual grouping could be nice, like replacing Interest: A, Interest: B with Interest: {A, B}.
I do think the general idea you describe would be useful, but I don’t think that ‘Interest’ labels are the right place. Maybe a different structuring of the projects (and then I mean the Gitea ‘projects’) could help here, but that would require a considerable amount of work which I don’t think is worth it. I mean, mentioning “transform” in the title could already be enough.
I almost never search for them, but do use them as quick filtering info when looking at list of bugs in a module e.g.
AFAIK so far we are using assignment to gitea projects for in-development features, once bug reports are accepted for them. Not sure if having different labels on top of it would be that useful? But not against the proposal either.
In general I would say yes. Think that’s already quite the case for the Core module e.g., (depsgraph, image, overrides, undo, id management, etc.), and I find it useful to help ‘triaging’ issues among the dev team.
In the EEVEE & Viewport module there are already nice amount of different labels for each areas. So I don’t think there is anything to improve there for us.
I think triagers should make sure to use the right sub features label. It is kind of hard to filter things I broke from things that other devs broke for instance if the labeling is not done thoroughly. Also it might make think me there is no new bug reports to look at for my feature when they are. They are instead put under just the module label which filters them out.
I am unsure. The risk is that some issues might be labeled as limited to one platform when they could potentially be reproduce on others. But developers filtering for their platform would not find them. At least for us, the OpenGL and Metal tags are enough for the distinction.
I agree with this. However, I would not consider supporting bug fix for EEVEE legacy
For us this is definitely worth it. But like I previously pointed, the current labels are enough.
I don’t regularly look at the Interest labels, Module is usually enough, but I do appreciate when they’re there, and I try to set them myself, for certain sub-areas like Alembic or USD for the Pipeline/Assets module.
I sometimes see Interests applied to issues where its unnecessary. e.g. An issue that will be entirely solved by the Module in question and not some other Interest. I think this happens most when folks set a Module:Foo and then Interest:Bar where Bar is also a module as well. I guess you could say I try to use Interests only for sub-areas, not top level module areas. Some amount of rigor should be applied when setting the Interest when necessary. Maybe something like:
a) Don’t just set an Interest simply because it’s related to something else, set it when that other area may need to be personally involved with the fix or the review for the fix.
b) Don’t use Interest:Foo in addition to Module:Foo especially when making a first pass at triage. If you can’t fully triage the issue to a Module, leave the tags blank. I always remove the Interest when I fully triage it to a Module anyhow.
Additionally, because of how every git source forge choses to display these tags, having many labels/tags on each report makes viewing the bug list a really poor experience.
Large Modules with clearly delineated sub-areas might be ok IFF the developers in that area are actually going to use the labels. If they’re not, then setting the labels will just be wasted work and visual noise. Though keeping the needs of the Triage team in perspective is necessary too, not just for the developers.
In an ideal world this one would be nice. I often maintain a set of vendor-specific bugs that I can refer back to and this could help. However, as mentioned above, it’s somewhat easy to see that it might end up incorrect or out of date if the problem ends up being non-vendor-specific. Not sure how best to proceed with this one as I’d like it when it’s right, but dislike if I come across something I missed because of the labels…