Some additional bug management questions needing decided are included in this infra bug report: https://gitlab.com/inkscape/infra/services/issues/4
Thanks, I missed that one. I added some thougts.
[Milestones] I'm a little unsure of how much we are going to be able to rely on people remembering to do this, though. Are there other ideas for how we could either enforce it, or implement something that'd do it mechanically for us?
Well not any more or less than we could before... Milestones were manually set on LP, too.
I hope we can count on everybody to be at least as disciplined. On GitLab it should be even easier, as one does not need special permissions to set milestones (only the Inkscape Bug Team could on LP), so all developers can add them.
If there's an automated way that would obviously be great, but as GitLab does not differentiate between "closed/fixed" and "closed/invalid" it might be hard to get right.
[Importance] "Blocker" should not be used here; it's more something that should be reserved for the discretion of the release management team. It shouldn't be designatable by reporters or bug triagers.
Sorry, I didn't explain well enough:
In my suggestion there are only four "official" importance labels
(Critical / High / Medium / Low).
However GitLab has a concept of "label priority" [1] that can be
used for sorting. I simply suggested that "Blocker" would always
automatically bet sorted to the top (above "critical") and
"Feature requests" (if we want them) to the bottom (below "low")
of the list.
[1] https://docs.gitlab.com/ee/user/project/labels.html#label-priority
Every bug is of utmost importance to whomever reports it, and so it's natural to want your ticket to move to the head of the queue. Having a "Blocker" state settable by bug reporters is awfully tempting to achieve this.
On GitLab you need at least "Reporter" rights to add labels to an issue. Regular users could not tamper with the priority of their reports. This is something I'd reserve for established bug wranglers and developers themselves.
My guess is that developers care less about the importance level assigned to a bug (unless its marked Critical), and more about if the issue is a recent regression, or is against the section of code they've been focusing on lately, or has an active user to engage with, or needs an urgent fix.
Yes, however it helps bug wranglers a lot if bugs are assigned a
priority, it's useful in the release process and for writing the
release notes, and it simplifies searching the tracker. The
importance gives me quick hints on what to expect and if I'm
looking through the tracker searching for a certain class of crash
issues, I can exclude "medium/low" importance bugs from my search.
Also I do not agree that developers do not care about the importance level. After all we are *tracking* bugs in order to fix them, and that does not only include regressions and code we've worked on recently.
I'm not sure labels are effective for tracking any of those,
Well, obviously they don't track code experience of individual
developers or whom they communicate with currently, but apart from
that they are great to measure the severity of a bug (the bug team
did a great job defining priorities, see
https://inkscape.org/develop/bug-management/#Bug_importance). If
we worked them off from top to bottom, we certainly would use our
resources efficiently. ;-)
For Feature Requests we have this break out bug for reaching a decision: https://gitlab.com/inkscape/infra/services/issues/22 >From past discussions I've gathered the consensus is to hold feature requests separately from actual bugs.
That's mainly because everybody remembers the uncurated list of
"Wishlist" items from Launchpad. We obviously don't want that.
A well-written feature request on the other hand, that has been
fully discussed and defined (i.e. all parties agree on *what*
feature to implement and more importantly on *how* to implement
it) and is therefore ready for implementation has actual value. We
don't want those lost among the flood of Wishlist-like requests we
undoubtedly will amass in the inbox.
If you look at the current list of feature requests [2] (yes, we
already have some...) most of them are actionable items that just
need a developer. They're certainly too technical to go into
inkscape/inbox and would be lost there.
It's also a nice example for the "Help wanted" scheme that came up
in a branch of this e-mail thread: While we won't implement
certain features ourselves, we can clarify that they'd be
appreciated if somebody would do the heavy lifting for us!
You'll additionally notice that one of the feature requests was
actually filed by me - it's a project I'd like to work on in
future and I filed it in our issue tracker to keep track of it and
give others the possibility to comment if they have something to
contribute. Where else should I've gone with this? I feel the
issue tracker is the logical place...
[2] https://gitlab.com/inkscape/inkscape/issues?label_name%5B%5D=feature+request
"Feature requests" actually comprise a spectrum from highly detailed development plans, down to off-the-cuff random ideas and suggestions. Part of what needs decided is what slice(s) of that spectrum we wish to track, and where we want to track them.
Per the above, I think:
My guess is if we allow some feature requests to commingle with the bugs, it will be hard to judge what should and shouldn't be included, so we could end up with a lot more piled into the tracker than we want. "Only Actual Bugs in the Issue Tracker" is a clear distinction that will be easier to control, I think. But I think we do need someplace for them to end up.
Well, while it would be clear distinction, you posed the crucial question yourself: Where do actionable feature requests go? inkscape/inbox certainly isn't the place where we'll be able to efficiently work with them. Yet another tracker? Seems awfully redundant (we still have to see if the inbox plays out...). I think as long as we apply some common sense as to what feature requests we keep and which we move to inkscape/inbox this could be a totally workable solution until somebody can come up with something better.
o "incomplete": We have "Need info" but such bugs should usually not be kept in "inkscape/inkscape" for extended periods of time (if the info is not given, close or move back to "inbox")Yes, agreed in general. However, there are many situations where the bug is pretty well defined, and easily reproducible, but there still isn't enough info for the developer to work on it. E.g. they may need the user to run a special build, or test out a diagnostic patch, or something.
Well at that point the bug can be considered confirmed and the developer is free to communicate with users in the issue however they want. "Need info" is only meant for bugs that need more info to be confirmed and/or replicated (i.e. such bugs that are actually not supposed to be in inkscape/inkscape). However we have people filing directly into inkscape/inkscape and I realize moving an issue that looks valid but could not yet be fully confirmed to inbox, only to move it back a day later is useless, so this is sort of a concession towards those users. If they don't provide the information we can still move it after a week or so.
Where do you think we should document these bug management guidelines? A file in the inkscape/doc directory? Or wiki?
Basically that's https://inkscape.org/develop/bug-management/
For everything else I'd usually suggest the (Media)Wiki.
However in this particular case I'd actually consider using a GitLab Wiki page as it gives use some nice features like directly linking labels by just writing "~labelname" in the Markdown, which will produce the visual representation of that label linked to the corresponding search page in the issue tracker (we could obviously emulate such functionality on the website, but it would mean unnecessary additional effort). Also having the tracker documentation alongside the tracker itself seems to make some sense...
Cheers,
Patrick