[Tracker-discuss] bugs.python.org schema redesign

[Tennessee Leeuwenburg]

On Wed, Mar 25, 2009 at 4:47 PM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> Brett Cannon writes:
>
>  > What do other people think? If others are happy with Stage as it is then
> we
>  > could add the "Needs docs" step along with "Needs backporting" and that
>  > should fill in the gaps along with a "Needs Decision" keyword to help
> grab
>  > the attention of core developers when people are stuck and need help
> with
>  > deciding how to do something (should address Tennessee's desires).
>
> There's plenty of stuff that "needs decision" being discussed on
> python-dev.  Are committers really going to troll the tracker for the
> "needs decision" keyword?


I'm not sure that "needs decision" does in fact address what I'm talking
about, and I am also concerned that it would make the committers life
harder. What I wanted wasn't a flag to get a committer's attention on the
issue, but rather a flag for the committers not to waste their time until
the issue has been bashed into shape. It's a flag that the people involved
are still debating what to do about the issue, and it's not yet ready for
higher consideration.

Under that model, I imagine the core committers would do what (I think) they
have always done -- react to what is on python-dev, review patches when they
are flagged as ready, and take up specific issues which are of interest to
them.

I would use use the new flag when processing new issues often. I'm currently
involved in a discussion about the implementation of additional operators
for timedelta objects, for example. In this case there's a patch, but the
functionality is still being debated amongst the group (it had been dormant
for a while before  I commented on it). If I want the input of a committer,
there's nothing stopping me from posting to python-dev for more input.
However, I would love to mark the issue as "under discussion" so that I can
start categorising issues into two camps -- one which is ready for
development and one which is not. For example, I'm considering building some
sub-issues, some which deal with uncontroversial aspects of the parent
issue, so that they can move forward, and others which will concentrate on
the thorny bits. At the moment, all the new functionality is being blocked
by the debate.

I feel that I have all the power I need to get more attention to this issue
if I want, but what I can't do is exclude it from the list of "new" issues.
It's not ready for any of the "stage" levels as yet, but it's not "fully up
for grabs" either. It's in a pre-development, post-triage state.

Cheers,
-T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tracker-discuss/attachments/20090325/5f998e20/attachment.htm>