Re: Changes to the bugzilla workflow: 2 proposals
Hi, > a) use the "needinfo" flag instead of the NEEDINFO status. > > This is implemented on various instances of bugzilla (mozilla.org, > redhat.com, opensuse.org) and allows the requester to set a needinfo on one > or more specific user. +1 > b) change back the initial state from UNCONFIRMED to NEW. > > This was the default until Bugzilla 3. But Many of our developers don't > really use the UNCONFIRMED->CONFIRMED transition and this confuses the > users. Moreover, NEW is still the initial status on various bugzilla > instances. I would introduce an ASSIGNED state so that developers that want > to mark that they have acknowledged it and they are going to work on it can > do it. +1 Best Regards, sandro signature.asc Description: This is a digitally signed message part.
Re: Changes to the bugzilla workflow: 2 proposals
Thomas Pfeiffer ha scritto: > On Montag, 12. Dezember 2016 07:39:24 CET Martin Gräßlin wrote: >> Am 2016-12-11 22:35, schrieb Luigi Toscano: >>> Hi, >>> >>> I would like to propose two changes to the Bugzilla workflow for our >>> instance >>> on bugs.kde.org. The two proposals are totally independent from each >>> other. >>> >>> a) use the "needinfo" flag instead of the NEEDINFO status. >>> >>> This is implemented on various instances of bugzilla (mozilla.org, >>> redhat.com, >>> opensuse.org) and allows the requester to set a needinfo on one or more >>> specific user. >> >> What does it mean to the state of "Open" bugs? What I like about the >> RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If >> the bugs would still be shown, it would completely destroy the search >> for me (KWin currently gets 1-3 crash reports by Arch users per day). > > Just a maybe dumb question: Are the flag and the status mutually exclusive on > an installation level? > If we make use of the flag on bugs.kde.org, are people blocked from using the > status? > > Of course the user-facing UI of bugs.kde.org should be as similar as possible > across products, but since it's not the users who set the flag or status, > can't > we just allow each project team to use what they prefer? > They are independent features. While I would agree with adding more statuses (that can be optional in the usage workflow, i.e. you can always go directly to RESOLVED) I would personally advocate for not having to have both needinfo options, and I think that reporting can be fixed. That said, yes, we could enable the flag at any time. -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
Luigi Toscano ha scritto: > On Monday, 12 December 2016 13:25:55 CET Boudewijn Rempt wrote: >> On Mon, 12 Dec 2016, Martin Gräßlin wrote: >>> No, that would affect more. For example when looking for a bug report I go >>> to bugs.kde.org, Browse, kwin, component and then have a very small list >>> of the bugs for that component and can find the bug report. >>> >>> If all the nonsentical needsinfo bugs get in there and are not hidden by >>> default, it gets completely useless. >>> >>> Also I don't want to be at 1000 open bug reports in a year. Consider the >>> social impact of that if weekly-bug-summary stats include those bugs. >> >> Fortunately, in that case, the weekly info page has disappeared from >> the front page... But yes, needinfo is a category that applies to a bug, >> it isn't just "I have a question for this person who reported or commented >> on this bug" -- it's this bug report is useless without further info. >> >> Now, if the status automatically changed back if info was added, that would >> be a nice improvement. > > So if the weekly status page was filter out the bugs in needinfo state, would > that be enough? > When the target of the needinfo answer, the needinfo flag is cleared (unless > a > checkbox is unchecked, this can be configured). The needinfo flag could be > cleaned also if another person answers (not enabled by default). Confirmed (thanks Ben): we can change it, it's a custom page: https://cgit.kde.org/websites/bugs-kde-org.git/tree/weekly-bug-summary.cgi?h=kde-5.0 -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Montag, 12. Dezember 2016 07:39:24 CET Martin Gräßlin wrote: > Am 2016-12-11 22:35, schrieb Luigi Toscano: > > Hi, > > > > I would like to propose two changes to the Bugzilla workflow for our > > instance > > on bugs.kde.org. The two proposals are totally independent from each > > other. > > > > a) use the "needinfo" flag instead of the NEEDINFO status. > > > > This is implemented on various instances of bugzilla (mozilla.org, > > redhat.com, > > opensuse.org) and allows the requester to set a needinfo on one or more > > specific user. > > What does it mean to the state of "Open" bugs? What I like about the > RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If > the bugs would still be shown, it would completely destroy the search > for me (KWin currently gets 1-3 crash reports by Arch users per day). Just a maybe dumb question: Are the flag and the status mutually exclusive on an installation level? If we make use of the flag on bugs.kde.org, are people blocked from using the status? Of course the user-facing UI of bugs.kde.org should be as similar as possible across products, but since it's not the users who set the flag or status, can't we just allow each project team to use what they prefer?
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 18:13:57 CET Boudewijn Rempt wrote: > On Mon, 12 Dec 2016, David Edmundson wrote: > > In terms of bugzilla workflow, we need to indicate 3 possible states of > > > > who we are waiting on: > > - needs bugzilla input from a developer (current unconfirmed) > > - needs bugzilla input from the reporter (current needsinfo) > > - doesn't require any further bugzilla input (current confirmed/resolved > > > > as appropriate) > > But are the states just there to reflect that we're waiting on something? > > > I don't think it can be done in any fewer statuses, and I don't really see > > how it requires any more. > > As I said before, and I handle the second-biggest KDE project in terms of > new bugs per year, my workflow would be easier with more states, and I'll > describe them, instead of using existing terms: I think that David was talking about the "needinfo" condition. > > [...] > On a tangent, but something I've wanted to bring up for long time... > > Yeah, they're nuts. Well, maybe not nuts, but bugzilla is a poster-child > of rudeness towards people who want to help. RESOLVED/WONTFIX, RESOLVED/ > INVALID -- that all reads as "BUGGEROFF/YOUIDIOT. This is not bugzilla "per se". We can't change the name of the resolution. I've seen CANTFIX otherwise, but of course we can find more friendly values. -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, David Edmundson wrote: > In terms of bugzilla workflow, we need to indicate 3 possible states of > who we are waiting on: > > - needs bugzilla input from a developer (current unconfirmed) > - needs bugzilla input from the reporter (current needsinfo) > - doesn't require any further bugzilla input (current confirmed/resolved > as appropriate) > But are the states just there to reflect that we're waiting on something? > I don't think it can be done in any fewer statuses, and I don't really see > how it requires any more. As I said before, and I handle the second-biggest KDE project in terms of new bugs per year, my workflow would be easier with more states, and I'll describe them, instead of using existing terms: * new, haven't looked at it yet * have looked at it, couldn't reproduce it or couldn't understand it, but don't want to look at it again when I'm looking for new reports * have looked at it, and I know the reporter hasn't told me everything I need yet * have looked at it and I know what is going on * have started working on it * have finished with the darn thing * never want to look at the report again, it was dumb (well, that's the same I have finished with the darn thing) > Not arguing, but it's worth noting this was a deliberate default change > between bugzilla 3 and bugzilla 4. On a tangent, but something I've wanted to bring up for long time... Yeah, they're nuts. Well, maybe not nuts, but bugzilla is a poster-child of rudeness towards people who want to help. RESOLVED/WONTFIX, RESOLVED/ INVALID -- that all reads as "BUGGEROFF/YOUIDIOT. A bug tracker is in the first place a tool to help me, as a developer, be more efficient in improving my software, but a very close second it's a marketing tool, and a recruitement tool and a customer retention tool. It's one of the most direct ways to stay in touch with our user base, with the users who are fan enough that they scale the stairs to the Olympus and manage to make use of a tool that must look like the Necronomicon to them. It's also a unique selling point, because with proprietary software, this kind of contact is all but impossible. I've said it before, but I _love_ and _admire_ everyone who reports a bug in bugs.kde.org! -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
On Sun, Dec 11, 2016 at 9:35 PM, Luigi Toscano wrote: > Hi, > > I would like to propose two changes to the Bugzilla workflow for our > instance > on bugs.kde.org. The two proposals are totally independent from each > other. > > a) use the "needinfo" flag instead of the NEEDINFO status. > > This is implemented on various instances of bugzilla (mozilla.org, > redhat.com, > opensuse.org) and allows the requester to set a needinfo on one or more > specific user. > > > In terms of bugzilla workflow, we need to indicate 3 possible states of who we are waiting on: - needs bugzilla input from a developer (current unconfirmed) - needs bugzilla input from the reporter (current needsinfo) - doesn't require any further bugzilla input (current confirmed/resolved as appropriate) I don't think it can be done in any fewer statuses, and I don't really see how it requires any more. > b) change back the initial state from UNCONFIRMED to NEW. > > This was the default until Bugzilla 3. But Many of our developers don't > really > use the UNCONFIRMED->CONFIRMED transition and this confuses the users. > Moreover, NEW is still the initial status on various bugzilla instances. > Not arguing, but it's worth noting this was a deliberate default change between bugzilla 3 and bugzilla 4. Whether they have new or not, is probably an indication of how old that project's bugzilla instance is. They document the reason here: https://bugzillaupdate.wordpress.com/2010/07/06/bugzilla-4-0-has-a-new-default-status-workflow/ However, we have another problem: You can rename every status in bugzilla except this one... http://bugzilla.readthedocs.io/en/latest/administering/workflow.html >I would introduce an ASSIGNED state so that developers that want to mark that they have acknowledged it and they are going to work on it can do it. That's quite clearly 3 proposals. I'll report a bug :P FWIW that's bugzilla 4/5's default "INPROGRESS". David
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, Martin Gräßlin wrote: > Overall from what I read in this thread so far about it, I'm quite against > this change. For me the focus is on getting those bugs away as I know that we > won't get the backtrace. Try asking Arch users for a backtrace... Maybe RESOLVED/BACKTRACE would work for those? -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, Luigi Toscano wrote: > You can ask to another person without adding explicitly to the bug. The flag > is cleared after asking, so you don't have to go and check the list of > pending > NEEDINFO for answer if you miss the email. > This may not be relevant for you. It is for me at least. So, if someone answers, the flag gets clear? That might be quite useful, though I get my answers sorted into a special mailbox, which also works. > Also, especially if you want to use more states as described below (TRIAGED, > CONFIRMED, etc), you don't need to go forth and back from the NEEDINFO state > if you need some information at some point in the later state. This is the > case that makes me consider needinfo as not as a state as the others (it can > break the workflow). Maybe it's not so visible when we have only one bug > initial status that moves almost always to RESOLVED, but it is. That's a really good point. In that sense, NEEDINFO is weird indeed. > > Well, I would like more states -- as I explained, NEW, TRIAGED, CONFIRMED, > > ASSIGNED, RESOLVED, NEEDINFO would cover all my needs. That's how a bug > > changes over time in my workflow. > > See above for more benefit as needinfo flag in this case. Okay, but I would still like to have a TRIAGED state in between NEW and CONFIRMED :-) > > > > > Substates could work, but would not be optimal. > > > > > Is there a special reason why keywords are horrible? > > > > * They're shown in a different location, the info block of the bug, so > > they're not meant for tracking state, and this is state. Keywords are for > > describing the bug. > > I see. > > > * The keywords we have are a mish-mash mixing all kinds of different things. > > * and they cannot be cleaned up without removing information from existing > > bugs. > They can be removed, it needs some work: > - if the information conveyed by the keyword was never relevant, remove it > - if it should be assigned to some other entity, move it there (with some > automation) > That does not mean that it could not be done, it takes time. But this is a > discussion for another time. I don't see them as horrible: for example, the > status of Feature could be tracked there instead of priority. Regression is > useful too. > > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 13:54:44 CET Boudewijn Rempt wrote: > On Mon, 12 Dec 2016, Luigi Toscano wrote: > > You could intercept them by filtering the content of the X-Bugzilla-Flags: > > header. > > Okay. > > > It may not bring immediate benefits for everyone, and of course some > > people > > would not benefit from it, but if there are no regressions I think it > > would be beneficial anyway. > > But what _are_ the benefits? I'm sure I must be missing something. Apart > from the granularity of asking a specific person -- which I don't see as > relevant or helpful. You can ask to another person without adding explicitly to the bug. The flag is cleared after asking, so you don't have to go and check the list of pending NEEDINFO for answer if you miss the email. This may not be relevant for you. It is for me at least. Also, especially if you want to use more states as described below (TRIAGED, CONFIRMED, etc), you don't need to go forth and back from the NEEDINFO state if you need some information at some point in the later state. This is the case that makes me consider needinfo as not as a state as the others (it can break the workflow). Maybe it's not so visible when we have only one bug initial status that moves almost always to RESOLVED, but it is. > > > > Not if you're talking about the keywords like in the top half of the > > > screen, those are horrible. if I can have NEW/UNTRIAGED, NEW/TRIAGED, > > > NEW/CONFIRMED like RESOLVED/WONTFIX or RESOLVED/FIXED, then that might > > > work. But the easiest flow would ideally still be from NEW to TRIAGED > > > to CONFIRMED to ASSIGNED to RESOLVED. > > > > I don't think that adding more substate combination would improve things. > > Well, I would like more states -- as I explained, NEW, TRIAGED, CONFIRMED, > ASSIGNED, RESOLVED, NEEDINFO would cover all my needs. That's how a bug > changes over time in my workflow. See above for more benefit as needinfo flag in this case. > > Substates could work, but would not be optimal. > > > Is there a special reason why keywords are horrible? > > * They're shown in a different location, the info block of the bug, so > they're not meant for tracking state, and this is state. Keywords are for > describing the bug. I see. > * The keywords we have are a mish-mash mixing all kinds of different things. > * and they cannot be cleaned up without removing information from existing > bugs. They can be removed, it needs some work: - if the information conveyed by the keyword was never relevant, remove it - if it should be assigned to some other entity, move it there (with some automation) That does not mean that it could not be done, it takes time. But this is a discussion for another time. I don't see them as horrible: for example, the status of Feature could be tracked there instead of priority. Regression is useful too. -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, Luigi Toscano wrote: > You could intercept them by filtering the content of the X-Bugzilla-Flags: > header. Okay. > It may not bring immediate benefits for everyone, and of course some people > would not benefit from it, but if there are no regressions I think it would > be > beneficial anyway. But what _are_ the benefits? I'm sure I must be missing something. Apart from the granularity of asking a specific person -- which I don't see as relevant or helpful. > > Not if you're talking about the keywords like in the top half of the screen, > > those are horrible. if I can have NEW/UNTRIAGED, NEW/TRIAGED, NEW/CONFIRMED > > like RESOLVED/WONTFIX or RESOLVED/FIXED, then that might work. But the > > easiest flow would ideally still be from NEW to TRIAGED to CONFIRMED to > > ASSIGNED to RESOLVED. > > I don't think that adding more substate combination would improve things. Well, I would like more states -- as I explained, NEW, TRIAGED, CONFIRMED, ASSIGNED, RESOLVED, NEEDINFO would cover all my needs. That's how a bug changes over time in my workflow. Substates could work, but would not be optimal. > Is there a special reason why keywords are horrible? * They're shown in a different location, the info block of the bug, so they're not meant for tracking state, and this is state. Keywords are for describing the bug. * The keywords we have are a mish-mash mixing all kinds of different things. * and they cannot be cleaned up without removing information from existing bugs. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 12:49:32 CET Boudewijn Rempt wrote: > On Mon, 12 Dec 2016, Luigi Toscano wrote: > > On Monday, 12 December 2016 10:22:37 CET Boudewijn Rempt wrote: > > > On Sun, 11 Dec 2016, Luigi Toscano wrote: > > > > Hi, > > > > > > > > I would like to propose two changes to the Bugzilla workflow for our > > > > instance on bugs.kde.org. The two proposals are totally independent > > > > from > > > > each other. > > > > > > > > a) use the "needinfo" flag instead of the NEEDINFO status. > > > > > > I wouldn't like that. I'm with Martin here -- NEEDINFO is an essential > > > part > > > of my workflow, and I'm not interested in fine-grained asking info from > > > one > > > particular person in the bug thread. > > > > If you want to filter the bugs with needinfo, you can still do it (see the > > other answer on this thread), so this would not disrupt your queries. > > Even if you are not interested in more detailed needinfo, others could be. > > Wit the targeted needinfo it is *possible* to define periodic reminder > > emails too. > What about the mails? I filter all my bugzilla mail into new, changed and > needinfo folder with pine. You could intercept them by filtering the content of the X-Bugzilla-Flags: header. > > In any case, I don't see any improvements here -- not for my workflow. I > guess I can adapt, and I'm fine with having to do that, but it's not like > there's anything useful for me in return. It may not bring immediate benefits for everyone, and of course some people would not benefit from it, but if there are no regressions I think it would be beneficial anyway. > > > > > b) change back the initial state from UNCONFIRMED to NEW. > > > > > > > > This was the default until Bugzilla 3. But Many of our developers > > > > don't > > > > really use the UNCONFIRMED->CONFIRMED transition and this confuses the > > > > users. Moreover, NEW is still the initial status on various bugzilla > > > > instances. I would introduce an ASSIGNED state so that developers that > > > > want to mark that they have acknowledged it and they are going to work > > > > on > > > > it can do it. > > > > > > > > What do you think? > > > > > > I'm fine with adding NEW, my workflow currently misses a stage between > > > UNCONFIRMED and CONFIRMED that means "I looked at the bug report, but > > > couldn't confirm, and I don't want to look at it again any time soon", > > > so > > > going from NEW to UNCONFIRMED to CONFIRMED would be good for me. I don't > > > need an ASSIGNED stage, I don't even assign bugs these days; as soon as > > > someone starts to work on them, I make a phabricator task. > > > > Would NEW + a keyword (Triaged, InitialTriage) work for this case? > > Not if you're talking about the keywords like in the top half of the screen, > those are horrible. if I can have NEW/UNTRIAGED, NEW/TRIAGED, NEW/CONFIRMED > like RESOLVED/WONTFIX or RESOLVED/FIXED, then that might work. But the > easiest flow would ideally still be from NEW to TRIAGED to CONFIRMED to > ASSIGNED to RESOLVED. I don't think that adding more substate combination would improve things. Is there a special reason why keywords are horrible? > > I don't think anyone seriously uses the VERIFIED and CLOSED stages, to me > those are just bureaucracy. I think they are just part of the default set of states, and we don't use them currently (which does not mean that they are not useful in general). -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 13:25:55 CET Boudewijn Rempt wrote: > On Mon, 12 Dec 2016, Martin Gräßlin wrote: > > No, that would affect more. For example when looking for a bug report I go > > to bugs.kde.org, Browse, kwin, component and then have a very small list > > of the bugs for that component and can find the bug report. > > > > If all the nonsentical needsinfo bugs get in there and are not hidden by > > default, it gets completely useless. > > > > Also I don't want to be at 1000 open bug reports in a year. Consider the > > social impact of that if weekly-bug-summary stats include those bugs. > > Fortunately, in that case, the weekly info page has disappeared from > the front page... But yes, needinfo is a category that applies to a bug, > it isn't just "I have a question for this person who reported or commented > on this bug" -- it's this bug report is useless without further info. > > Now, if the status automatically changed back if info was added, that would > be a nice improvement. So if the weekly status page was filter out the bugs in needinfo state, would that be enough? When the target of the needinfo answer, the needinfo flag is cleared (unless a checkbox is unchecked, this can be configured). The needinfo flag could be cleaned also if another person answers (not enabled by default). > > > Please note that in case of KWin a needsinfo means we never hear back in > > 99 > > out of 100 cases and as I mentioned before we get several of those per > > day. My bug workflow is completely focused only on marking bugs as > > needsinfo. Yes, it's broken and yes for a high profile product like KWin > > it's even worse. > > > > So any change of the process must ensure that we are not swamped in > > useless > > bug reports destroying all the default views and stats bugzilla provides. > > > > Overall from what I read in this thread so far about it, I'm quite against > > this change. For me the focus is on getting those bugs away as I know that > > we won't get the backtrace. Try asking Arch users for a backtrace... > > I have to agree. Krita (+1075, -1210) isn't in the plasmashell category of > bugs (+2341, -2101) per year yet, but it's more than kwin (+646, -680), and > bugzilla's workflow needs to be as simple as possible to support me. I don't > think changing the way needinfo works simplifies my workflow. I see this more as a reporting issues. If that can be fixed by changing the reports, would that be fine? -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, Martin Gräßlin wrote: > No, that would affect more. For example when looking for a bug report I go to > bugs.kde.org, Browse, kwin, component and then have a very small list of the > bugs for that component and can find the bug report. > > If all the nonsentical needsinfo bugs get in there and are not hidden by > default, it gets completely useless. > > Also I don't want to be at 1000 open bug reports in a year. Consider the > social impact of that if weekly-bug-summary stats include those bugs. Fortunately, in that case, the weekly info page has disappeared from the front page... But yes, needinfo is a category that applies to a bug, it isn't just "I have a question for this person who reported or commented on this bug" -- it's this bug report is useless without further info. Now, if the status automatically changed back if info was added, that would be a nice improvement. > > Please note that in case of KWin a needsinfo means we never hear back in 99 > out of 100 cases and as I mentioned before we get several of those per day. My > bug workflow is completely focused only on marking bugs as needsinfo. Yes, > it's broken and yes for a high profile product like KWin it's even worse. > > So any change of the process must ensure that we are not swamped in useless > bug reports destroying all the default views and stats bugzilla provides. > > Overall from what I read in this thread so far about it, I'm quite against > this change. For me the focus is on getting those bugs away as I know that we > won't get the backtrace. Try asking Arch users for a backtrace... > I have to agree. Krita (+1075, -1210) isn't in the plasmashell category of bugs (+2341, -2101) per year yet, but it's more than kwin (+646, -680), and bugzilla's workflow needs to be as simple as possible to support me. I don't think changing the way needinfo works simplifies my workflow. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
On Mon, 12 Dec 2016, Luigi Toscano wrote: > On Monday, 12 December 2016 10:22:37 CET Boudewijn Rempt wrote: > > On Sun, 11 Dec 2016, Luigi Toscano wrote: > > > Hi, > > > > > > I would like to propose two changes to the Bugzilla workflow for our > > > instance on bugs.kde.org. The two proposals are totally independent from > > > each other. > > > > > > a) use the "needinfo" flag instead of the NEEDINFO status. > > > > I wouldn't like that. I'm with Martin here -- NEEDINFO is an essential part > > of my workflow, and I'm not interested in fine-grained asking info from one > > particular person in the bug thread. > > > If you want to filter the bugs with needinfo, you can still do it (see the > other answer on this thread), so this would not disrupt your queries. > Even if you are not interested in more detailed needinfo, others could be. > Wit > the targeted needinfo it is *possible* to define periodic reminder emails too. What about the mails? I filter all my bugzilla mail into new, changed and needinfo folder with pine. In any case, I don't see any improvements here -- not for my workflow. I guess I can adapt, and I'm fine with having to do that, but it's not like there's anything useful for me in return. > > > > > b) change back the initial state from UNCONFIRMED to NEW. > > > > > > This was the default until Bugzilla 3. But Many of our developers don't > > > really use the UNCONFIRMED->CONFIRMED transition and this confuses the > > > users. Moreover, NEW is still the initial status on various bugzilla > > > instances. I would introduce an ASSIGNED state so that developers that > > > want to mark that they have acknowledged it and they are going to work on > > > it can do it. > > > > > > What do you think? > > > > I'm fine with adding NEW, my workflow currently misses a stage between > > UNCONFIRMED and CONFIRMED that means "I looked at the bug report, but > > couldn't confirm, and I don't want to look at it again any time soon", so > > going from NEW to UNCONFIRMED to CONFIRMED would be good for me. I don't > > need an ASSIGNED stage, I don't even assign bugs these days; as soon as > > someone starts to work on them, I make a phabricator task. > > Would NEW + a keyword (Triaged, InitialTriage) work for this case? > Not if you're talking about the keywords like in the top half of the screen, those are horrible. if I can have NEW/UNTRIAGED, NEW/TRIAGED, NEW/CONFIRMED like RESOLVED/WONTFIX or RESOLVED/FIXED, then that might work. But the easiest flow would ideally still be from NEW to TRIAGED to CONFIRMED to ASSIGNED to RESOLVED. I don't think anyone seriously uses the VERIFIED and CLOSED stages, to me those are just bureaucracy. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
Am 2016-12-12 11:55, schrieb Luigi Toscano: On Monday, 12 December 2016 03:51:31 CET Nicolás Alvarez wrote: > El 12 dic 2016, a las 03:39, Martin Gräßlin escribió: > > Am 2016-12-11 22:35, schrieb Luigi Toscano: >> a) use the "needinfo" flag instead of the NEEDINFO status. >> This is implemented on various instances of bugzilla (mozilla.org, >> redhat.com, opensuse.org) and allows the requester to set a needinfo on >> one or more specific user. > > What does it mean to the state of "Open" bugs? What I like about the > RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If the > bugs would still be shown, it would completely destroy the search for me > (KWin currently gets 1-3 crash reports by Arch users per day). I think you would be able to change your searches to take "doesn't have a 'needsinfo' flag" into account. Exactly. You would need only a one-time change to your saved search(es). No, that would affect more. For example when looking for a bug report I go to bugs.kde.org, Browse, kwin, component and then have a very small list of the bugs for that component and can find the bug report. If all the nonsentical needsinfo bugs get in there and are not hidden by default, it gets completely useless. Also I don't want to be at 1000 open bug reports in a year. Consider the social impact of that if weekly-bug-summary stats include those bugs. Please note that in case of KWin a needsinfo means we never hear back in 99 out of 100 cases and as I mentioned before we get several of those per day. My bug workflow is completely focused only on marking bugs as needsinfo. Yes, it's broken and yes for a high profile product like KWin it's even worse. So any change of the process must ensure that we are not swamped in useless bug reports destroying all the default views and stats bugzilla provides. Overall from what I read in this thread so far about it, I'm quite against this change. For me the focus is on getting those bugs away as I know that we won't get the backtrace. Try asking Arch users for a backtrace... Cheers Martin
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 10:22:37 CET Boudewijn Rempt wrote: > On Sun, 11 Dec 2016, Luigi Toscano wrote: > > Hi, > > > > I would like to propose two changes to the Bugzilla workflow for our > > instance on bugs.kde.org. The two proposals are totally independent from > > each other. > > > > a) use the "needinfo" flag instead of the NEEDINFO status. > > I wouldn't like that. I'm with Martin here -- NEEDINFO is an essential part > of my workflow, and I'm not interested in fine-grained asking info from one > particular person in the bug thread. If you want to filter the bugs with needinfo, you can still do it (see the other answer on this thread), so this would not disrupt your queries. Even if you are not interested in more detailed needinfo, others could be. Wit the targeted needinfo it is *possible* to define periodic reminder emails too. > > b) change back the initial state from UNCONFIRMED to NEW. > > > > This was the default until Bugzilla 3. But Many of our developers don't > > really use the UNCONFIRMED->CONFIRMED transition and this confuses the > > users. Moreover, NEW is still the initial status on various bugzilla > > instances. I would introduce an ASSIGNED state so that developers that > > want to mark that they have acknowledged it and they are going to work on > > it can do it. > > > > What do you think? > > I'm fine with adding NEW, my workflow currently misses a stage between > UNCONFIRMED and CONFIRMED that means "I looked at the bug report, but > couldn't confirm, and I don't want to look at it again any time soon", so > going from NEW to UNCONFIRMED to CONFIRMED would be good for me. I don't > need an ASSIGNED stage, I don't even assign bugs these days; as soon as > someone starts to work on them, I make a phabricator task. Would NEW + a keyword (Triaged, InitialTriage) work for this case? -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 03:51:31 CET Nicolás Alvarez wrote: > > El 12 dic 2016, a las 03:39, Martin Gräßlin escribió: > > > > Am 2016-12-11 22:35, schrieb Luigi Toscano: > >> a) use the "needinfo" flag instead of the NEEDINFO status. > >> This is implemented on various instances of bugzilla (mozilla.org, > >> redhat.com, opensuse.org) and allows the requester to set a needinfo on > >> one or more specific user. > > > > What does it mean to the state of "Open" bugs? What I like about the > > RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If the > > bugs would still be shown, it would completely destroy the search for me > > (KWin currently gets 1-3 crash reports by Arch users per day). > I think you would be able to change your searches to take "doesn't have a > 'needsinfo' flag" into account. Exactly. You would need only a one-time change to your saved search(es). -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On Monday, 12 December 2016 19:34:55 CET Eike Hein wrote: > On 12/12/2016 07:27 PM, Elvis Angelaccio wrote: > > On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano > > > > wrote: > >> I would introduce an ASSIGNED state so that developers that want to mark > >> that they have acknowledged it and they are going to work on it can do > >> it.> > > Don't we already have the ASSIGNED state? I just checked and I can > > select it from the left dropdown menu. > > Correct, we have that and use it quite a bit imho. Oh, sorry, I did not check. It would be a matter of changing the policy then. -- Luigi
Re: Changes to the bugzilla workflow: 2 proposals
On 12/12/2016 07:27 PM, Elvis Angelaccio wrote: > On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano > wrote: >> I would introduce an ASSIGNED state so that developers that want to mark that >> they have acknowledged it and they are going to work on it can do it. > > Don't we already have the ASSIGNED state? I just checked and I can > select it from the left dropdown menu. Correct, we have that and use it quite a bit imho. Cheers, Eike
Re: Changes to the bugzilla workflow: 2 proposals
On Sun, Dec 11, 2016 at 10:35 PM, Luigi Toscano wrote: > I would introduce an ASSIGNED state so that developers that want to mark that > they have acknowledged it and they are going to work on it can do it. Don't we already have the ASSIGNED state? I just checked and I can select it from the left dropdown menu. > > -- > Luigi Cheers Elvis
Re: Changes to the bugzilla workflow: 2 proposals
On 12/12/2016 06:35 AM, Luigi Toscano wrote: > b) change back the initial state from UNCONFIRMED to NEW. > > This was the default until Bugzilla 3. But Many of our developers don't really > use the UNCONFIRMED->CONFIRMED transition and this confuses the users. > Moreover, NEW is still the initial status on various bugzilla instances. > I would introduce an ASSIGNED state so that developers that want to mark that > they have acknowledged it and they are going to work on it can do it. > > What do you think? I heavily agree with the NEW thing - all my bug queries list both, so I don't bother managing the state, and users feel really annoyed by UNCONFIRMED. It's unnecessary bad feelings. Cheers, Eike
Re: Changes to the bugzilla workflow: 2 proposals
On Sun, 11 Dec 2016, Luigi Toscano wrote: > Hi, > > I would like to propose two changes to the Bugzilla workflow for our instance > on bugs.kde.org. The two proposals are totally independent from each other. > > a) use the "needinfo" flag instead of the NEEDINFO status. I wouldn't like that. I'm with Martin here -- NEEDINFO is an essential part of my workflow, and I'm not interested in fine-grained asking info from one particular person in the bug thread. > > This is implemented on various instances of bugzilla (mozilla.org, redhat.com, > opensuse.org) and allows the requester to set a needinfo on one or more > specific user. > > > b) change back the initial state from UNCONFIRMED to NEW. > > This was the default until Bugzilla 3. But Many of our developers don't really > use the UNCONFIRMED->CONFIRMED transition and this confuses the users. > Moreover, NEW is still the initial status on various bugzilla instances. > I would introduce an ASSIGNED state so that developers that want to mark that > they have acknowledged it and they are going to work on it can do it. > > What do you think? > > I'm fine with adding NEW, my workflow currently misses a stage between UNCONFIRMED and CONFIRMED that means "I looked at the bug report, but couldn't confirm, and I don't want to look at it again any time soon", so going from NEW to UNCONFIRMED to CONFIRMED would be good for me. I don't need an ASSIGNED stage, I don't even assign bugs these days; as soon as someone starts to work on them, I make a phabricator task. -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
Re: Changes to the bugzilla workflow: 2 proposals
> El 12 dic 2016, a las 03:39, Martin Gräßlin escribió: > > Am 2016-12-11 22:35, schrieb Luigi Toscano: >> >> a) use the "needinfo" flag instead of the NEEDINFO status. >> This is implemented on various instances of bugzilla (mozilla.org, >> redhat.com, >> opensuse.org) and allows the requester to set a needinfo on one or more >> specific user. > > What does it mean to the state of "Open" bugs? What I like about the RESOLVED > NEEDSINFO is that it hides the bugs from my search lists. If the bugs would > still be shown, it would completely destroy the search for me (KWin currently > gets 1-3 crash reports by Arch users per day). I think you would be able to change your searches to take "doesn't have a 'needsinfo' flag" into account. -- Nicolás
Re: Changes to the bugzilla workflow: 2 proposals
Am 2016-12-11 22:35, schrieb Luigi Toscano: Hi, I would like to propose two changes to the Bugzilla workflow for our instance on bugs.kde.org. The two proposals are totally independent from each other. a) use the "needinfo" flag instead of the NEEDINFO status. This is implemented on various instances of bugzilla (mozilla.org, redhat.com, opensuse.org) and allows the requester to set a needinfo on one or more specific user. What does it mean to the state of "Open" bugs? What I like about the RESOLVED NEEDSINFO is that it hides the bugs from my search lists. If the bugs would still be shown, it would completely destroy the search for me (KWin currently gets 1-3 crash reports by Arch users per day). b) change back the initial state from UNCONFIRMED to NEW. This was the default until Bugzilla 3. But Many of our developers don't really use the UNCONFIRMED->CONFIRMED transition and this confuses the users. Moreover, NEW is still the initial status on various bugzilla instances. I would introduce an ASSIGNED state so that developers that want to mark that they have acknowledged it and they are going to work on it can do it. This sounds good! +1 to it. Cheers Martin
Re: Changes to the bugzilla workflow: 2 proposals
Il giorno Sun, 11 Dec 2016 22:35:03 +0100 Luigi Toscano ha scritto: > This is implemented on various instances of bugzilla (mozilla.org, > redhat.com, opensuse.org) and allows the requester to set a needinfo > on one or more specific user. To elaborate more for those unfamiliar: basically this flag allows to request information to a specific user, to the reporter, to the assignee, or to everyone, and can be cleared by itself when answering the request for information. In openSUSE we found it much more useful than the NEEDINFO state. > What do you think? +1 to both. That's what we use in openSUSE and works more or less OK. -- Luca Beltrame - KDE Forums team GPG key ID: A29D259B pgpppkldofPxF.pgp Description: Firma digitale OpenPGP
Changes to the bugzilla workflow: 2 proposals
Hi, I would like to propose two changes to the Bugzilla workflow for our instance on bugs.kde.org. The two proposals are totally independent from each other. a) use the "needinfo" flag instead of the NEEDINFO status. This is implemented on various instances of bugzilla (mozilla.org, redhat.com, opensuse.org) and allows the requester to set a needinfo on one or more specific user. b) change back the initial state from UNCONFIRMED to NEW. This was the default until Bugzilla 3. But Many of our developers don't really use the UNCONFIRMED->CONFIRMED transition and this confuses the users. Moreover, NEW is still the initial status on various bugzilla instances. I would introduce an ASSIGNED state so that developers that want to mark that they have acknowledged it and they are going to work on it can do it. What do you think? -- Luigi
