Re: Bug management for inkscape/inkscape

Am 19.02.2019 um 01:25 schrieb Bryce Harrington:
> 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:

  * highly detailed development plans should go into inkscape/inkscape
  * off-the-cuff random ideas and suggestions go into inkscape/inbox. If
    they have a lot of supporters (or our bug wranglers indentify them
    as valuable), they're discussed, the development goal is clearly
    defined and then they're moved/re-filed into inkscape/inkscape.

> 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

_______________________________________________
Inkscape-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/inkscape-devel