7:27 p.m.
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:
*
o 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?).
o 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:
o "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).
o "triaged" would be replaced by the presence (or absence) of an
"Importance:" label should we choose to use them.
o "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)
o "fix commited/fix released": I don't know how to replicate this
reasonably. Is it even required?
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")
o "opinion": should never exist in "inkscape/inkscape"
o "invalid": Do we need a label? Or shall we just close in this
case and forget about it?
o "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
8:37 p.m.
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.
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.
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
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
11:32 p.m.
Am 18.02.19 um 21:37 schrieb doctormo@...400...:
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
> Inkscape-devel(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
2:33 a.m.
Am 19.02.2019 um 00:32 schrieb Maren Hachmann:
Am 18.02.19 um 21:37 schrieb doctormo@...400...:
> 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?
+1, works in most cases!
I'd not even lock the issue (that can be misinterpreted and blocks valid
comments). Let's reserve that option for the occasional problematic case
where the reporter won't stop arguing.
2:30 a.m.
Am 18.02.2019 um 21:37 schrieb doctormo@...400...:
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.
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.
We already have "help wanted" [1] - would this be suitable?
I've seen this label being used successfully in other projects:
* On the one hand it's a good way to mark a bug as valid but express
that it's not a priority and might not be fixed anytime soon (or at
all) due to lack of time and/or knowledge in that specific area.
* On the other hand it encourages people wo *might* have time and/or
knowledge at their hands to submit a fix.
[1] https://gitlab.com/inkscape/inkscape/issues?label_name%5B%5D=help+wanted
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.
Well, there's just no way to let people down easy in this case... We
can't tell them that we won't fix their issue and not tell them at the
same time ;-)
The only thing that came close was the "opinion" status in LaunchPad
which was as spongy as it gets, and often was what triggered unnecessary
discussions in the first place.
Personally I appreciate projects that clearly communicate if issues are
"won't fix" as long as they give a reason. I might still disagree with
their reasoning, but at least I know what to expect (or rather what not
to expect). The worst are projects that close bugs without giving a
reason. Only slightly better are projects that never dare to close a bug
and keep people hanging forever not knowing what the actual status of a
bug is as a consequence (oh yes, Inkscape is - or at least was - such a
project ;-) . Maybe we can change something about this now.)
Cheers
Patrick
8:36 p.m.
I just don't know how to communicate this fact well enough.
"Developers Wishlist" ?
brynn
-----Original Message-----
From: doctormo@...400...
Sent: Monday, February 18, 2019 1:37 PM
To: Patrick Storz ; Inkscape-devel
Subject: Re: [Inkscape-devel] Bug management for inkscape/inkscape
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.
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.
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
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
12:25 a.m.
Some additional bug management questions needing decided are included in
this infra bug report:
https://gitlab.com/inkscape/infra/services/issues/4
More comments inline below:
On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
Having worked with the tracker fo some time here's my list of
items (in no
particular order) that I feel need attention.
* *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...
Yes, the workflow here is less structured than we had with
Launchpad.
I agree that adding milestone labels is a good practice that we should
recommend.
Linking to a MR, or even just pasting in the git commit message + SHA
can be vital not only for communicating that the issue is fixed, but
also where to find the fix (handy for packagers needing to cherrypick).
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?
* *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?
"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.
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.
However, in most cases I think what people really want is to note that
they feel their issue is "Urgent", and maybe a "Regression". Those
might be more practical, useful tags.
(We may also want to have an escalation process, separate from labeling,
for the truly horrendous problems. However, between RocketChat and the
mailing lists I suspect we're ok for now. This is already mentioned in
inkscape/infra/services/issues/4).
Beyond that, I think "Critical" + Milestone (+ Assignee) should be
adequate for identifying ultra-severe bugs. If we have so many Critical
bugs that we need yet another state... well I think we must have bigger
problems. ;-)
So, I think your four state list of importances is good, and will be
straightforward to match with incoming Launchpad bugs. In SourceForge
we had a 10-point level for importance, but honestly that was too fine
grained and we mostly just used 3,6,9 iirc.
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.
I'm not sure labels are effective for tracking any of those, although
I've noticed some bug trackers (Bugzilla I think) have importance and
urgency as separate fields. Personally, for Inkscape, I think tracking
urgency gets a bit fiddly. We don't have a strictly managed bug
workflow, so it's very much a judgment call and won't map very well to
reality. And, if we did want a stricter workflow we'd probably best
look at the existing kanban functionality in gitlab first.
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.
"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.
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.
* *Labels:
*
o 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?).
Yes, this is a good question.
As a general philosophy, it may help to think, "Will this label help
towards getting the bug closed?"
I could see how having labels for issues specific to particular
packaging systems would be helpful - they'd enable those maintainers to
search for their bugs, and enable developers to ignore them. However, I
also wonder if it would be better if the packagers themselves had their
own separate bug trackers that focus on problems specific to that
package. For Ubuntu, Fedora, etc. there are already external bug
trackers (Launchpad and Bugzilla), and no need to duplicate efforts
there; but for non-Linux packages it might make more sense.
Where this may crop up in particular is for serious bugs that are fixed
in master, but need to be cherrypicked and hotpatched into the
packaging. We'd want those types of bugs marked Closed in our main
tracker since they are, indeed, resolved, but the packager would want to
have an open bug until they've had a chance to tackle it.
Beyond that, and in general, there is probably a balance between
"adequately categorized" and "over categorized", which is going to
depend a lot on the workflow of developers. For example,
labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful,
whereas labels for what part of the UI the issue appears in may be
less helpful.
So, using the general philosophy mentioned above, I think labels should
be added where they enable developers to filter large classes of
issues they do or do not care about. I imagine this could include
crashes, regressions, SVG spec problems, file I/O, etc.
o 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").
I've been using the web interface for adding labels, so if they are
prefixed with "OS/" that seems not to be a problem there. Being able to
organize them alphabetically seems really handy, and adopting a
consistent scheme will aid predictability. Once one got used to the
convention, then even tagging via slash commands or via email (if that's
possible) should be sufficiently convenient.
* *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:
o "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).
+1 agreed
o "triaged" would be replaced by the presence (or
absence) of an
"Importance:" label should we choose to use them.
Yes, WFM.
o "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)
In my experience developers are horrible about remembering to toggle
this state when they're actually working on a bug. It is usually pretty
obvious in context since they'll be commenting on it or have an attached
MR under way.
There are probably situations and development workflows where it makes
sense to have this. It may be useful if we're utilizing kanban, for
instance.
If developers feel it helps them organize their bugs they're currently
working on vs. ones they plan to do later, it may be worth having this
or similar tag. If not, then it's a superfluous tag we should drop.
o "fix commited/fix released": I don't know how to
replicate this
reasonably. Is it even required?
I don't know how to replicate it either. I'd call it a nice-to-have
rather than required.
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.
o "opinion": should never exist in
"inkscape/inkscape"
o "invalid": Do we need a label? Or shall we just close in this
case and forget about it?
o "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?)
There are so many different reasons why a bug might get closed. In
addition to those three is also "Not our bug" and "Not actually a
bug".
I don't think we need labels for each contextual reason.
Better practice would be to include a message at time of closure
indicating a) the fix (e.g. git commit msg + SHA), or b) a short
explanation of the reason why it is being closed.
* *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?
I tend to prefer letting developers assign themselves bugs, except for
specific situations (like if they've created a regression, or if the
release team needs to direct attention on an urgent matter).
So, I really like the @mentioning approach. It flags attention without
committing them to owning the issue.
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!
Thanks, all good issues I have been wondering about too.
Where do you think we should document these bug management guidelines?
A file in the inkscape/doc directory? Or wiki?
Bryce
1:34 a.m.
Am 19.02.19 um 01:25 schrieb Bryce Harrington:
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?
- One option for enforcement / encouragement would be a commit message
template:
https://thoughtbot.com/blog/better-commit-messages-with-a-gitmessage-temp...
(I'd love those, as they'd enable me to better understand what a commit
is about - they could also already include the shortcut for 'closing' etc.)
Maren
2:38 a.m.
Am 19.02.2019 um 02:34 schrieb Maren Hachmann:
Am 19.02.19 um 01:25 schrieb Bryce Harrington:
> 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?
- One option for enforcement / encouragement would be a commit message
template:
https://thoughtbot.com/blog/better-commit-messages-with-a-gitmessage-temp...
(I'd love those, as they'd enable me to better understand what a commit
is about - they could also already include the shortcut for 'closing' etc.)
Maren
How'd that set a milestone?
I welcome the idea, though (didn't know that existed)! Bad commit
messages are all too common, whereas writing good commit messages isn't
that hard after all and they can an invaluable source of information if
done properly.
4:14 a.m.
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
6:20 p.m.
I've went ahead, cleared up some labels and implemented the Importance
labels we were discussing.
I've already gone through the list of open bugs and applied the scheme,
so they can be conveniently sorted by "label priority" now:
https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
Obviously there's still a lot of work which I hope we can tackle
together. Most importantly we need to urge ourselves to keep our tracker
clean and update bug status whenever possible (I've found a lot of
untriaged or only partially triaged bugs already, and even some that
have been fixed, but not updated accordingly).
On the upside we're receiving some invaluable help by Nathan Lee
(https://gitlab.com/nathanal) who does not only do a great job at
confirming and testing new reports, but also submitted various patches
already!
Also Qantas94Heavy (https://gitlab.com/Qantas94Heavy) started to sift
through the reports on Launchpad (even ahead of the nbug migration
game!) and is doing some amazing progress.
Cheers,
Patrick
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
More comments inline below:
On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
> Having worked with the tracker fo some time here's my list of items (in no
> particular order) that I feel need attention.
>
> * *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...
Yes, the workflow here is less structured than we had with
Launchpad.
I agree that adding milestone labels is a good practice that we should
recommend.
Linking to a MR, or even just pasting in the git commit message + SHA
can be vital not only for communicating that the issue is fixed, but
also where to find the fix (handy for packagers needing to cherrypick).
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?
> * *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?
"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.
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.
However, in most cases I think what people really want is to note that
they feel their issue is "Urgent", and maybe a "Regression". Those
might be more practical, useful tags.
(We may also want to have an escalation process, separate from labeling,
for the truly horrendous problems. However, between RocketChat and the
mailing lists I suspect we're ok for now. This is already mentioned in
inkscape/infra/services/issues/4).
Beyond that, I think "Critical" + Milestone (+ Assignee) should be
adequate for identifying ultra-severe bugs. If we have so many Critical
bugs that we need yet another state... well I think we must have bigger
problems. ;-)
So, I think your four state list of importances is good, and will be
straightforward to match with incoming Launchpad bugs. In SourceForge
we had a 10-point level for importance, but honestly that was too fine
grained and we mostly just used 3,6,9 iirc.
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.
I'm not sure labels are effective for tracking any of those, although
I've noticed some bug trackers (Bugzilla I think) have importance and
urgency as separate fields. Personally, for Inkscape, I think tracking
urgency gets a bit fiddly. We don't have a strictly managed bug
workflow, so it's very much a judgment call and won't map very well to
reality. And, if we did want a stricter workflow we'd probably best
look at the existing kanban functionality in gitlab first.
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.
"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.
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.
> * *Labels:
> *
> o 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?).
Yes, this is a good question.
As a general philosophy, it may help to think, "Will this label help
towards getting the bug closed?"
I could see how having labels for issues specific to particular
packaging systems would be helpful - they'd enable those maintainers to
search for their bugs, and enable developers to ignore them. However, I
also wonder if it would be better if the packagers themselves had their
own separate bug trackers that focus on problems specific to that
package. For Ubuntu, Fedora, etc. there are already external bug
trackers (Launchpad and Bugzilla), and no need to duplicate efforts
there; but for non-Linux packages it might make more sense.
Where this may crop up in particular is for serious bugs that are fixed
in master, but need to be cherrypicked and hotpatched into the
packaging. We'd want those types of bugs marked Closed in our main
tracker since they are, indeed, resolved, but the packager would want to
have an open bug until they've had a chance to tackle it.
Beyond that, and in general, there is probably a balance between
"adequately categorized" and "over categorized", which is going to
depend a lot on the workflow of developers. For example,
labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful,
whereas labels for what part of the UI the issue appears in may be
less helpful.
So, using the general philosophy mentioned above, I think labels should
be added where they enable developers to filter large classes of
issues they do or do not care about. I imagine this could include
crashes, regressions, SVG spec problems, file I/O, etc.
> o 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").
I've been using the web interface for adding labels, so if they are
prefixed with "OS/" that seems not to be a problem there. Being able to
organize them alphabetically seems really handy, and adopting a
consistent scheme will aid predictability. Once one got used to the
convention, then even tagging via slash commands or via email (if that's
possible) should be sufficiently convenient.
> * *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:
> o "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).
+1 agreed
> o "triaged" would be replaced by the presence (or absence) of an
> "Importance:" label should we choose to use them.
Yes, WFM.
> o "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)
In my experience developers are horrible about remembering to toggle
this state when they're actually working on a bug. It is usually pretty
obvious in context since they'll be commenting on it or have an attached
MR under way.
There are probably situations and development workflows where it makes
sense to have this. It may be useful if we're utilizing kanban, for
instance.
If developers feel it helps them organize their bugs they're currently
working on vs. ones they plan to do later, it may be worth having this
or similar tag. If not, then it's a superfluous tag we should drop.
> o "fix commited/fix released": I don't know how to replicate
this
> reasonably. Is it even required?
I don't know how to replicate it either. I'd call it a nice-to-have
rather than required.
> 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.
> o "opinion": should never exist in "inkscape/inkscape"
> o "invalid": Do we need a label? Or shall we just close in this
> case and forget about it?
> o "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?)
There are so many different reasons why a bug might get closed. In
addition to those three is also "Not our bug" and "Not actually a
bug".
I don't think we need labels for each contextual reason.
Better practice would be to include a message at time of closure
indicating a) the fix (e.g. git commit msg + SHA), or b) a short
explanation of the reason why it is being closed.
> * *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?
I tend to prefer letting developers assign themselves bugs, except for
specific situations (like if they've created a regression, or if the
release team needs to direct attention on an urgent matter).
So, I really like the @mentioning approach. It flags attention without
committing them to owning the issue.
> 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!
Thanks, all good issues I have been wondering about too.
Where do you think we should document these bug management guidelines?
A file in the inkscape/doc directory? Or wiki?
Bryce
11:21 p.m.
On Sun, Mar 10, 2019 at 07:20:48PM +0100, Patrick Storz wrote:
I've went ahead, cleared up some labels and implemented the
Importance
labels we were discussing.
I've already gone through the list of open bugs and applied the scheme, so
they can be conveniently sorted by "label priority" now:
https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
Great, was just looking at bugs and noticed the improved organization.
Obviously there's still a lot of work which I hope we can tackle
together.
Most importantly we need to urge ourselves to keep our tracker clean and
update bug status whenever possible (I've found a lot of untriaged or only
partially triaged bugs already, and even some that have been fixed, but not
updated accordingly).
Agreed.
Btw, there's a mobile app for gitlab. Handy for reviewing stuff in
Inbox when you're out and about.
On the upside we're receiving some invaluable help by Nathan Lee
(https://gitlab.com/nathanal) who does not only do a great job at confirming
and testing new reports, but also submitted various patches already!
Also Qantas94Heavy (https://gitlab.com/Qantas94Heavy) started to sift
through the reports on Launchpad (even ahead of the nbug migration game!)
and is doing some amazing progress.
Excellent, it's always good seeing more people getting involved in triaging.
Btw, on the topic of feature requests, Ted, Martin, Tav, me, and others
had a discussion at hackfest on this in relation to keeping the roadmap
better updated, post-1.0, and sketched in some conceptual ideas.
Essentially, we'd build a gitlab issue board with the larger feature
plans, or "Big Ideas" as I think Ted called them. We speculated
experimenting with using the gitlab kanban for organizing them, but
however we do it this would replace (or at least augment) the current
Roadmap in wiki.
We also recognized that with a volunteer organization where we encourage
devels to work on what interests them, rather than giving top-down
directives, our "roadmap" is more akin to a "forecast". You may have
noticed a "ToForecast" label was added to the bugtracker; this concept
is where that term is coming from.
For planning purposes, we discussed establishing a regular monthly
meeting cycle to review feature proposals and scope out development
priorities. This would be the "Forecast Party" that Martin mentioned in
email last week. We also recognized that for UI/UX sometimes the
blocker on even easy things is to just have a decision made, so a
thought was that this event could include reviewing the month's UI/UX
change proposals that want to have decisions made, and make them.
Hit me with any other ideas. I'll post a kickoff email for the first
meeting, for some time this month.
Bryce
Cheers,
Patrick
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
>
> More comments inline below:
>
> On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
> > Having worked with the tracker fo some time here's my list of items (in no
> > particular order) that I feel need attention.
> >
> > * *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...
> Yes, the workflow here is less structured than we had with
> Launchpad.
>
> I agree that adding milestone labels is a good practice that we should
> recommend.
>
> Linking to a MR, or even just pasting in the git commit message + SHA
> can be vital not only for communicating that the issue is fixed, but
> also where to find the fix (handy for packagers needing to cherrypick).
>
> 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?
>
>
> > * *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?
> "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.
>
> 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.
>
> However, in most cases I think what people really want is to note that
> they feel their issue is "Urgent", and maybe a "Regression".
Those
> might be more practical, useful tags.
>
> (We may also want to have an escalation process, separate from labeling,
> for the truly horrendous problems. However, between RocketChat and the
> mailing lists I suspect we're ok for now. This is already mentioned in
> inkscape/infra/services/issues/4).
>
> Beyond that, I think "Critical" + Milestone (+ Assignee) should be
> adequate for identifying ultra-severe bugs. If we have so many Critical
> bugs that we need yet another state... well I think we must have bigger
> problems. ;-)
>
>
> So, I think your four state list of importances is good, and will be
> straightforward to match with incoming Launchpad bugs. In SourceForge
> we had a 10-point level for importance, but honestly that was too fine
> grained and we mostly just used 3,6,9 iirc.
>
> 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.
>
> I'm not sure labels are effective for tracking any of those, although
> I've noticed some bug trackers (Bugzilla I think) have importance and
> urgency as separate fields. Personally, for Inkscape, I think tracking
> urgency gets a bit fiddly. We don't have a strictly managed bug
> workflow, so it's very much a judgment call and won't map very well to
> reality. And, if we did want a stricter workflow we'd probably best
> look at the existing kanban functionality in gitlab first.
>
>
> 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.
>
> "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.
>
> 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.
>
> > * *Labels:
> > *
> > o 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?).
> Yes, this is a good question.
>
> As a general philosophy, it may help to think, "Will this label help
> towards getting the bug closed?"
>
> I could see how having labels for issues specific to particular
> packaging systems would be helpful - they'd enable those maintainers to
> search for their bugs, and enable developers to ignore them. However, I
> also wonder if it would be better if the packagers themselves had their
> own separate bug trackers that focus on problems specific to that
> package. For Ubuntu, Fedora, etc. there are already external bug
> trackers (Launchpad and Bugzilla), and no need to duplicate efforts
> there; but for non-Linux packages it might make more sense.
>
> Where this may crop up in particular is for serious bugs that are fixed
> in master, but need to be cherrypicked and hotpatched into the
> packaging. We'd want those types of bugs marked Closed in our main
> tracker since they are, indeed, resolved, but the packager would want to
> have an open bug until they've had a chance to tackle it.
>
>
> Beyond that, and in general, there is probably a balance between
> "adequately categorized" and "over categorized", which is going
to
> depend a lot on the workflow of developers. For example,
> labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful,
> whereas labels for what part of the UI the issue appears in may be
> less helpful.
>
> So, using the general philosophy mentioned above, I think labels should
> be added where they enable developers to filter large classes of
> issues they do or do not care about. I imagine this could include
> crashes, regressions, SVG spec problems, file I/O, etc.
>
> > o 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").
> I've been using the web interface for adding labels, so if they are
> prefixed with "OS/" that seems not to be a problem there. Being able to
> organize them alphabetically seems really handy, and adopting a
> consistent scheme will aid predictability. Once one got used to the
> convention, then even tagging via slash commands or via email (if that's
> possible) should be sufficiently convenient.
>
> > * *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:
> > o "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).
> +1 agreed
>
> > o "triaged" would be replaced by the presence (or absence) of
an
> > "Importance:" label should we choose to use them.
> Yes, WFM.
>
> > o "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)
> In my experience developers are horrible about remembering to toggle
> this state when they're actually working on a bug. It is usually pretty
> obvious in context since they'll be commenting on it or have an attached
> MR under way.
>
> There are probably situations and development workflows where it makes
> sense to have this. It may be useful if we're utilizing kanban, for
> instance.
>
> If developers feel it helps them organize their bugs they're currently
> working on vs. ones they plan to do later, it may be worth having this
> or similar tag. If not, then it's a superfluous tag we should drop.
>
>
> > o "fix commited/fix released": I don't know how to
replicate this
> > reasonably. Is it even required?
> I don't know how to replicate it either. I'd call it a nice-to-have
> rather than required.
>
> > 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.
>
> > o "opinion": should never exist in
"inkscape/inkscape"
> > o "invalid": Do we need a label? Or shall we just close in
this
> > case and forget about it?
> > o "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?)
> There are so many different reasons why a bug might get closed. In
> addition to those three is also "Not our bug" and "Not actually a
bug".
>
> I don't think we need labels for each contextual reason.
>
> Better practice would be to include a message at time of closure
> indicating a) the fix (e.g. git commit msg + SHA), or b) a short
> explanation of the reason why it is being closed.
>
> > * *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?
> I tend to prefer letting developers assign themselves bugs, except for
> specific situations (like if they've created a regression, or if the
> release team needs to direct attention on an urgent matter).
>
> So, I really like the @mentioning approach. It flags attention without
> committing them to owning the issue.
>
>
> > 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!
> Thanks, all good issues I have been wondering about too.
>
> Where do you think we should document these bug management guidelines?
> A file in the inkscape/doc directory? Or wiki?
>
> Bryce
6:05 p.m.
On Tue, Mar 12, 2019 at 12:42:36AM +0100, Mihaela wrote:
The "Big Ideas" sound like a good candidate for the Epic
feature in
GitLab, although you need to upgrade to use it (maybe GitLab could
sponsor Inkscape in this way? Any other useful GitLab features that
aren't free?)
We thought about that, although I figure if we keep to a high level of
granularity we can probably just use a plain single kanban board. If it
turns out everyone really likes kanban and we want to use it heavier, we
could consider using gitlab epics, or perhaps one of the many other
kanban services out there.
But what we need to decide right now is what to call it. We didn't have
any solid thoughts, but a few ideas are: "Big ideas", "Blueprints",
"Features", ... Do you have any good ideas?
Bryce
Maybe Milestones could be used to "gather up" related
Issues in a
similar way. It all depends on how you decide to use the tools...
Here is a good (short) article about GitLab uses Epics for their UX
development:
[1] How the GitLab UX team uses epics
how to work iteratively, making the smallest changes possible, while
maintaining a holistic view of the application
efficient way to plan, track, and execute a group of thematically
related issues
With a holistic view of what we wanted to achieve, we could go back
and find issues in the backlog that were critical to the vision.
These issues were added to the epic and ordered according to
priority.
Mihaela
On 12. 03. 2019. 00:21, Bryce Harrington wrote:
On Sun, Mar 10, 2019 at 07:20:48PM +0100, Patrick Storz wrote:
I've went ahead, cleared up some labels and implemented the Importance
labels we were discussing.
I've already gone through the list of open bugs and applied the scheme, so
they can be conveniently sorted by "label priority" now:
[2]https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
Great, was just looking at bugs and noticed the improved organization.
Obviously there's still a lot of work which I hope we can tackle together.
Most importantly we need to urge ourselves to keep our tracker clean and
update bug status whenever possible (I've found a lot of untriaged or only
partially triaged bugs already, and even some that have been fixed, but not
updated accordingly).
Agreed.
Btw, there's a mobile app for gitlab. Handy for reviewing stuff in
Inbox when you're out and about.
On the upside we're receiving some invaluable help by Nathan Lee
([3]https://gitlab.com/nathanal) who does not only do a great job at confirming
and testing new reports, but also submitted various patches already!
Also Qantas94Heavy ([4]https://gitlab.com/Qantas94Heavy) started to sift
through the reports on Launchpad (even ahead of the nbug migration game!)
and is doing some amazing progress.
Excellent, it's always good seeing more people getting involved in triaging.
Btw, on the topic of feature requests, Ted, Martin, Tav, me, and others
had a discussion at hackfest on this in relation to keeping the roadmap
better updated, post-1.0, and sketched in some conceptual ideas.
Essentially, we'd build a gitlab issue board with the larger feature
plans, or "Big Ideas" as I think Ted called them. We speculated
experimenting with using the gitlab kanban for organizing them, but
however we do it this would replace (or at least augment) the current
Roadmap in wiki.
We also recognized that with a volunteer organization where we encourage
devels to work on what interests them, rather than giving top-down
directives, our "roadmap" is more akin to a "forecast". You may
have
noticed a "ToForecast" label was added to the bugtracker; this concept
is where that term is coming from.
For planning purposes, we discussed establishing a regular monthly
meeting cycle to review feature proposals and scope out development
priorities. This would be the "Forecast Party" that Martin mentioned in
email last week. We also recognized that for UI/UX sometimes the
blocker on even easy things is to just have a decision made, so a
thought was that this event could include reviewing the month's UI/UX
change proposals that want to have decisions made, and make them.
Hit me with any other ideas. I'll post a kickoff email for the first
meeting, for some time this month.
Bryce
Cheers,
Patrick
Am 19.02.2019 um 01:25 schrieb Bryce Harrington:
Some additional bug management questions needing decided are included in
this infra bug report:
[5]https://gitlab.com/inkscape/infra/services/issues/4
More comments inline below:
On Mon, Feb 18, 2019 at 08:27:26PM +0100, Patrick Storz wrote:
Having worked with the tracker fo some time here's my list of items (in no
particular order) that I feel need attention.
* *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...
Yes, the workflow here is less structured than we had with
Launchpad.
I agree that adding milestone labels is a good practice that we should
recommend.
Linking to a MR, or even just pasting in the git commit message + SHA
can be vital not only for communicating that the issue is fixed, but
also where to find the fix (handy for packagers needing to cherrypick).
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?
* *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?
"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.
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.
However, in most cases I think what people really want is to note that
they feel their issue is "Urgent", and maybe a "Regression". Those
might be more practical, useful tags.
(We may also want to have an escalation process, separate from labeling,
for the truly horrendous problems. However, between RocketChat and the
mailing lists I suspect we're ok for now. This is already mentioned in
inkscape/infra/services/issues/4).
Beyond that, I think "Critical" + Milestone (+ Assignee) should be
adequate for identifying ultra-severe bugs. If we have so many Critical
bugs that we need yet another state... well I think we must have bigger
problems. ;-)
So, I think your four state list of importances is good, and will be
straightforward to match with incoming Launchpad bugs. In SourceForge
we had a 10-point level for importance, but honestly that was too fine
grained and we mostly just used 3,6,9 iirc.
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.
I'm not sure labels are effective for tracking any of those, although
I've noticed some bug trackers (Bugzilla I think) have importance and
urgency as separate fields. Personally, for Inkscape, I think tracking
urgency gets a bit fiddly. We don't have a strictly managed bug
workflow, so it's very much a judgment call and won't map very well to
reality. And, if we did want a stricter workflow we'd probably best
look at the existing kanban functionality in gitlab first.
For Feature Requests we have this break out bug for reaching a decision:
[6]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.
"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.
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.
* *Labels:
*
o 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?).
Yes, this is a good question.
As a general philosophy, it may help to think, "Will this label help
towards getting the bug closed?"
I could see how having labels for issues specific to particular
packaging systems would be helpful - they'd enable those maintainers to
search for their bugs, and enable developers to ignore them. However, I
also wonder if it would be better if the packagers themselves had their
own separate bug trackers that focus on problems specific to that
package. For Ubuntu, Fedora, etc. there are already external bug
trackers (Launchpad and Bugzilla), and no need to duplicate efforts
there; but for non-Linux packages it might make more sense.
Where this may crop up in particular is for serious bugs that are fixed
in master, but need to be cherrypicked and hotpatched into the
packaging. We'd want those types of bugs marked Closed in our main
tracker since they are, indeed, resolved, but the packager would want to
have an open bug until they've had a chance to tackle it.
Beyond that, and in general, there is probably a balance between
"adequately categorized" and "over categorized", which is going to
depend a lot on the workflow of developers. For example,
labeling Gtk2, Gtk3, and Gtk4 issues distinctly would likely be useful,
whereas labels for what part of the UI the issue appears in may be
less helpful.
So, using the general philosophy mentioned above, I think labels should
be added where they enable developers to filter large classes of
issues they do or do not care about. I imagine this could include
crashes, regressions, SVG spec problems, file I/O, etc.
o 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").
I've been using the web interface for adding labels, so if they are
prefixed with "OS/" that seems not to be a problem there. Being able to
organize them alphabetically seems really handy, and adopting a
consistent scheme will aid predictability. Once one got used to the
convention, then even tagging via slash commands or via email (if that's
possible) should be sufficiently convenient.
* *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:
o "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).
+1 agreed
o "triaged" would be replaced by the presence (or absence) of an
"Importance:" label should we choose to use them.
Yes, WFM.
o "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)
In my experience developers are horrible about remembering to toggle
this state when they're actually working on a bug. It is usually pretty
obvious in context since they'll be commenting on it or have an attached
MR under way.
There are probably situations and development workflows where it makes
sense to have this. It may be useful if we're utilizing kanban, for
instance.
If developers feel it helps them organize their bugs they're currently
working on vs. ones they plan to do later, it may be worth having this
or similar tag. If not, then it's a superfluous tag we should drop.
o "fix commited/fix released": I don't know how to replicate this
reasonably. Is it even required?
I don't know how to replicate it either. I'd call it a nice-to-have
rather than required.
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.
o "opinion": should never exist in "inkscape/inkscape"
o "invalid": Do we need a label? Or shall we just close in this
case and forget about it?
o "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?)
There are so many different reasons why a bug might get closed. In
addition to those three is also "Not our bug" and "Not actually a
bug".
I don't think we need labels for each contextual reason.
Better practice would be to include a message at time of closure
indicating a) the fix (e.g. git commit msg + SHA), or b) a short
explanation of the reason why it is being closed.
* *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?
I tend to prefer letting developers assign themselves bugs, except for
specific situations (like if they've created a regression, or if the
release team needs to direct attention on an urgent matter).
So, I really like the @mentioning approach. It flags attention without
committing them to owning the issue.
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!
Thanks, all good issues I have been wondering about too.
Where do you think we should document these bug management guidelines?
A file in the inkscape/doc directory? Or wiki?
Bryce
_______________________________________________
Inkscape-devel mailing list
[7]Inkscape-devel(a)lists.sourceforge.net
[8]https://lists.sourceforge.net/lists/listinfo/inkscape-devel
References
1. https://about.gitlab.com/2018/03/19/use-cases-for-epics/
2. https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
3. https://gitlab.com/nathanal
4. https://gitlab.com/Qantas94Heavy
5. https://gitlab.com/inkscape/infra/services/issues/4
6. https://gitlab.com/inkscape/infra/services/issues/22
7. mailto:Inkscape-devel@lists.sourceforge.net
8. https://lists.sourceforge.net/lists/listinfo/inkscape-devel
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
6:55 p.m.
Am 13.03.2019 um 19:05 schrieb Bryce Harrington:
On Tue, Mar 12, 2019 at 12:42:36AM +0100, Mihaela wrote:
> The "Big Ideas" sound like a good candidate for the Epic feature in
> GitLab, although you need to upgrade to use it (maybe GitLab could
> sponsor Inkscape in this way? Any other useful GitLab features that
> aren't free?)
We thought about that, although I figure if we keep to a high level of
granularity we can probably just use a plain single kanban board. If it
turns out everyone really likes kanban and we want to use it heavier, we
could consider using gitlab epics, or perhaps one of the many other
kanban services out there.
But what we need to decide right now is what to call it. We didn't have
any solid thoughts, but a few ideas are: "Big ideas", "Blueprints",
"Features", ... Do you have any good ideas?
As you mention "blueprints" and "features": How do we prevent this
from
becoming one of the following?
* Launchpad Blueprints, where a huge amount of unsorted ideas ended
up, that nobody ever looked at.
* Launchpad "Wishlist" bugs, which were a vast amount of mostly
unactionable ideas of varying usefulness which were often not more
than a nice way of "closing" a report.
Also you're asking for names already - but I think nobody except for the
hackfest attendees knows what this feature is actually about and how
it's supposed to work in the end. Are you planning a more detailed
write-up on this?
From the things I read between the lines I especially wonder: How are
"ideas" selected? How does it differ from discussions we're having in
inbox already? What issues is it trying to solve in the first place
(i.e. why do we even need a new place)? And related to the above: What
do you want to do differently compared to previous models that will make
it more likely it'll work this time?
The same goes for the "Forecast" btw, which could use some explaining,
too, unless you want to explain it by doing "it" (whatever "it" might
be...)
Cheers
Patrick
8:40 p.m.
On Wed, Mar 13, 2019 at 07:55:25PM +0100, Patrick Storz wrote:
Am 13.03.2019 um 19:05 schrieb Bryce Harrington:
> On Tue, Mar 12, 2019 at 12:42:36AM +0100, Mihaela wrote:
> > The "Big Ideas" sound like a good candidate for the Epic feature
in
> > GitLab, although you need to upgrade to use it (maybe GitLab could
> > sponsor Inkscape in this way? Any other useful GitLab features that
> > aren't free?)
> We thought about that, although I figure if we keep to a high level of
> granularity we can probably just use a plain single kanban board. If it
> turns out everyone really likes kanban and we want to use it heavier, we
> could consider using gitlab epics, or perhaps one of the many other
> kanban services out there.
>
> But what we need to decide right now is what to call it. We didn't have
> any solid thoughts, but a few ideas are: "Big ideas",
"Blueprints",
> "Features", ... Do you have any good ideas?
As you mention "blueprints" and "features": How do we prevent this
from
becoming one of the following?
* Launchpad Blueprints, where a huge amount of unsorted ideas ended
up, that nobody ever looked at.
* Launchpad "Wishlist" bugs, which were a vast amount of mostly
unactionable ideas of varying usefulness which were often not more
than a nice way of "closing" a report.
Was thinking probably can follow the same process you suggested for the
main bug tracker. Everything goes into inbox, only the best, most
fleshed out (roadmap-ready) items would move on to this tracker.
Also you're asking for names already - but I think nobody except
for the
hackfest attendees knows what this feature is actually about and how it's
supposed to work in the end. Are you planning a more detailed write-up on
this?
Yep.
This is mostly just a continuation of the "What about feature requests"
question we've been punting on since before the transition, although it
came up at hackfest in context of the post-1.0 roadmap.
From the things I read between the lines I especially wonder: How
are
"ideas" selected? How does it differ from discussions we're having in
inbox
already? What issues is it trying to solve in the first place (i.e. why do
we even need a new place)? And related to the above: What do you want to do
differently compared to previous models that will make it more likely it'll
work this time?
The same goes for the "Forecast" btw, which could use some explaining, too,
unless you want to explain it by doing "it" (whatever "it" might
be...)
Martin posted about this on the 5th, as part of the summary about
Friendly Mentorship concept from the hackfest, but I can explain it in
more detail.
In talking about the roadmap, I'd pointed out that it doesn't generally
work very well as a top-down dictate, since developers tend to know what
they plan to work on already, so instead it works best if approached
more like a "forecast". People liked that term better than roadmap, and
it stuck in all the subsequent discussions.
Bryce
9:11 p.m.
Am 13.03.2019 um 21:40 schrieb Bryce Harrington:
Was thinking probably can follow the same process you suggested for
the
main bug tracker. Everything goes into inbox, only the best, most
fleshed out (roadmap-ready) items would move on to this tracker.
And what do we gain from having a separate tracker instead of using
issues at inkscape/inkscape with the "feature request" label (especially
in the scenario where we allow only fleshed out proposals)?
I feel that this is working well already (and probably in-line with the
"forecast" idea). For example I've added my own plans as "feature
requests" for increased visibility and to give others the chance to
comment. For other well-defined projects we don't have assignees yet,
but for example the request for a continuously-built flatpak release
already triggered some relevant discussion and might have gained us a
potential contributor who 's interested in implementing the feature.
As for splitting out feature requests into another sub-project I'm
afraid that it will actually decrease their visibility and makes it all
to easy to completely ignore them. Also it looses functionality, as we
won't be able to share the same labels / milestones easily (which mostly
apply to feature requests, too, I guess).
Looking forward to the write-up!
Martin posted about this on the 5th, as part of the summary about
Friendly Mentorship concept from the hackfest, but I can explain it in
more detail.
I remember. It read pretty vague, though, and I certainly don't
understand yet how the forecast (and the forecasting events) are meant
to work. That's why I asked.
In talking about the roadmap, I'd pointed out that it doesn't
generally
work very well as a top-down dictate, since developers tend to know what
they plan to work on already, so instead it works best if approached
more like a "forecast". People liked that term better than roadmap, and
it stuck in all the subsequent discussions.
That's the single thing I fully understood from Martin's explanation,
but what else does change except the name? ;-)
Our roadmap always was "what we should do", and we ended up mostly doing
something else, that's certainly not new. Does this simply mean devs are
encouraged to add what they want to work on to the forecast and we
abstain from adding "action items" for which we don't have assignees yet?
Could somebody elaborate more on the "forecast meetings"? Are they
simply meant as a monthly developer meetings (a bit like the board
meetings) where current and upcoming work can be discussed? Or is there
a more formal process involved? For example I've noticed the "to
forecast" label - how is it applied and what is the result of tagging an
issue report or feature request with it?
Cheers,
Patrick
9:48 p.m.
Names. New and Old are important.
Forecast party is an event where developers and users get together to
discuss specific features.
The schedule depends on the timing of the event.
A regular schedule will include 10 minutes at the start for which
problematic changes (things with code OR designs) can be shown and
quickly voted on. Presenters will be highly encouraged to post an
animated GIF to their flagged issue or merge request. Votes will be
posted to the issue, issues without GIFs will not be discussed. Votes
will be YES (change is good), NO (do not change) or RESEARCH (send the
idea to proper UX testing, should be very rare).
The rest of the time will be taken by discussion a single idea or
feature. The goal is to write up details into the forecast issue,
including doing research on how other programs handle the design, who
is interested or excited to work on the idea and what kind of release
schedule the feature if implemented would fall into.
The specific idea will be announce ahead of time.
The goal of the Forecast party is to increase visibility of
developments, to excite the developer community with new ideas and to
plan out when an exciting idea is a good idea to land.
This is only a very rough outline of the process I'm personally
thinking about.
Regards, Martin
On Wed, 2019-03-13 at 22:11 +0100, Patrick Storz wrote:
Am 13.03.2019 um 21:40 schrieb Bryce Harrington:
> Was thinking probably can follow the same process you suggested for
> the
> main bug tracker. Everything goes into inbox, only the best, most
> fleshed out (roadmap-ready) items would move on to this tracker.
And what do we gain from having a separate tracker instead of using
issues at inkscape/inkscape with the "feature request" label
(especially
in the scenario where we allow only fleshed out proposals)?
I feel that this is working well already (and probably in-line with
the
"forecast" idea). For example I've added my own plans as "feature
requests" for increased visibility and to give others the chance to
comment. For other well-defined projects we don't have assignees
yet,
but for example the request for a continuously-built flatpak release
already triggered some relevant discussion and might have gained us
a
potential contributor who 's interested in implementing the feature.
As for splitting out feature requests into another sub-project I'm
afraid that it will actually decrease their visibility and makes it
all
to easy to completely ignore them. Also it looses functionality, as
we
won't be able to share the same labels / milestones easily (which
mostly
apply to feature requests, too, I guess).
Looking forward to the write-up!
> Martin posted about this on the 5th, as part of the summary about
> Friendly Mentorship concept from the hackfest, but I can explain it
> in
> more detail.
I remember. It read pretty vague, though, and I certainly don't
understand yet how the forecast (and the forecasting events) are
meant
to work. That's why I asked.
> In talking about the roadmap, I'd pointed out that it doesn't
> generally
> work very well as a top-down dictate, since developers tend to know
> what
> they plan to work on already, so instead it works best if
> approached
> more like a "forecast". People liked that term better than
> roadmap, and
> it stuck in all the subsequent discussions.
That's the single thing I fully understood from Martin's
explanation,
but what else does change except the name? ;-)
Our roadmap always was "what we should do", and we ended up mostly
doing
something else, that's certainly not new. Does this simply mean devs
are
encouraged to add what they want to work on to the forecast and we
abstain from adding "action items" for which we don't have assignees
yet?
Could somebody elaborate more on the "forecast meetings"? Are they
simply meant as a monthly developer meetings (a bit like the board
meetings) where current and upcoming work can be discussed? Or is
there
a more formal process involved? For example I've noticed the "to
forecast" label - how is it applied and what is the result of tagging
an
issue report or feature request with it?
Cheers,
Patrick
_______________________________________________
Inkscape-devel mailing list
Inkscape-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
10:15 p.m.
Am 13.03.2019 um 22:48 schrieb doctormo@...400...:
Names. New and Old are important.
Forecast party is an event where developers and users get together to
discuss specific features.
The schedule depends on the timing of the event.
A regular schedule will include 10 minutes at the start for which
problematic changes (things with code OR designs) can be shown and
quickly voted on. Presenters will be highly encouraged to post an
animated GIF to their flagged issue or merge request. Votes will be
posted to the issue, issues without GIFs will not be discussed. Votes
will be YES (change is good), NO (do not change) or RESEARCH (send the
idea to proper UX testing, should be very rare).
The rest of the time will be taken by discussion a single idea or
feature. The goal is to write up details into the forecast issue,
including doing research on how other programs handle the design, who
is interested or excited to work on the idea and what kind of release
schedule the feature if implemented would fall into.
The specific idea will be announce ahead of time.
The goal of the Forecast party is to increase visibility of
developments, to excite the developer community with new ideas and to
plan out when an exciting idea is a good idea to land.
This is only a very rough outline of the process I'm personally
thinking about.
Regards, Martin
Thanks! This makes it a lot easier to understand the general idea!
One specific question though on the following:
Presenters will be highly encouraged to post an
animated GIF to their flagged issue or merge request.
How are presenters chosen? I believe by the "to forecast" label?
If so, who assigns the label? The reporter? Any dev? The "forecast team"?
Is the person who assigns the label also the person presenting the issue
and making sure the necessary info (like the gif) is available?
Cheers
Patrick
10:44 p.m.
1. How are presenters chosen? - Usually the person who wants the
change.
2. I believe by the "to forecast" label? Yes
3. If so, who assigns the label? - Anyone when there is an obvious
conflict between changing and not changing.
4. The reporter? Any dev? The "forecast team"? Yes
5. Is the person who assigns the label also the person presenting the
issue
6. and making sure the necessary info (like the gif) is available? - If
they want it, they should provide the materials to present it.
Martin,
12:48 a.m.
It may help to know a bit more context.
The original underlying problem this process is aiming to solve is where
a change is proposed but they're not entirely sure what approach to
take, and the contributor feels blocked due to lack of guidance.
Similar kinds of uncertainty can pop up in bug triage, and with
developers who implement a new feature but need advice on how to
optimize the UI/UX for it.
So, the idea is sort of an anti-bureaucracy, where instead of slowing
things down by requiring approval steps, to instead focus on where there
is uncertainty or disagreement and figure out how to help the
contributor get through those blocks.
Bryce
On Wed, Mar 13, 2019 at 06:44:36PM -0400, doctormo@...400... wrote:
1. How are presenters chosen? - Usually the person who wants the
change.
2. I believe by the "to forecast" label? Yes
3. If so, who assigns the label? - Anyone when there is an obvious
conflict between changing and not changing.
4. The reporter? Any dev? The "forecast team"? Yes
5. Is the person who assigns the label also the person presenting the
issue
6. and making sure the necessary info (like the gif) is available? - If
they want it, they should provide the materials to present it.
Martin,
1723
days inactive
1747
days old
inkscape-devel@lists.inkscape.org
20 comments
6 participants
participants (6)
-
unknown＠example.com -
Bryce Harrington -
brynn -
Maren Hachmann -
Mihaela -
Patrick Storz