Re: [Python-Dev] Addition of further status options to tracker
[adding python-dev back on to the email] On Tue, Mar 10, 2009 at 15:51, Tennessee Leeuwenburg wrote: > >>> 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. >> > > Yep. I like that too. > > >> 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. >> > > Now that I am understanding the tracker system better, I think it's fine to > just add reviews to the tracker issue and that will be enough to grab > attention. There is always the option of emailing the list. > > >> >> 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. >> > > Sounds exactly right. I'm not so concerned about this field being updated. > If it doesn't, but someone is clearly working on it, then it's not really > holding anyone back. Tracker janitors (although I do prefer gardeners!) can > worry about whether the field is set correctly, and developers can just get > on with doing their work. > > I like: >"Open/New" >"Needs help / Chatting" >"Under development" >"Pending feedback" >"Closed" > > very much. > > As long as "Under Dev" and "Pending" are time-based to switch to "chatting" or "closed" respectively, I am fine with this. What do other people think? Too heavy-handed? Just right to help people get people involved? -Brett > ...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. > > > > Maybe we can just revert anything that is under development back to "needs > help" after a month of inactivity? > > 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
Re: [Python-Dev] Addition of further status options to tracker
On Tue, Mar 10, 2009 at 15:33, Nick Coghlan wrote: > Brett Cannon wrote: > > 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. > > If an issue is assigned, then somebody has claimed it and is working on > it (or it has at least been sent to a specific person for consideration). > Right, but that is for core developers only. I think Tennessee is worrying about non-core folks. -Brett ___ 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
Re: [Python-Dev] Addition of further status options to tracker
Brett Cannon wrote: > 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. If an issue is assigned, then somebody has claimed it and is working on it (or it has at least been sent to a specific person for consideration). Deciding that someone has dropped off the face of the planet and that their issues should be unassigned is something that a human tracker janitor would probably have to decide to do (the original assignee would get email about the assignment changes and have the option of reclaiming issues they still cared about). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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
Re: [Python-Dev] Addition of further status options to tracker
On Mon, Mar 9, 2009 at 22:39, Tennessee Leeuwenburg 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 ig
Re: [Python-Dev] Addition of further status options to tracker
Tennessee Leeuwenburg gmail.com> writes: > > Hi all,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 '+'): I have to point out that the more alternatives there are to choose from, the more choosing from them can feel like a bureaucratic burden. Since Python has no formal development process (as opposed to, say, Twisted), I think the tracker should match today's quite informal and flexible way of working. ___ 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
Re: [Python-Dev] Addition of further status options to tracker
> > 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
Re: [Python-Dev] Addition of further status options to tracker
On Mon, Mar 9, 2009 at 21:00, Tennessee Leeuwenburg wrote: > > > On Tue, Mar 10, 2009 at 2:39 PM, Brett Cannon wrote: > >> >> >> On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg < >> tleeuwenb...@gmail.com> wrote: >> >>> Hi all, >>> >>> 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 '+'): >>> Open: Means that the issue has been created and not further reviewed >>> + Request Approved: Means that the issue is marked as worth further >>> development by the community >>> + 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) >>> + Under Development: Means that an implementation is currently under >>> development >>> Pending Feedback: Means that work is suspended pending feedback >>> + 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 >>> Closed: Means that the issue is either suspended indefinitely or has >>> been resolved (see resolution value) >> >> >> I assume you want all of this for the Status field, correct? >> >> As for the options, some of these overlap with the Stage field. For >> instance, if something has been set to any stage other than >> "accepted/rejected" it means it needs to be looked into, so that duplicates >> your "Request Approved" status. Similar thing with the review stages and >> "Under Final Review". >> >> But a general "under development" status would probably be worth adding. >> That way if an issue is "open" it needs attention, "Under development" means >> someone is working on a solution, "pending" means someone is blocking the >> issue for more information, and "closed" means closed. >> >> One thing to watch out for, Tennessee, is getting too specific. Like your >> "Request Approved" and "Specification Approved" just seems too heavy-handed >> to my tastes. Personally, I prefer to make sure the issue workflow to be >> somewhat simple so that people don't end up arguing over stuff like whether >> something has been specified well enough to have it set to "Spec Approved" >> even if someone else disagrees (which you know would happen). >> >> -Brett >> > > Hi Brett, > > Some great points. The "stage" settings do overlap a lot of what I had > suggested. What I'm trying to reach is a way to flag quite clearly whether a > tracker issue is: > * In need of a first response > * Being taken care of by someone > * Needs the attention of core developers, just about ready > > At the moment, the open/closed settings are a bit useless -- issues are > "Open" until they are finished, at which point they are "Closed". I > personally suspect that "Pending feedback" is little-used. > For now. But once auto-closing of pending issues is set up then it will get used consistently (don't ask me when that is happening, I just know Daniel and Martin have been talking about it). > At the moment, many "Open" issues are in various states of maturity or > disrepair, so the only really useful information is whether an issue is > "Closed". > > Examining the stage options more closely, they are very code-oriented. > Right, because we are dealing with code. =) > Really they relate to implementation, not other parts of the process. It's > difficult for me as someone who wants to help out with the Issue resolution > process as much as coding to take an atomic action to help advance the issue > through a process. > > What do you think about the following "Status" flags: > > * Open: Means newly-created, needs early attention > * + Request for Comment: Means that a discussion regarding functionality > is requested > * + Under Development: Means that a caring developer is taking care of it > * Pending Feedback: blocking on new information > * Closed: Means closed > > Once the issue is marked as under development, more information is then > provided by the "Stage" flag. > > "Request for Comment" means that anyone who is stuck on trying to get their > ideas sorted or a loose specification agreed on can call for feedback > through this flag. There's still some risk of arguments blocking the > progression to "Under development", but the issue owner can at least pass to > "Under development" at their own will without requiring universal agreement. > There is also a worry of abuse if anyone can set this. If only people in the Developer role can set this then that's fine. But if people start using this just to get attention because they are unhappy with how slowly something is going it will kill its usefulness. > > Core developers can then search on 'commit review' or 'patch review' to see > what could use their attention, while people who are happy to contribute to > the debate can search on "Open" and "Request f
Re: [Python-Dev] Addition of further status options to tracker
Terry Reedy wrote: > The other problem with too many specifics is non-use. As it is, an issue is > sometimes closed with no resolution marked, so one has to scroll down, > possibly a long way, to see whether it was accepted or rejected. (Is it > possible to require a resolution when closing?) Yes, it is possible. If you think it should be implemented, file a RFE in the meta tracker. However, it'll also be much easier to mass-edit issues in the near future, so if this kind of (careful) cleanup can be done by tracker janitors later, it might be best to leave core developers free of these requirements... Soon we'll also have the option of marking an issue as Pending and having it automatically closed some time later. 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
Re: [Python-Dev] Addition of further status options to tracker
Brett Cannon wrote: On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg mailto:tleeuwenb...@gmail.com>> wrote: Hi all, 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 '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + 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) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + 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 Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) I assume you want all of this for the Status field, correct? As for the options, some of these overlap with the Stage field. For instance, if something has been set to any stage other than "accepted/rejected" it means it needs to be looked into, so that duplicates your "Request Approved" status. Similar thing with the review stages and "Under Final Review". But a general "under development" status would probably be worth adding. That way if an issue is "open" it needs attention, "Under development" means someone is working on a solution, "pending" means someone is blocking the issue for more information, and "closed" means closed. I like this. Open would mean that triage is still needed: reject and close (or provisionally reject 'pending'), fix and close, or move to 'under developemnt. One thing to watch out for, Tennessee, is getting too specific. Like your "Request Approved" and "Specification Approved" just seems too heavy-handed to my tastes. Personally, I prefer to make sure the issue workflow to be somewhat simple so that people don't end up arguing over stuff like whether something has been specified well enough to have it set to "Spec Approved" even if someone else disagrees (which you know would happen). The other problem with too many specifics is non-use. As it is, an issue is sometimes closed with no resolution marked, so one has to scroll down, possibly a long way, to see whether it was accepted or rejected. (Is it possible to require a resolution when closing?) Terry ___ 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
Re: [Python-Dev] Addition of further status options to tracker
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
Re: [Python-Dev] Addition of further status options to tracker
On Tue, Mar 10, 2009 at 2:39 PM, Brett Cannon wrote: > > > On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg < > tleeuwenb...@gmail.com> wrote: > >> Hi all, >> >> 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 '+'): >> Open: Means that the issue has been created and not further reviewed >> + Request Approved: Means that the issue is marked as worth further >> development by the community >> + 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) >> + Under Development: Means that an implementation is currently under >> development >> Pending Feedback: Means that work is suspended pending feedback >> + 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 >> Closed: Means that the issue is either suspended indefinitely or has >> been resolved (see resolution value) > > > I assume you want all of this for the Status field, correct? > > As for the options, some of these overlap with the Stage field. For > instance, if something has been set to any stage other than > "accepted/rejected" it means it needs to be looked into, so that duplicates > your "Request Approved" status. Similar thing with the review stages and > "Under Final Review". > > But a general "under development" status would probably be worth adding. > That way if an issue is "open" it needs attention, "Under development" means > someone is working on a solution, "pending" means someone is blocking the > issue for more information, and "closed" means closed. > > One thing to watch out for, Tennessee, is getting too specific. Like your > "Request Approved" and "Specification Approved" just seems too heavy-handed > to my tastes. Personally, I prefer to make sure the issue workflow to be > somewhat simple so that people don't end up arguing over stuff like whether > something has been specified well enough to have it set to "Spec Approved" > even if someone else disagrees (which you know would happen). > > -Brett > Hi Brett, Some great points. The "stage" settings do overlap a lot of what I had suggested. What I'm trying to reach is a way to flag quite clearly whether a tracker issue is: * In need of a first response * Being taken care of by someone * Needs the attention of core developers, just about ready At the moment, the open/closed settings are a bit useless -- issues are "Open" until they are finished, at which point they are "Closed". I personally suspect that "Pending feedback" is little-used. At the moment, many "Open" issues are in various states of maturity or disrepair, so the only really useful information is whether an issue is "Closed". Examining the stage options more closely, they are very code-oriented. Really they relate to implementation, not other parts of the process. It's difficult for me as someone who wants to help out with the Issue resolution process as much as coding to take an atomic action to help advance the issue through a process. What do you think about the following "Status" flags: * Open: Means newly-created, needs early attention * + Request for Comment: Means that a discussion regarding functionality is requested * + Under Development: Means that a caring developer is taking care of it * Pending Feedback: blocking on new information * Closed: Means closed Once the issue is marked as under development, more information is then provided by the "Stage" flag. "Request for Comment" means that anyone who is stuck on trying to get their ideas sorted or a loose specification agreed on can call for feedback through this flag. There's still some risk of arguments blocking the progression to "Under development", but the issue owner can at least pass to "Under development" at their own will without requiring universal agreement. Core developers can then search on 'commit review' or 'patch review' to see what could use their attention, while people who are happy to contribute to the debate can search on "Open" and "Request for Comment" issues. Obviously the RFC flag is redundant when an issue is first raised, since the submitter always has the option of simply emailing this list. However, for older, potentially stale issues, it is a useful indicator that the issue may be either closed out or could use refreshing. 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
Re: [Python-Dev] Addition of further status options to tracker
On Mon, Mar 9, 2009 at 20:25, Tennessee Leeuwenburg wrote: > Hi all, > > 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 '+'): > Open: Means that the issue has been created and not further reviewed > + Request Approved: Means that the issue is marked as worth further > development by the community > + 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) > + Under Development: Means that an implementation is currently under > development > Pending Feedback: Means that work is suspended pending feedback > + 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 > Closed: Means that the issue is either suspended indefinitely or has been > resolved (see resolution value) I assume you want all of this for the Status field, correct? As for the options, some of these overlap with the Stage field. For instance, if something has been set to any stage other than "accepted/rejected" it means it needs to be looked into, so that duplicates your "Request Approved" status. Similar thing with the review stages and "Under Final Review". But a general "under development" status would probably be worth adding. That way if an issue is "open" it needs attention, "Under development" means someone is working on a solution, "pending" means someone is blocking the issue for more information, and "closed" means closed. One thing to watch out for, Tennessee, is getting too specific. Like your "Request Approved" and "Specification Approved" just seems too heavy-handed to my tastes. Personally, I prefer to make sure the issue workflow to be somewhat simple so that people don't end up arguing over stuff like whether something has been specified well enough to have it set to "Spec Approved" even if someone else disagrees (which you know would happen). -Brett ___ 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
[Python-Dev] Addition of further status options to tracker
Hi all, 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 '+'): Open: Means that the issue has been created and not further reviewed + Request Approved: Means that the issue is marked as worth further development by the community + 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) + Under Development: Means that an implementation is currently under development Pending Feedback: Means that work is suspended pending feedback + 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 Closed: Means that the issue is either suspended indefinitely or has been resolved (see resolution value) 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... 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. 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... Comments welcome! Crocker's rules, but please keep it constructive... -T -- -- Tennessee Leeuwenburg http://myownhat.blogspot.com/ "Don't believe everything you think" ___ 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
