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.