Re: Bug management for inkscape/inkscape

Am 18.02.19 um 21:37 schrieb [email protected]:
> MY only addition to this important discussion is this:
> 
> We need a way to communicate to users that a problem is important to
> the project, would be useful and progressive if it was done, but for
> which we do not have the resources to make it happen.
> 
> The label: "Too Expensive" doesn't really tick the boxes for me.

- What about 'needs project lead' or 'needs contributors'?

> The reason why I think this is important is because quite often we have
> bugs that just sort of kick around for years and years, and there's no
> understanding from users about their responsibility to stop expecting
> free-riding on volunteer maintenance and developer time and start
> taking responsibility somewhat for raising the needed resources to get
> problems attention.
> 
> I just don't know how to communicate this fact well enough.
> 
> The converse would be a bug that would be marked "If we fixed this the
> project would be worse off, so we won't fix it" but more polite. The
> Won't Fix label in LP was always contentious for being too blunt for
> most users.

- Maybe just give a polite reason in the last comment, lock it, and close?

Maren

> Best Regards, Martin Owens
> 
> On Mon, 2019-02-18 at 20:27 +0100, Patrick Storz wrote:
>> Hi all,
>> it seems the message of our move of issue tracking to GitLab is
>> slowly spreading and we're seeing a steady flow of new reports in our
>> inkscape/inkscape issue tracker on Gitlab (
>> https://gitlab.com/inkscape/inkscape/issues).
>> As most of us had the opportunity to get some first-hand experience
>> with the new issue tracking by now and with the amount of bugs still
>> being manageable, it seems to be a good time to discuss and decide on
>> some guidelines for this tracker, so we can make most efficient use
>> of it.
>> Having worked with the tracker fo some time here's my list of items
>> (in no particular order) that I feel need attention. Please add to it
>> as needed and most importantly discuss, so we can find solutions that
>> work well for all of us. (We can obviously break individual topics
>> out into GitLab issues eventually, once we have set a rough
>> direction).
>> Milestones:
>> On Launchpad (LP) we used Milestones for targeting bugs (only
>> occasionally, though) but more importantly for tracking in which
>> release a fix landed. The latter seems of particular importance, as
>> release notes rely on it heavily.
>> I suggest to continue this practice and expand it to merge requests.
>> However this requires us all to make sure to actually set milestones
>> properly. Currently we often just close bugs without giving it
>> further thought (GitLab even does that automatically for us if a
>> suitable commit message is used), which would make it almost
>> impossible to keep track of the issues fixed in a particular release.
>> Even more so for MRs...
>>
>> Importance:
>> I feel that we need some mechanism to prioritize bugs. What is your
>> take on creating a set of prioritized labels of the form "Importance:
>> High" to replace LPs importance field?
>> I propose to use "Critical -> High -> Medium -> Low". Even above
>> critical I'd put the already existing label "Blocker". At the end of
>> the list I'd rank "Feature request". Does this sound reasonable? Or
>> is it too fine grained? Is handling "Blocker" and "Feature request"
>> as additional importance labels fine or should they be separate?
>>
>> Labels:
>> A general question is what labels we want to apply and how many there
>> should be. I'm a bit torn here, as a short list makes it easier to
>> keep track of the existing labels and avoids similar issues being
>> tagged differently, especially if there are multiple similar choices
>> or one tag is a sub/superset of another. A longer list would help us
>> categorize issues better though. (For example: Do we want a tag for
>> every packaging option we have, e.g. AppImage, Flatpak, msi, exe,
>> Windows Store, ...? Do we want a tag for every Linux distribution or
>> just a single "Linux" tag?).
>> Another question is if we want to categorize them (e.g. "OS/Linux",
>> "OS/Windows", "OS/Mac") or if we strip the category?  The former
>> ensures similar tags are sorted together (otherwise they're sorted
>> alphabetically) and *if* one remembers the category name it makes it
>> easy to get all relevant tags by simply typing "OS", but then again
>> tagging with just "Windows" seems more natural and the category might
>> add noise. Also it obviously requires some thought in order
>> to           create useful categories (in contrast to just applying
>> "random" tags that fit and creating new ones on-the-fly). As I'm
>> somebody who likes order I tend to prefer categorization, but this is
>> something I'd like your opinion on. (Important note: The search is
>> clever enough to give you "OS/Windows" if you search for "win").
>>
>> Status
>> On LP we had a detailed status field (new, confirmed, triaged, in
>> progress, fix commited, fix released - also: incomplete, opinion,
>> invalid, won't fix). Which of those do we want to replicate in GitLab
>> (and how?). We could obviously create a label for each of them, but I
>> have a feeling without a dedicated field it'd not be used
>> consistently.
>> One idea:
>> "new/confirmed" should be covered by "inkscape/inkscape" vs
>> "inkscape/inbox". Only confirmed issues should ever end up in
>> "inkscape/inkscape" (everything else should be confirmed or moved to
>> the inbox for triaging).
>> "triaged" would be replaced by the presence (or absence) of an
>> "Importance:" label should we choose to use them.
>> "in progress": We already have a corresponding label and could use
>> it. Alternatively we could define that all assigned bugs are "in
>> progress" (i.e. only assign bugs if the assignee is going to work on
>> them eventually; un-assign otherwise)
>> "fix commited/fix released": I don't know how to replicate this
>> reasonably. Is it even required?
>> "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")
>> "opinion": should never exist in "inkscape/inkscape"
>> "invalid": Do we need a label? Or shall we just close in this case
>> and forget about it?
>> "won't fix": should usually not make it into "inkscape/inkscape" - do
>> we want a label or shall we just close (i.e. same question as as for
>> invalid?)
>>
>> Assignee
>> As suggested above we could use the assignee field to put devs who
>> are going to work on an issue eventually (i.e. indicate "this issue
>> is being looked into / will be looked into shortly").
>> Alternatively we could use it to indicate devs who are likely to be
>> able to fix the issue and are most suited for detailed triaging and
>> further investigation (i.e. indicate "we know somebody who might be
>> able to help, please wait until they find the time to check"). This
>> could be used to distribute and direct the workload a bit. However we
>> can likely do that with simple @mentioning?
>>
>> Sorry for the long text (I hope you all read up to this ;-)), it
>> certainly got longer than intended... I'm looking forward to your
>> opinions, though!
>> Cheers
>> Patrick
>>
>>
>> _______________________________________________
>> Inkscape-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> 
> 
> 
> _______________________________________________
> Inkscape-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>