I've subscribed Nick, Brett, and Jessica to this list to start out. Jessica: Nick and Brett and I (as well as some other people) had a conversation at the sprints about where it would be appropriate to conduct the conversation about improving the workflow and workflow infrastructure, and we decided we really needed a new list for it. Tracker-discuss was the obvious candidate, but that lists gets all of the tickets and ticket traffic posted on the meta-tracker, and this discussion doesn't need to be interrupted by those, nor will our discussion be limited to topics concerning the tracker. Thus this list. All: Take a look at the list description, and let me know if you think that covers it, and any tweaks you think we should make to that mission statement. First question: should the list be public/open subscription? I don't see any reason it should be closed, but I'm open to opinions :) Assuming it is open subscription, I propose I make an announcement on the python-committers, python-dev, tracker-discuss, and python-mentorship mailing lists inviting interested parties to sign up. --David
I would add that the list is under the PSF CoC and infractions will result in banishment. And I'm not sure if you mailed Nick and I the password for the list -- on the train -- but don't forget that; done that myself. :) I've subscribed Nick, Brett, and Jessica to this list to start out. Jessica: Nick and Brett and I (as well as some other people) had a conversation at the sprints about where it would be appropriate to conduct the conversation about improving the workflow and workflow infrastructure, and we decided we really needed a new list for it. Tracker-discuss was the obvious candidate, but that lists gets all of the tickets and ticket traffic posted on the meta-tracker, and this discussion doesn't need to be interrupted by those, nor will our discussion be limited to topics concerning the tracker. Thus this list. All: Take a look at the list description, and let me know if you think that covers it, and any tweaks you think we should make to that mission statement. First question: should the list be public/open subscription? I don't see any reason it should be closed, but I'm open to opinions :) Assuming it is open subscription, I propose I make an announcement on the python-committers, python-dev, tracker-discuss, and python-mentorship mailing lists inviting interested parties to sign up. --David _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow
On Wed, 16 Apr 2014 13:10:35 -0400, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 16 Apr 2014 13:08, "Brett Cannon" <bcannon@gmail.com> wrote:
I would add that the list is under the PSF CoC and infractions will
result in banishment.
Sustained infractions, anyway. Also handy to link to the CoC from the footer.
Done. --David
I had a fair amount of time to think during my drive home from PyCon. I have some preliminary thoughts about ticket workflow and ways we can improve it. I'll try to write it up this weekend to act as a conversation starter. In the meantime, I'd like to put forth a small proposal with regards to one specific thing in the current tracker interface. Currently for resolution we have: duplicate fixed not a bug later out of date postponed rejected remind wont fix works for me 3rd party I would like to collapse and reorder this list as follows: duplicate not a bug works for me fixed postponed won't fix 3rd party You may or may not recall that we used to have a resolution 'accepted', where 'accepted' was "supposed" to be for enhancements that were committed. It tended to be an attractive nuisance, though, since people would set it when they thought the bug *should* be fixed rather than when an enhancement was committed. (There is a sense in which it is indeed valuable to be able to say that, but I'll suggest a way to deal with that in my larger brain dump; it doesn't belong in the 'resolution' field :). 'rejected' isn't really an attractive nuisance, but it doesn't get applied only to enhancements. Sometimes it is applied to proposed "bug" fixes. So, the distinction between "won't fix" and "rejected" is not clear, and thus has little utility. Now, we *could* go through and "fix" the metadata if we actually wanted to use that distinction for something, but I doubt that we do. If you are analyzing tracker data, you can always check if the issue was an enhancement or not. So I propose that we drop 'rejected' and just close rejected enhancements as "won't fix". (After all, we often only half-jokingly say that enhancement requests are "API bugs".) For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them. The ordering is currently mostly-alphabetical, I picked an ordering that feels "logical" to me, but I'm not really attached to the ordering. --David
On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray@bitdance.com> wrote:
[...]
For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them.
Presumably you mean collapsing "later" and "remind" into "postpone". Fine with me. That seems to leave "out of date" unaccounted for. If we're in a collapsing mood, I guess that could be covered by "fixed". Further down the minimalist route, perhaps "works for me" could be collapsed into "not a bug" as well. That distinction seems hazy enough to make it difficult to apply the two consistently. While part of me likes the idea of having more fine-grained statuses as we do today, in practice it is difficult to make use of them so I'm OK with consolidation. BTW, what about the fields for existing (open and closed) issues? Would they get mapped to the new values? -- Ned Deily nad@acm.org -- []
On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
Is "3rd party" a different thing from "not a bug". Often it's "not a bug" because it's a bug somewhere else (perhaps not identified :-)). Regardless, +1. Regards Antoine.
Hi, On Apr 19, 2014 5:59 AM, "R. David Murray" <rdmurray@bitdance.com> wrote:
I had a fair amount of time to think during my drive home from PyCon. I have some preliminary thoughts about ticket workflow and ways we can improve it. I'll try to write it up this weekend to act as a conversation starter.
In the meantime, I'd like to put forth a small proposal with regards to one specific thing in the current tracker interface. Currently for resolution we have:
duplicate fixed not a bug later out of date postponed rejected remind wont fix works for me 3rd party
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
IIUC this is what you are doing: duplicate = duplicate not a bug = not a bug + rejected works for me = works for me (+ out of date?) fixed = fixed postponed = later + remind + postponed (+ out of date?) won't fix = wont fix 3rd party = 3rd party This seems a reasonable request to me. I've been trying to simplify the interface of the tracker and remove non-essential elements, and this would be a good step in that direction. The next step could be "merging" this with the "closed" status so that you select the resolution once while you mark the issue as closed (or possible pending).
You may or may not recall that we used to have a resolution 'accepted', where 'accepted' was "supposed" to be for enhancements that were committed. It tended to be an attractive nuisance, though, since people would set it when they thought the bug *should* be fixed rather than when an enhancement was committed. (There is a sense in which it is indeed valuable to be able to say that, but I'll suggest a way to deal with that in my larger brain dump; it doesn't belong in the 'resolution' field :).
'rejected' isn't really an attractive nuisance, but it doesn't get applied only to enhancements. Sometimes it is applied to proposed "bug" fixes. So, the distinction between "won't fix" and "rejected" is not clear, and thus has little utility. Now, we *could* go through and "fix" the metadata if we actually wanted to use that distinction for something, but I doubt that we do. If you are analyzing tracker data, you can always check if the issue was an enhancement or not. So I propose that we drop 'rejected' and just close rejected enhancements as "won't fix". (After all, we often only half-jokingly say that enhancement requests are "API bugs".)
For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them.
While doing these changes we should keep in mind what are all those fields useful for. I can think of two main use cases: 1) searching/filtering issues (both for finding specific issues or for analyzing tracker data); 2) informing users about the current situation of the issue; In general I don't think anyone needs such a fine-grained filtering (have you ever looked for "postponed" issues or wanted to know how many "later" issues there are?), and the rationale for closing the issue could be detailed in the message, so I'm +1 on the change you suggest.
The ordering is currently mostly-alphabetical, I picked an ordering that feels "logical" to me, but I'm not really attached to the ordering.
Remember that there is also https://wiki.python.org/moin/DesiredTrackerFeatures which contain discussions and ideas about possible improvements to the interface. Best Regards, Ezio Melotti
--David _______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
On 19 Apr 2014 06:04, "Antoine Pitrou" <antoine@python.org> wrote:
On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
Is "3rd party" a different thing from "not a bug". Often it's "not a bug" because it's a bug somewhere else (perhaps not identified :-)).
That would be the resolution used for things like bugs in pip, or errors in a patched distro version. Ideally it would require a URL that referenced the bug in the other projects issue tracker, but that can go in a comment easily enough. Cheers, Nick.
Regardless, +1.
Regards
Antoine.
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct:
On 19 Apr 2014 00:47, "Ned Deily" <nad@acm.org> wrote:
On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray@bitdance.com> wrote:
[...]
For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them.
Presumably you mean collapsing "later" and "remind" into "postpone".
Fine with me.
That seems to leave "out of date" unaccounted for. If we're in a
collapsing mood, I guess that could be covered by "fixed". +1
Further down the minimalist route, perhaps "works for me" could be
collapsed into "not a bug" as well. That distinction seems hazy enough to make it difficult to apply the two consistently.
To my mind, "works for me" is closer to "can't fix". The closest resolution we use in Red Hat Bugzilla would likely be "INSUFFICIENT DATA" - the bug report is too incomplete for us to reproduce the error or otherwise identify the actual problem (if any). Cheers, Nick.
While part of me likes the idea of having more fine-grained statuses as
we do today, in practice it is difficult to make use of them so I'm OK with consolidation.
BTW, what about the fields for existing (open and closed) issues? Would
they get mapped to the new values?
-- Ned Deily nad@acm.org -- []
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct:
On Fri, 18 Apr 2014 21:22:45 -0700, Ned Deily <nad@acm.org> wrote:
On Apr 18, 2014, at 19:59 , R. David Murray <rdmurray@bitdance.com> wrote:
[...]
For the other deletions, I think think it should be obvious that we only need one resolution that says "maybe someday this will get reopened", rather than three of them.
Presumably you mean collapsing "later" and "remind" into "postpone". Fine with me.
That seems to leave "out of date" unaccounted for. If we're in a
Yes, you are right, I forgot that one. I suppose that one should be kept, although I suspect it gets used only infrequently.
collapsing mood, I guess that could be covered by "fixed". Further down the minimalist route, perhaps "works for me" could be collapsed into "not a bug" as well. That distinction seems hazy enough to make it difficult to apply the two consistently.
I'd be fine with eliminating "works for me" in favor of "not a bug". Especially since "works for me" is really ambiguous when faced with possible cross-platform issues.
While part of me likes the idea of having more fine-grained statuses as we do today, in practice it is difficult to make use of them so I'm OK with consolidation.
As far as I can see the current use case for resolution is to inform viewers of the bug, and most importantly the original reporter, what the "disposition" of the bug was. For that purpose "works for me" and "not a bug" are essentially equivalent.
BTW, what about the fields for existing (open and closed) issues? Would they get mapped to the new values?
They will continue to show the resolution they were closed with. We *could* go back and change the resolution of closed issues, but unless we are using resolution in a way that such a cleanup would actually benefit, I don't think it is worth spending time on. --David PS: Thanks for updating the devguide, but the way, I'd forgotten about that.
Just for the record, I checked how many issues use each different resolution: 13129 fixed 3041 not a bug 1937 duplicate 1626 wont fix 1545 rejected 1423 out of date 726 works for me 108 later 60 postponed 16 remind 9 3rd party (Note that 3rd party has been added recently, hence the low number of issues that use it)
On Sat, 19 Apr 2014 12:02:02 +0200, Antoine Pitrou <antoine@python.org> wrote:
On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
Is "3rd party" a different thing from "not a bug". Often it's "not a bug" because it's a bug somewhere else (perhaps not identified :-)).
Regardless, +1.
Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug" to the person who reported the issue, so I think 3rd party is worthwhile. Also, the number of 3rd party issues that we end up responding to could be a useful metric to have. That said, I won't cry if we decide to drop it :) --David
On sam., 2014-04-19 at 10:53 -0400, R. David Murray wrote:
On Sat, 19 Apr 2014 12:02:02 +0200, Antoine Pitrou <antoine@python.org> wrote:
On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
Is "3rd party" a different thing from "not a bug". Often it's "not a bug" because it's a bug somewhere else (perhaps not identified :-)).
Regardless, +1.
Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug" to the person who reported the issue, so I think 3rd party is worthwhile. Also, the number of 3rd party issues that we end up responding to could be a useful metric to have.
That's not a problem to me. (OTOH, it "3rd party" was spelled "third party", I think I would like it better :-) for some reason, the leading digit looks wrong :-D) Regards Antoine.
On Sat, 19 Apr 2014 14:20:31 +0300, Ezio Melotti <ezio.melotti@gmail.com> wrote:
IIUC this is what you are doing:
duplicate = duplicate not a bug = not a bug + rejected works for me = works for me (+ out of date?) fixed = fixed postponed = later + remind + postponed (+ out of date?) won't fix = wont fix 3rd party = 3rd party
This seems a reasonable request to me.
Yes. It seems despite what I said in a previous message about keeping it that people are OK with dropping "out of date" in favor of "fixed", which is also fine with me.
I've been trying to simplify the interface of the tracker and remove non-essential elements, and this would be a good step in that direction. The next step could be "merging" this with the "closed" status so that you select the resolution once while you mark the issue as closed (or possible pending).
Yeah, simplifying that is what my proposal is about. I need to finish writing it ;)
While doing these changes we should keep in mind what are all those fields useful for. I can think of two main use cases:
Exactly. The only fields we should have are those that are *useful*: things that turn into something operationally. Not just busy work :)
1) searching/filtering issues (both for finding specific issues or for analyzing tracker data); 2) informing users about the current situation of the issue;
Right.
In general I don't think anyone needs such a fine-grained filtering (have you ever looked for "postponed" issues or wanted to know how many "later" issues there are?), and the rationale for closing the issue could be detailed in the message, so I'm +1 on the change you suggest.
The ordering is currently mostly-alphabetical, I picked an ordering that feels "logical" to me, but I'm not really attached to the ordering.
Remember that there is also https://wiki.python.org/moin/DesiredTrackerFeatures which contain discussions and ideas about possible improvements to the interface.
Good point, I need to review that before finishing my for-discussion proposal. --David
On Sat, 19 Apr 2014 09:43:51 -0400, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 Apr 2014 06:04, "Antoine Pitrou" <antoine@python.org> wrote:
On ven., 2014-04-18 at 22:59 -0400, R. David Murray wrote:
I would like to collapse and reorder this list as follows:
duplicate not a bug works for me fixed postponed won't fix 3rd party
Is "3rd party" a different thing from "not a bug". Often it's "not a bug" because it's a bug somewhere else (perhaps not identified :-)).
That would be the resolution used for things like bugs in pip, or errors in a patched distro version. Ideally it would require a URL that referenced the bug in the other projects issue tracker, but that can go in a comment easily enough.
At some point I think it would be great to add tooling to support that (a list of 3rd party bug tracker URLs that can autocomplete like nosy does). For now just putting it in the comment works fine. --David
On Sat, 19 Apr 2014 09:49:30 -0400, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 19 Apr 2014 00:47, "Ned Deily" <nad@acm.org> wrote:
Further down the minimalist route, perhaps "works for me" could be collapsed into "not a bug" as well. That distinction seems hazy enough to make it difficult to apply the two consistently.
To my mind, "works for me" is closer to "can't fix". The closest resolution we use in Red Hat Bugzilla would likely be "INSUFFICIENT DATA" - the bug report is too incomplete for us to reproduce the error or otherwise identify the actual problem (if any).
Yeah, I thought about that, but I didn't want to suggest *adding* resolutions at this point. We may want something like 'insufficient data' later, though. Or I suppose we could rename "works for me" to be that, if other people think it is accurate enough. --David
On Sat, 19 Apr 2014 16:58:47 +0200, Antoine Pitrou <antoine@python.org> wrote:
On sam., 2014-04-19 at 10:53 -0400, R. David Murray wrote:
Yeah, "it's a bug somewhere else" doesn't sound very much like "not a bug" to the person who reported the issue, so I think 3rd party is worthwhile. Also, the number of 3rd party issues that we end up responding to could be a useful metric to have.
That's not a problem to me. (OTOH, it "3rd party" was spelled "third party", I think I would like it better :-) for some reason, the leading digit looks wrong :-D)
Good idea. I just copied the original 'versions' text without thinking about it. Consider it done (because it is). If anyone objects, it is easy enough to change it back :) --David
participants (6)
-
Antoine Pitrou -
Brett Cannon -
Ezio Melotti -
Ned Deily -
Nick Coghlan -
R. David Murray