2024-06-13 Triaging module meeting

Meetings
1

Triaging Module Meeting

Biweekly Triaging module meeting for planning and coordination.
Folks on the payroll should attend if possible, others are invited as well.
In these meetings, we can keep us up-to-date on everything triaging, discuss recent important issues and see if we can bring the module forward.
I believe it is also good to see human faces once in a while :), so there is always room for some personal stuff if appropriate.

The meeting will be on 2024-06-13T11:00:00Z. It is open for everybody interested to join the video call (link below).

Links

Attendees

Topics

Meeting Notes

  • Wizard
  • floating point precision issues:
  • improve upon issues with unavailable hardware
    • Triaging module should create a list of hardware specific issues is pending, Philipp will start an issue on gitea, everyone can add to this then
  • feedback regarding our triaging infrastructure
    • PRs need review/feedback
  • Labels: keep an eye on the devtalk thread, maybe mention the “Unconfirmed” label there as well (along with the consequences it had back in the days of phabricator), decide upon actions to take next meeting if Alaska is attending
  • Quality Project
    • We discovered there are too many reports hanging in “Needs Info from User” even though there was a response
      • Check on the possibility of auto-changing the label back from “Needs Info from User” to “Needs Triage” if there is a response ()
      • Similar to Thomas’ daily high priortiy bug list: drop a list of these in our Triaging channel?
  • Extensions:
    • Old Reports on now “core” extensions : keep them?
    • No clear situation regarding bugreports for extensions: discussion needs to continue, wait for feedback from Dalai, Francesco, Campbell
  • Some discussion about “Known Issues”: not really clear whether to close them or not (not even from Tracker Curfew — Developer Blog), there are two types:
    • Known Issue because of design limitation
    • Known Issue because of limited resources (no fix within months)
    • Close/keep open based on the above?

Following meeting

The following meeting will be on 2024-06-27T12:00:00Z. Again it will be open for everybody who’s interested.

6 Likes
2

I would of sent this message on Blender chat, but it appears to be down at the moment.

@lichtwerk It is unlikely that I will be able to attend the meeting today due to changes in personal arrangements.

Here’s some notes on what I’ve been working on in case you wanted to discuss it in the meeting.

2 Likes
3

I don’t have strong opinions about adjustments to labels. So if you want to make a decision without me, that’s perfectly fine.

I believe @mano-wii was the primary person that brought up this point, I just worked on the devtalk thread to get outsite feedback going.

This should be relatively easy to do with simple modifications to my “activity monitoring” script.

  • Check recent activity.
  • See if the activity was on a issue with the Needs info label.
  • Check extra critera, E.g. Is the activity from the original reporter?
  • Adjust the label if all the criteria is met.
4

As for labels, my initial idea was to restructure the existing labels. To me, some of them seem a bit confusing. For example, consider the labels EEVEE & Viewport and Render & Cycles. For those seeing them for the first time, it may not be clear what “Viewport” indicates, or which label should be assigned to an issue that involves EEVEE rendering (should it be the Render & Cycles module?).

To me, it would be more intuitive if these labels were separated into: EEVEE, Cycles, Workbench, Overlays, Metal, Vulkan, OpenGL, and Render Pipeline. One label would not exclude the other. But I recognize that this can complicate the definition of what modules are.

Perhaps the module labels could be removed with this restructuring, and the modules could be identified by a mix of labels?

((Cycles | Render_Pipeline) & Cycles_Render) != 0

However, I recognize that this could raise more questions. For example, which module would the labels EEVEE + Render Pipeline go to?

If triagers still need to choose a module, this change doesn’t seem to offer much advantage in the end :\

So the main question that remains is: Is it viable to remove module labels? (something for future discussion :thinking:)

5

Sorry, I didn’t capture that when I created the devtalk thread. A large restructure could also result in signficant work transistioning old reports to the new structure (E.g. The current labels on some reports may be too vague for us to automatically transition them to the restructured labels). But on the plus side it will be a “one time job”.

This serpeation of labels could also be thought of as the question “are some modules too large?” I was going to add that question to the discussion about labels, but removed it because it didn’t fit into the subject of labels. Maybe that’s something we should ask Blender admins, modules, or developers.

6

This is a very valid question in my opinion. I would prefer modules to be more clearly defined even if contributors are assigned to many of them. The downside of this, is that we will have many more workboards.

I agree with @mano-wii. At least for triaging, it is better to split.

7

Just asking because it seems I might of mis-understood things. Does the Module | EEVEE & Viewport label mean anything once the report is on the EEVEE & Viewport workboard (the same question applies to all other modules)?

Because if it doesn’t, would it be better to:

  1. Re-evaluate the scope of different modules/projects (E.g. The Render & Cycles module can be split up into Cycles, Freestyle, Color Management, etc. If a small number of projects is desired, then somethings can still be combined. For example a Other render module could exist that contains Freestyle and say Overlays).
  2. Get rid of the Module labels, and have triagers assign reports to the relevant projects/workboards instead of adding the Module label.
  3. Then go with what mano-wii suggested, split up the labels to the many small sections if they don’t exist already.
8

The current convention is that all issues should be assigned a module label, and this is ensured by the triaging team. This way an issue is always clearly the responsibility of some module.

The workboard is for modules to organize things how they prefer, and not a concern of the triaging team. The module can choose to put all issues on the workboard, or only a subset, or have multiple workboards. In general putting all bugs on a workboard is not convenient, and it’s not how people typically browse them.

1 Like