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

[Brett Cannon]

On Mon, Mar 9, 2009 at 22:39, Tennessee Leeuwenburg
<tleeuwenburg at gmail.com>wrote:

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

OK, let's do what is necessary to flag issues like this so that people can
do this. That's why I like the "Under Development" status. Could rename
"open" to "available" or "unsolved" to more clearly mark those issues as up
for grabs.


> 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, etc.
>
>    * 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.
>

Typically we use nosy lists to get specific people's attention. That or the
priority gets bumped if it turns out to be an important issue. Lastly,
people can email python-dev directly asking for input if all other attempts
to get attention have failed.


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

In other words you want some way to flag an issue that just needs to be
talked about but is not ready to be coded. So status would go "open/new" ->
"chatting/needs help" -> "under dev" -> "closed" with "pending" fitting in
when necessary. Sound about right?

My worry with this is making sure the field gets updated.


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

Doesn't seem to have been much of a problem so far.


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

What I have been telling people is to search for open issues that match up
with what you are looking for based on Stage (whether it be docs, testing,
writing patches), what it affects (based on Component so you can skip
C-related issues) and if it is flagged as easy or not. Your point is that's
fine, but that also turns up issues that people are already working on and
so people constantly bump up against issues that are being dealt with.

I can understand that, but I would worry that if we flag something as under
development it will simply be ignored by other people when they could
actually help out (write the docs for someone, etc.). Or even worse that
someone gets to a certain point with the development, walks away short of
finishing the work (say doesn't get the docs finished) and everyone
continues to ignore the issue because it is still flagged as under
development.

If we can come up with a simple solution to this problem (perhaps have
issues set to under development with no activity shift down a status level
after a month) then maybe we will have something everyone can be happy with.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20090310/ecd5ac94/attachment-0001.htm>