> > 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. 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. 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. 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... Cheers, -T
_______________________________________________ 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
