We have 1k bugs. Would you like to help triage?
We've hit a bittersweet milestone of 1,000 open issues for IfcOpenShell :')
I think this is an appropriate time to ask for the (unpaid, volunteer) help of bug triaging. I believe that when we focus on bugs, we can close bugs faster than we receive them, but we often don't have that dedicated focus time, so bugs pile up. Triaging means that when we do focus on bugs, we do so strategically.
What this means in practice is for someone to help tag bugs in a few aspects:
- Whether it is Bonsai/IfcOpenShell-Python/IfcOpenShell-Core, etc.
- To label whether it is a feature request, bug, or generic task.
- If it is Bonsai and a bug, to label it as Low, Medium, High, or Critical priority.
- To have a general knowledge of bugs and close if they are a duplicate.
- To test older bugs that might already be fixed and close it, keeping an eye on commits.
For example, critical bugs are crashes and regressions. Low are cosmetic or usability.
Anybody keen? It does not require programming knowledge, but it will probably need you to be (or become) a poweruser over time :)
Comments
Can do.
I don't want to do it alone though. Who will hold hands with me? ;)
I think we need to add these labels...
I'd be happy to join.
I will be glad to help
Github has a "type" attribute, which you can choose from "Bug", "Feature", and "Task".
I'd say "Bug" means actually something is doing something that it isn't designed to do. So that means UX improvements go under "feature".
"Task" needs a bit of explanation, this might be refactoring, adding documentation, tweaking the build system, and so on. They're probably pretty rare.
For adding a severity level, we only recently just added a "Critical" label. I'd propose only bugs are allowed to have a severity label. Here's an attempt at definitions:
There is a healthy amount of ambiguity as always :) I'd say for a start only things tagged with Bonsai need these extra tags.
If you'd like to help let me know your Github username so I can ensure there are appropriate permissions :) A huge thank you in advance!
@Moult
same username as here
Cheers, invited. BTW my proposal for severity definitions could be totally wrong, please if someone has a better idea please go for it :)
Dayo9174
@Moult i think this initiative is very important because it allows the core developer to focus on important things and this means less energy (and money) waste. It also helps the new user experience because less critical bugs means more stability and so on.
I can help, of course, starting with the issues i'm involved with. Thanks as always :-)
I will be glad to help. @Moult is it possible to write a banner in issues of github with these "triage golden rules"? So the issue owner can already flag his/her issue? I guess that will help moving forward.
Thanks!
My github user falken10vdl
Maybe another option is to create some more issue templates with at least the most common combinations and have labels applied to them automatically (see 4 in https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository):
I have created a possible PR ( Add issue templates that allocate labels automatically for easier Triage #6539 ) for doing that in case that is benefitial:
As an example when creating issues using the templates Bug - Bonsai - Major & Feature - IfcOpenshell-Python, the labels are allocated:
Thanks!
imho, i feel this is too many options. For an average person (casual user) submitting a report, I feel they would glaze over, and would be confused what goes where, and perhaps not even post anything, since it's too involved.
I think it makes more sense to make the posting of a bug the most easy thing to do, and then the 'triage team' can tighten up its categorization, after the fact.
I'm actually of the camp where I don't think we should have any templates at all--all though the (3) we currently have is a nice balance.
Sure! It was just a suggestion in case that could help but yes, maybe that is too much. There is also the new issue forms:
https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository#creating-issue-forms
That is probably friendlier and if asking a couple of questions in a dropdown menu can make afterwards the triage easier... could also be an option. What do you think?
Thanks!
Something in this line could help? https://github.com/marketplace/actions/advanced-issue-labeler
Thanks!
Count me in; GitHub username is Owura_qu
Thanks a huge amount for all your help! I've invited everybody. For the next release cycle I'd like to focus on bugs :)
GitHub: JanFilipec
I've added descriptions to the labels in Github so you can see their definitions inline.
I've also added "valid model not loading" to the definition of critical severity. (note that if an invalid model doesn't load, it's therefore a minor severity).
I'd like to help, please: john-rogers
I think a label akin to "Needs info from user" would help triage some stale, very old or already resolved bugs. Some users write a bug report, devs ask for additional information and then they don't think about coming back giving more explanation and the bug reports stays open indefinitely. Adding this tag would help define a rule like "if no info from user for 2 weeks when it is absolutely neeeded to debug, then close this report".
Maybe we can adapt some status system similar to what Blender is using on their issues.
The most useful ones are probably those 3:
I've added the "Needs Info" label. 2 weeks is a bit harsh perhaps at our level of resources. Perhaps 1 month? BTW you can also search for "no:label".
I can perhaps do a bit of typing and severity triage. User: sboddy
Cheers, added :)
Does it take a while for the permissions to be provisioned in github? No change to the UI in the right side-bar so far.
I've sent an invite but you probably need to accept it. Check your inbox?
BTW this is the equivalent of "needs triage" for Bonsai if you want a TODO list ;)
is:issue state:open -label:Severity:Major -label:Severity:Minor -label:Severity:Critical label:BonsaiDoh! I didn't realise it was so... consensual. Thought you'd just flip a switch and it'd be there. All good now.
I have seen that there are +600 issues without a type value but only +20 issues without label.
Do we assign type to those 600? Does it make sense that type if not assigned it is assumed to be a bug?
What is the expected proccess?
Assign type -> assign label of product (bonsai, ifcopenshell, etc) ->...
Thanks!
would add...
is:issue state:open -label:Severity:Major -label:Severity:Minor -label:Severity:Critical label:Bonsai -type:Feature