[Python-Dev] Addition of further status options to tracker
tleeuwenburg at gmail.com
Tue Mar 10 06:39:29 CET 2009
> I don't mind what approach is taken -- I'm happy to work within the
>> current infrastructure if someone can suggest a good way. I really just want
>> to be able to start distinguishing between issues that are essentially new
>> and under debate versus issues that most people agree are a "Good Thing To
>> Do", and then helping those issues advance to the point of implementation by
>> discussing and, if necessary, formalising or recording requirements against
> I have always viewed it that if Stage is set to anything other than its
> empty default it is worth looking into. But it seems to me what you are
> after is some obvious way to disambiguate issues that are feature requests
> that someone has just asked for and anyone can work on if they want, and
> issues that require attention, i.e. bugs and patches. Is that accurate?
Pretty much. I've got two views. One is that I'd like to search for issues
that are up for grabs which I could take over, hack on, and generally not
get underfoot of core development activity. The other is that I think I can
help with issue gardening -- splitting issues up into those which still need
some more thought, those which someone should pick up and start working on,
* Ideas needing more consideration
* Ideas being hotly debated
* Good ideas with no owning developer
* Ideas currently under initial development
* Ideas ready for consideration by the core developers
In order to make the most use of experienced developers, I'd say it's
important that they spend most of their time concentrated at the bottom of
that list. Bugs and patches more or less automatically qualify for that, and
they can be searched on pretty effectively now. However, doing gardening on
the issues which aren't quite there yet is currently pretty clumsy.
Say I'm a core developer and very busy. I'd like to quickly address bugs if
possible, and I'm happy to help out on important new issues. I certainly
don't want to trawl through a whole lot of immature issues and do the triage
myself -- what a waste of time! Right now, what can such a person search on
to find the relevant issues? It looks like "patch review" or "commit review"
will do nicely. This isn't going to change, so that is still supported. Bugs
are essentially everything not a feature request, so that doesn't change
Okay, so the developer workflow is simple and supported. But what about
pre-core development workflow?
How about for those involved in performing triage and specification? Where I
work, at least 50% of the time is spent just working out what to do. There's
a lot of real work in triage and specification, and it really shouldn't be
done by core developers who could be churning out shiny new stuff. That
means that the triage team (or issue janitors) need to be able to support a
workflow this is pretty easy on them, too. At this stage, we're not dealing
with code, we're just dealing with problems.
If we want people with great ideas to get to the top of the heap quickly, we
need some way to facilitate that, while issues that are either inappropriate
or being hotly contested don't suck time away from more important things.
Anyway, I really do just want to fit in. I'm just butting into some workflow
things which seem a bit clumsy when doing issue gardening or when finding
coding tasks that are up for grabs for a python-dev newbie...
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev