Trac Ticketing guidelines

[Chris Pickel]

On 15 Jul, 2007, at 5:44, Juan Manuel Palacios wrote:
>> My understanding of the difference between these is that an  
>> enhancement is something that goes /into/ the repository, whereas  
>> a task is something that's done /to/ it. For example, requesting  
>> an update to port 'foo' is an enhancement, whereas requesting that  
>> 'foo' be renamed to 'libfoo' is a task.
>
> 	Even though I agree you have a point here, I still think the  
> enhancement Vs. task distinction is rather gratuitous. I guess I  
> just need to see more examples to find it useful because I still  
> can't justify it. I'm personally inclined to remove the task &  
> contribution ticket types and stick to simply defect and  
> enhancement, but I'm happy to go by consensus and keep them around  
> even if just a few find them useful.

I don't have a strong opinion. Though one could consider the rarity  
of task reports as being a symptom of the actual scarcity of tasks  
relative to enhancements or defects.

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

>> Colloquy's Trac simply defines these as "highest", "high",  
>> "normal", "low", "lowest" (defaulting of course to "normal"). This  
>> seems much clearer and perhaps more useful than our current system.
>
> 	I agree with Ryan and you here, but then with Ryan again: I think  
> "high", "normal" and "low" should suffice for most (if not all) our  
> needs, while also sticking to self-explanatory names (I didn't  
> write the current priorities, I also said "wha...?" when first  
> becoming acquainted with our trac installation ;-). When you have  
> both "highest" and "high", how is what's put in each determined? We  
> want to keep this as simple as possible (but not one bit simpler,  
> as Albert once said).

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.

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

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.


Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
Url : http://lists.macosforge.org/pipermail/macports-dev/attachments/20070715/dce931e4/PGP.bin