[Tracker-discuss] Feature/Change request handling procedure

[Georg Brandl]

Stefan Seefeld schrieb:
> Brett Cannon wrote:
> 
>>     * version is an enum to express the python version (or branch) the
>>     problem
>>       occured in.
>> 
>> 
>> Is this a single setting, or can it have multiple values?  If we
>> automatically close old bugs, it might get us to deal with things faster
>> and thus we won't have bugs from a couple versions back.  But otherwise
>> we can end up with bugs where they are present in 2.3 and people need an
>> easy way to note that it is still present in 2.5, etc.
> 
> Good point. It certainly can be a multilink, i.e. refer to multiple
> versions / branches. (An interesting side-note: if we hook up with
> subversion, we probably want to track changes to individual branches
> and only close out the parts of a bug that got affected by a checkin.)
> 
>> This also brings up the idea of having a dependency field.  If I am
>> waiting for feedback or more details from someone, set that field to
>> their username.  If I don't here from them after a set amount of time
>> (like two weeks) the bug gets closed automatically for lack of information.
> 
> Right. I think there can be a status enumerator for this state, together
> with a timer that gets started whenever that state is entered.

Good. That's continuing the SF "Pending" state then.

>>     * severity is an enum allowing users to express the impact the bug
>>     has on them,
>>       such as: (critical, major, normal, minor)
>> 
>>     * dependencies: a list of bugs that need to be fixed before this can
>>     be fixed.
>> 
>>     * status: one of (new, open, closed)
>> 
>>     * resolution, set when status is set to closed: one of (fixed,
>>     invalid, duplicate) 

I would also add "rejected" for patches and "works for me". I don't know if
we need "won't fix". Something like "out of date" is also useful.

>> Also add "Lack of Info" or something since we end up with bugs that just
>> sit there waiting for more info from the OP that we never get.
> 
> Good point. Wouldn't that be the same status enumerator as above
> (or at least, very similar) ?

I'd say that if the "pending" state period is over with no response, set
status to "closed" and resolution to "lack of info" *if* it isn't already
set to another value. This allows to handle both the cases where you need
more info to process the bug, and where you processed it but want to give
the OP the opportunity to comment before closing it.

>>     Users submit bugs, setting title, and optionally components,
>>     platforms, version,
>>     and severity.
>> 
>> 
>> Don't let them set severity.  I have gotten into mini competitions with
>> OPs over resetting the severity.  They think they know better than me
>> what is severe and what isn't.  And everyone's bug to them is severe.  =)
> 
> I guess that's your call. I have made good experience with such a flag.
> And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)

Can't the field become locked after the original submission?

Georg