Issue triaging · Coq devs & plugin devs

are you really planning to work on all of these 49 issues? https://github.com/coq/coq/issues/assigned/maximedenes?page=2&q=is%3Aopen+is%3Aissue+assignee%3Amaximedenes
currently issue assignment is meaningless AFAICT so adding some is just noise
if we want it to mean something we need to first clean all current assignments, then decide on what the meaning is exactly ("planning to work on it" is too vague imo)

Maxime Dénès (Feb 19 2019 at 13:31):

are you really planning to work on all of these 49 issues?

yes, maybe I took some wrongly, but that would be an exception

Maxime Dénès (Feb 19 2019 at 13:32):

then decide on what the meaning is exactly ("planning to work on it" is too vague imo)

fair enough, what would you suggest then?

Gaëtan Gilbert (Feb 19 2019 at 14:06):

I think triaging is more about classification than assignment
I can see 2 axes for classification:

how much do we want to fix the issue (something like: invalid < not sure if want < nice to have < ?? < blocker, not sure if there's space between nice to have and blocker / how that space would be described) (NB invalid may mean "redirected to discourse" for some issues)
how hard it is to do (not happening < large scale redesign needed / complicated investigation needed < local redesign needed / (expected) short investigation needed < we already know what to do and just need to do it < PR submitted < already fixed), in some way this interacts with where the issue occurs (eg a funind bug may be easy for those who know funind, but with the current team it's not going to get fixed)
maybe also add to some project? I haven't really used projects so don't know

if we actually do triaging the above would probably need some adjustment of course

then assignment could reflect some commitment to make progress (even if not fully committing to making a fix), so when assigning one would indicate how long until they expect to have news, eg "sometime in the next 2 weeks I'll try to debug this", then either it actually happens (5 days later: "I got bla bla results, no more time to work on this so removing assignment") or it doesn't and whoever looks upon the PR can remove the assignment (or the assignee can do it themselves when they realise they'll miss the deadline)
Probably nobody is going to say "I'll have a look before 2100 lol" and assign so deadlines should remain reasonable and we could clean old assignments / guess that an assignment is outdated just by looking at the last update date on the PR

lots of issues would have no assignee since we don't have enough people to work on all 1.8k, that's basically what @Vincent Laporte was saying IIUC

Personally my work is pretty unorganised so if I follow that assignment scheme it would look like "I'm looking at this today" -> a few hours later: "well that went nowhere" or "here are some results" or "here's a PR"
the idea is more organized people may get more value out of it, and more importantly I don't know what else we could do with issue assignments (which may mean we just don't have a use for them)
it's not like we can say "if you're assigned then you have to fix this by next release" or some such since when the issue isn't fixed nothing will happen

anyway I'm just making this up so if you have any comments speak up

Maxime Dénès (Feb 19 2019 at 14:40):

sounds good to me

Théo Zimmermann (Feb 19 2019 at 18:49):

FTR I had said I would be writing a proposal of an issue triaging policy and I agree with what @Gaëtan Gilbert has said above. In particular, assignment should mean short term commitment (with deadline) and should be removed when we realize we are not going to work on it soon.

Théo Zimmermann (Feb 20 2019 at 14:33):

I liked the "priority: nice to have" phrasing of @Gaëtan Gilbert, so I renamed the previous "priority: low" label (that sounded quite negative when putting on some user's bug report).

Théo Zimmermann (Feb 20 2019 at 14:33):

Regarding "high" priority, ideally we would like to list for who it is high priority (a single user, many users, Consortium users, influential user, developer) and to make sure that there is a limited number of high priority bugs listed per user, but this is definitely not something that can be achieved with tags.

Théo Zimmermann (Feb 20 2019 at 14:36):

That being said we can search issues by number of :+1: (is:issue is:open sort:reactions-+1-desc ) which could serve as an indicator of the demand among users if it was used more often.

Last updated: Oct 12 2024 at 13:01 UTC