On Jul 11, 2010, at 3:19 PM, Martin v. Löwis wrote:
> Unfortunately, it's often not clear what the submitter wants: does she
> want to help, or want to get help? For a bug report, I often post a
> message "can you provide a patch?", but sometimes, it isn't that clear.
Perhaps this is the one area where the biggest advance could be made: a
clarification of the workflow.
My experience with Python issues which have been "triaged" is that everyone who
triages tickets has a slightly different idea of who is responsible for the
ticket and what they're supposed to do next at every point in the process.
Triage, as described on <http://www.python.org/dev/workflow/>, emphasizes
making sure "that all fields in the issue tracker are properly set", rather
than on communicating with the contributor or reporter.
On Twisted, we try to encourage triagers to focus on communicating the workflow
ramifications of what a particular contributor has done. We try to provide a
response to the bug reporter or patch submitter that says "thanks, but in order
to move this along, you need to go through the following steps" and sometimes
even attach a link to the workflow document pointing out exactly where in the
process the ticket is now stuck. (At least, that's what we're trying to do.)
This involves a lot of repeating ourselves in ticket comments, but it's well
worth it (and as more of the repetition moves into citing links to documents
that have been written to describe aspects of the workflow, it's less onerous).
<http://www.python.org/dev/workflow/> describes what the steps are, but it's in
a sort of procedural passive voice that doesn't say who is responsible for
doing reviews or how to get a list of patches which need to be reviewed or what
exactly a third-party non-core-committer reviewer should do to remove the
'Patch review' keyword.
<http://twistedmatrix.com/trac/wiki/TwistedDevelopment#SubmittingaPatch> and
<http://twistedmatrix.com/trac/wiki/ReviewProcess> meander around a bit, but a
while ago we re-worked them so that each section has a specific audience
(authors, reviewers, or external patch submitters) and that helped readers
understand what they're intended to do.
Plus, <http://twistedmatrix.com/trac/report/15> is a useful resource for core
developers with only a little bit of free time to do a review.
(I'm just offering some suggestions based on what I think has worked, not to
hold Twisted up as a paragon of a perfect streamlined process. We still have
folks complain about stuck patches, these documents are _far_ from perfect, and
there are still some varying opinions about how certain workflow problems
should be dealt with and differences in quality of review. Plus, we have far
fewer patches to deal with than Python. Nevertheless, the situation used to be
worse for us, and these measures seem to have helped.)
_______________________________________________
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
