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