[Python-Dev] Addition of further status options to tracker

[Daniel (ajax) Diniz]

Hi Tennessee,
I plan to take a look at all open issues before PyCon, do you want to
join forces? :)

Tennessee Leeuwenburg wrote:
> I am beginning reviewing some more issues in the tracker. I think it would
> be useful to have the following status options (new status options marked
> with a '+'):

Great! Thanks a lot :)

I think your ideas are good, but believe you should take a better look
at the Stages, some messages from this list and tracker-discuss from
February, and Brett's document linked from there.

>   + Request Approved: Means that the issue is marked as worth further
> development by the community

Not sure it's a 'status', but I like the idea of disambiguating
between 'send us tests/patches so we can think whether the bug/feature
is valid' and 'the bug/feature is valid, send us tests/patches'.
However, it might be better to merge this with 'Specification
Approved', as the important bit is 'contributions on this are
welcome'.

>   + Specification Approved: Means that the functionality to be developed is
> written down in some form, and agreed at least in general terms (preferably
> in fairly specific terms)

See above. +1 on a way to make this clear, -0 on it being separate
from the above, -1 on being a status.

>   + Under Development: Means that an implementation is currently under
> development

This one I like a lot, but think it should be a keyword, like
'claimed'. I think it should be set when someone says "I'll work on
this one". But if you mean 'should be under development', -1 :)

>   + Under Final Review: Means that a patch has been submitted and may be a
> flag that core developers can usefully review the work done without having
> to revisit the whole process

-1, as it is rather redundant with Stage.

[...]

> My reasoning for this is as follows:
>   Example one: I am currently reviewing issue 2706 which covers
> datetime.timedelta operators. I have a reasonable amount of familiarity with
> time programming and think I have some valuable input on the functionality
> aspects, however I'm not a super-great C programmer. I'd like to help with
> coming up with the final feature specification, but then leave it to others
> to consider the merits of the C code patch. Being able to help get this
> marked as "request approved", then "specification approved" might help speed
> up a lot of the process of developing the patch and getting it accepted. It
> also saves code developers from having to develop an implementation while a
> functionality debate is still ongoing...

You can provide unit tests (and perhaps an equivalent Python
implementation),  they are a great way to specify behavior. Also, they
are required for a healthy commit and make the corner cases easier to
spot.

>   I think that having these additional steps will help to avoid erroneous
> development of non-features, and also break up the review process into more
> manageable chunks of work.

I think core developers shouldn't waste time setting a hundred little
fields on each issue, but giving them practical ways to query (and
denote) these extended properties seems worthwhile.

> Of course I realise not everything needs such a
> delineated process, but by the same token it might assist in keeping some of
> the less visible/popular changes moving through the process...

Well, there's the signal-to-noise ratio to consider too. Like with the
nosy_count noise issue, things might get in the way of developers work
(I'll work on this soon, promise :D).

I'll be doing some janitorial tasks this week and next, triaging
issues and populating their fields. If you want to discuss specific
changes or suggest different methods/goals/rules for this work, I'd be
very grateful. If you want to join the tracker janitors club, remember
to bring a shrubbery :)

Regards,
 Daniel