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

[Brett Cannon]

On Tue, Mar 24, 2009 at 23:25, Tennessee Leeuwenburg <tleeuwenburg at gmail.com
> wrote:

>
>
> 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.
>

Well, it has been suggested to add a "confirmed" stage to say the issue has
been triaged, but nothing more. After that committers can simply wait until
an issue has reached "patch review" or "committer review" if triaging ends
up working that well.

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