"Martin v. Löwis" writes:
> > o consensus needed
> > o test needed
> > o patch needed
> > o patch needs work
> > o patch review
> > o commit review
> >
> > The first of these additional items is equivalent to your bullet item
> > above. I would propose that the issue, regardless of whether or not
> > it is a bug fix or a feature request, goes into 'consensus needed'
All of these passives are making me aggressive....
Sure, these are real statuses internally, but they seem mostly of
interest to people who are actually working on the issue. They'll be
getting nosy mail and following the issue in their browsers. Is this
really needed for them?
On the other hand, for a non-developer who wants to know what's
happening to their issue, these are all rather fuzzy. The submitter
of a bug wants to know
(1) Does python-dev admit it's an issue?
No -> resolved because invalid
Yes -> confirmed
Don't know -> waiting for more information from submitter (I would
call this "pending response from OP")
Not triaged -> "-- unset --" or new
(2) Has anybody accepted responsibility for working on this?
Yes -> assigned
(3) Has anybody done any work recently?
No -> sleeping
(4) Is there a solution?
Yes -> resolved because implemented
(5) Can I get the solution by normal upgrading?
Yes -> closed
So submitters already have *at least* seven statuses that they would
like to be able to recognize at a glance. I think these correlate
well with what developers who accept broad responsibility (release
engineers, for example) need to know, too.
Does workflow coordination require more than that? Almost certainly,
yes. But is it a good idea to pack all that into status?
Also, note that code, doc, and test can be done in any order. A
developer may write a test so he can automatically elicit the problem
behavior, then document the desired behavior, then come up with code
to implement it. Or the OP could submit a patch, then the maintainer
decides what parts of the patch are specified behavior and what parts
are implementation details and documents it, and finally they come up
with a test. That means you have at least *eight* different statuses,
or maybe 27 (ie, each component is tri-state: no improvement needed,
improvement needed, implemented).
I'm not suggesting that this kind of thing should be implemented;
rather, until the use case and who needs it is clear, the status field
should be kept as simple as possible.
> Well, there is always the "unset" state, which means "not triaged".
I've had complaints from my users about the "-- not specified --"
status; they prefer "new". They seem to think that "unspecified"
means the tracker is broken.
> Instead, would it help to add a "confirmed" state? For a bug, that
> would mean that it was successfully reproduced; for a patch, it
> was confirmed as desirable.
Yes. Lack of such a state is a PR disaster. There needs to be a
signal that triage has happened, but the person doing triage typically
will not accept responsibility for fixing the bug, only for improving
the description of the reproduction recipe (including adding a test)
etc.
> If the person performing triage cannot confirm the bug, they should
> reject the issue (or recommend rejection, in case they are unsure).
If they're unsure, they should ping the submitter and request more
information, and set the status to "waiting for response". As you say:
> Somebody performing triage should never conclude with "I don't
> know"; this would be time-wasting.
>
> If, for a bug, the reviewer disagrees that it would be a bug if the
> behavior actually exists, then the issue should be closed (resolution
> not-a-bug/invalid).
Maybe set it "resolved" (if there's such a status separate from
"closed"). The idea is that if the issue gets "me toos", then it
should be added to the FAQ. Also, such issues should be easy to
search for, but most standard searches restrict to "open" issues.
> If the reviewer agrees that it would be a bug, but fails to
> reproduce it, a test is needed.
By "reviewer" you mean the person doing triage, right? By "test is
needed", you really mean "cooperation from the submitter in defining a
test", right? (Tests are always needed to prevent regressions.)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
