We currently have a single IO related label, xdmf. I think we need more in order to simplify improvements to specific readers. it could be more area:X or even a new category like io:X.
What comes to mind :
io:xdmf
io:openfoam
io:netcdf
io:exodus
io:export (a generic one seems enough)
io:AMReX
io:cgns
io:Ensight
io:csv
io: other (any io not covered by the other labels)
These are only suggestions.
More area labels
I think we should add more area labels:
area:htg
area:servermanager
area:selection
aera:animation
area:UI
area:plugins
?
Once again, these are only suggestions.
3: Lang or Skills labels
In order to help new comes, external and different background people to contribute, adding a lang or skills category would be nice. Of course, it concerns the skills needed to fix the issue in the best knowledge of the reporter (or the dev that take a quick look at the issue.
What comes to mind :
skills:python
skills:opengl
skills:qt
skills:VTK
skills:servermanager (duplicate of the area I know, open to suggestions)
skills:cmake ?
skills:?
Of course, in this context, A pass to improve the description of some labels would also be good.
Also, if the robot could show a warning to add some labels to the issue on creation it would be great (althoug I’m not sure non-paraview-project-members can actually add labels).
What do you think ? Would you use these labels ?
Do you think these labels would help Kitwarean to fix issues and non-kitwarean to contribute more ?
Do you have any other ideas for different labels ?
I’m personally not convinced additional labels will provide many advantages. The projects and priorities labels have been useful in my experience for communicating with customers which issues to tackle next.
What will likely happen is any additional labels will not be uniformly (or even correctly) applied to issues and their utility will be minimal. As for outside contributors, they will first have to learn what the labels mean, how to search by labels, etc., so I don’t think they’ll necessarily have any effect on contributions.
My first thought mirrors Cory’s. ParaView has an outside vendor that has taken years to start effectively using the bug tracker and the labels that exist. Additional complexity may not add much.
Labels have been added as needed. If there aren’t enough issues to warrant a tag, it has been skipped. Making area:io:xdmf might be useful if there are as many as mentioned elsewhere (50+). I haven’t seen enough other issues to warrant the other mentioned labels myself.
I’d also like to keep them all lowercase, but that’s me.
The skills labels seem more useful on Discourse than GitLab to me.
How much better are the labels than just searching for the relevant keyword?
This assumes that one has already triaged and figured out where the actual problem is. How many that aren’t triage:easy do we actually have that doesn’t fit into an existing label? Most of your labels already have area labels (lang:python, area:rendering, area:build). area:servermanager may be useful as a new label though.
How much better are the labels than just searching for the relevant keyword?
With that like of thinking, label could just not be used.
This assumes that one has already triaged and figured out where the actual problem is.
Absolutely, sometime I take a look at an issue that seems interesting, I investigate, figure out the fix but realize that I can’t do it now or without funding. Using label in that case would be a neat way to formalize that this investigation has been done.
Of course, a comment in the body of the issue works as well.
How many that aren’t triage:easy do we actually have that doesn’t fit into an existing label? Most of your labels already have area labels (lang:python, area:rendering, area:build). area:servermanager may be useful as a new label though.
Not sure what is your point here, having multiple labels on a single is not a bad thing in itself.
Labels are there to facilitate the workflow. If a simple keyword search works well enough for what it stands for, then I question its immediate utility. The ones that exist now are not so easily searchable (docs could be a determination from a bug rather than a fix, build problems come in dozens of shades and flavors, rendering might crop of from anywhere, triage:easy doesn’t have a keyword obviously associated with it, etc.).
These are triage:X or workflow: labels. What new state fits in there that doesn’t exist now?
No, but keeping a dozen labels up-to-date accurately is nowhere near as trivial either. Labels may be missed at initial triage hiding them from future searches if they’re trusted. Unless we’re committing to actually keep these things accurate and triage every new issue within a reasonable timeframe, it’s just not worth the effort.