[Python-Dev] Tracker reviews workflow and flags

[Brian Curtin]

On Fri, Mar 19, 2010 at 03:09, anatoly techtonik <techtonik at gmail.com>wrote:

> I want to push some of my patches before 2.7 and use 5-1 rule for
> that, but I can't come up with any review workflow other than mailing
> status of my comments to the issues here. I can't mark issues in any
> way. How about giving users ability to set flags or keywords? Maybe
> entering a separate field like "Review status"?
>

We already have "Patch Review" as a stage, and "needs review" as a flag,
which I feel is more than enough. If you don't have the privileges to modify
an issue, you can always comment on the issue with something like "can this
issue be set to the patch review stage?" Someone will probably take a look
at it and set it accordingly.

Real world example with issue8151. It is an issue with a trivial patch
> in it. Everything what is needed is to dispatch it to stable `commit
> queue` and port to trunk. It is not 'easy' - it is 'trivial', but I
> have no means to mark it as 'easy' either, so even this trivial fix
> lies in tracker for three days waiting for review.
>

Given that we have hundreds of issues with patches waiting for review, three
days isn't so bad :) As with any project, there are only so many people and
so much time to get the work done.


> About 'easy' flag:
> "6      easy    This is an easy task (e.g. suitable for GHOP or bug day
> beginners)"
> It seems that it is for the issue that requires a patch, but if the
> patch is already there and nobody wants to commit it - what should I
> do?
>

Post a comment on the issue asking what the status is. If an approved patch
has been sitting for a few weeks, make a comment. If it has been there for a
few days, I'd let it slide but keep it on your radar.


>
> Finally, review queue proposal.
> To follow 5-1 rule, I need to review 5 issues, before mine is
> reviewed, so I need some help from tracker.
> 1. I lack expertise in certain areas (C/C++, Mac OS, etc.), so I would
> like to hide some issues under "Needs review" query, so they won't
> bother me (if too many people marked issues in this way - the stats
> may become a good reason for highly professional bug party)
>

There already exists a component field which has Macintosh as an option, so
you could filter on that. Same goes for Windows.

Drilling down to the language(s) involved in the issue feels like just
another step that would get limited use. I do see what you are saying,
though, because I'm sure it's frustrating to want to look out there for a
nice pure-Python issue, then the first 10 issues you click on require C code
(or vice versa).


> 2. I need ability to set "Needs review" flag back. Some issues were
> once reviewed, but since then they've got modified and need further
> comments.  The need the review again. That means pushed back _into the
> end_ of patch queue.
>

I don't think the "needs review" flag gets unset, but if it has been unset
manually and you've made changes, you can ask for another review. If you can
get the changes made quickly, you might be able to get the previous reviewer
to look at it again while it's still fresh in their mind.


> 3. Setting bug dependency by users. Often nobody wants to care about
> issue, because it is just too long, there is much irrelevant comments
> and nobody has time to read it. We don't have personal digg-like
> comment filters to cope with the amount of text to be brain-loaded.
> But it is possible to refactor such issue thread into separate
> digestable issue/issues.
>
>
> P.S.  About personal comment filters if anybody is interested in that.
> Digg-like +1, -1 are good for voting, but for filtering it would be
> nice to: 1. have several filters for different aspects of the thread,
> 2. have JS filter by marking individual phrases in comments and adding
> ranges to filter using jquery / ajax
>
> This way reviews will be more fun and easy.
> --
> anatoly t.
>

I think that would take away from the goal of fixing the issue. Even some -1
comments could contain helpful information, but you might have to explicitly
click on that hidden comment to find out.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100319/3c75a976/attachment.html>