Bug management for inkscape/inkscape
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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.
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
_______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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-templat...
(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
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-templat...
(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.
Am 19.02.2019 um 01:25 schrieb Bryce Harrington:
Some additional bug management questions needing decided are included in this infra bug report:
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
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
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
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@lists.sourceforge.net [8]https://lists.sourceforge.net/lists/listinfo/inkscape-devel
References
- https://about.gitlab.com/2018/03/19/use-cases-for-epics/
- https://gitlab.com/inkscape/inkscape/issues?sort=label_priority
- https://gitlab.com/nathanal
- https://gitlab.com/Qantas94Heavy
- https://gitlab.com/inkscape/infra/services/issues/4
- https://gitlab.com/inkscape/infra/services/issues/22
- mailto:Inkscape-devel@lists.sourceforge.net
- https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
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
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,
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:
- 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,
participants (6)
-
unknown＠example.com -
Bryce Harrington -
brynn -
Maren Hachmann -
Mihaela -
Patrick Storz