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.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo/macports-dev
