On 16 Apr 2014 13:08, "Brett Cannon" 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. Cheers, Nick.

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 19 Apr 2014 00:47, "Ned Deily" wrote:

On Apr 18, 2014, at 19:59 , R. David Murray 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:

https://www.python.org/psf/codeofconduct

On Fri, 18 Apr 2014 21:22:45 -0700, Ned Deily wrote:

On Apr 18, 2014, at 19:59 , R. David Murray 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.

On 19 Apr 2014 06:04, "Antoine Pitrou" 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:

https://www.python.org/psf/codeofconduct

On Sat, 19 Apr 2014 12:02:02 +0200, Antoine Pitrou 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 Sat, 19 Apr 2014 16:58:47 +0200, Antoine Pitrou 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

On Sat, 19 Apr 2014 14:20:31 +0300, Ezio Melotti 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