Trac Ticketing guidelines

[Ryan Schmidt]

On Jul 15, 2007, at 15:40, Chris Pickel wrote:

>> I believe the type ticket field is already ignored enough, the  
>> vast majority of tickets simply go by the default (defect) even  
>> when some of them don't belong in it:
>>
>> defect: 5480
>> contribution: 24
>> enhancement: 1141
>> task: 52
>>
>> 	So it doesn't make much of a difference to me to keep the smaller  
>> two around. I do care, however, about making report filings as  
>> simple & accurate as possible.
>
> Perhaps you want to create "unclassified" as the default, so then  
> at least we can tell the difference between people who actually  
> think it's an defect vs. people who haven't set it appropriately.

I like that idea! But then we should look at doing that for all  
select boxes, don't you think?

> I had a look at Adium's Trac, and they don't seem to allow  
> priorities or milestones to be set at all. Tickets in their system  
> do have priorities, though, so they appear to be set only by  
> admins. That's not a bad system either but would require more  
> vigilance with the bugs. They also use highest-lowest like Colloquy.
>
> However, I again don't have a strong preference, but to build on  
> Ryan's comment, we could have the severity be reported by users and  
> the priority used internally.

If we do keep Severity, we need to overhaul those values too, since  
they don't make much sense either. But again, why do we need both  
severity and priority? To me they sort of mean the same thing. Do  
they mean different things to you?

>> I'd really love it if we could group these two fine ideas in just  
>> a single milestone (simplicity is golden!) that conveys the idea  
>> of "Will be worked on later"; and based on that, I'd like to use a  
>> name other than "Base", as some users are likely to not know what  
>> that means. Can you help me come up with a suitable name? I'm a  
>> bit sleepy already ;-)
>
> I think that "Core" might be a workable term, particularly with  
> Apple's heavy use of it. "System" is also OK but could potentially  
> be ambiguous. "Infrastructure" conflicts with our current use of it  
> as a component but is otherwise good.

"Core" sounds good to me. Hopefully users will recognize its meaning  
too.

I didn't realize "Infrastructure" was already used in a component. I  
guess there it refers to the servers, repository, rsync setup, ticket  
system, etc.?

> One final thing is that it would be nice to know if an update is a  
> maintainer update or just a contribution. The former are very  
> simple to deal with, and could be dealt with even better if they  
> were already flagged as such.

Whether it's flagged that way or not, anybody looking to commit the  
contribution would still need to verify the submitter's email address  
against the port maintainer's address, so I don't know if the flag  
would be that helpful. Seems to me like it would rather be more work:  
now we have to check not only if the email address matches, but also  
if it's been categorized correctly, and fix it if it hasn't.