[Tracker-discuss] Feature/Change request handling procedure

[Brett Cannon]

On 11/30/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>
> Neal Norwitz schrieb:
> >> I'm slightly uncomfortable about that approach since it
> >> codifies a process which isn't codified so far. The
> >> discomfort is only about the codification - I can see
> >> that the implied process could actually work.
> >
> > But don't we mostly do that already?
>
> That's true. Still, we currently have a flag "is patch"
> (by having the issue in the patches tracker), so it would
> be a deviation from the status quo not to have that anymore.


Yeah, but the status quo sucks so I think it is fine to deviate.  =)

I know these fine points are not important for the initial
> setup, as they can be changed afterwards. So coding a work-flow
> into the tracker is fine with me, I guess.
>
>
I agree with Neal; let's go ahead and change how things are done now and if
it becomes an issue we can change it.  But I suspect if we help make it easy
to search for issues that are in a specific state it will not only let us
keep on top of things that need to be dealt with in a specific way (e.g.,
patch reviews), but also lets us get people to help us more in terms of
triaging bugs.  Bug days, for instance, could have total newbies look at
'open' bugs to help us flag them properly instead of having to go through
existing bugs and try to find easy ones to deal with.  Better granularity
(w/o being to restrictive) should be a good thing in this respect.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/tracker-discuss/attachments/20061130/5a4eb504/attachment.htm