[Tracker-discuss] Feature/Change request handling procedure

[Stefan Seefeld]

Georg Brandl wrote:

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

Conceptually these all seem to fit into the 'invalid' box. It may make
sense to spell them out if you want to be able to query for them. Otherwise
providing the rest of the feedback in a message could be enough.
So: Do you think querying for the cases you mention is a frequent enough
use case to warrant these additional resolution enumerators ?

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

OK.

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

Sure. However, the reason for me to distinguish between severity and priority
is precisely to be able to draw the line between the evaluation of the user,
and the evaluation of the bug fixer.
I would find it rude for developers to reset the severity, and I think it
isn't the user's business to tell developers in what order to process bugs
either. (Note that I'm talking about roles here, not actual persons. A single
person may well play both roles...)

Therefor I believe that severity should be writable by everybody (though
developers should respect the ranking given by the OP), while priorities
should be writable only by (potential) bug fixers, i.e. developers.


Regards,
		Stefan

-- 

      ...ich hab' noch einen Koffer in Berlin...