FreeLists / haiku-web / [haiku-web] Trac (reevaluated)

[Waldemar Kornewald <wkornew@xxxxxxx>]

Hi,
unfortunately, not much has happened on the bug&task tracker's side. :(
Well, I'd like to reevaluate/reprioritize our requirements a little bit. Maybe
we can simplify our needs, so the work that is left could easily be finished
within two or three days.

Michael, could we please put a news item on our website? This must finally get
finished!
Help! We need Python and Rails developers! Please adapt Trac and/or help with
RailFrog. See our wiki for a task description:
http://www.haiku-os.org/wiki/index.php?title=Website_Team

Don't be scared:
I've watched the usage of Bugzilla and it seems that the current two-level
categorization approach is not very effective and too ambiguous. Many entries
contain the affected component in the Summary field ("[Keymap] Typing ..."),
sometimes even though it has already been selected in Component field, and
often it does not make a lot of sense to have this two-level categorization
because either  the affected application is not mentioned in the list or only
one level is needed.
What do you think? How much do we need this, anyway? A nice one-level scheme and
good examples next to free-form text fields
(example: "[ShowImage] zooming does not work")
could be at least as good as what we have now.

I guess don't need to replace the current Cc subscription system right now. That
can wait.

What is left for a first real-world Trac test? Copy+pasted from wiki:

Only developers and admins are allowed to create tasks. Users may only create
"bug" and "wish" tickets (later, we might not allow for wishes, anymore). This
probably requires permissions per ticket type.

Only developers and admins can be assigned to tickets.

Milestone, Priority, and Status (and for ticket creation: Assign-To) should only
be editable by developers and admins. For normal users the drop-down fields
should be hidden. TICKET_APPEND is okay to start with, but non-editable fields
should be hidden instead of just disabling them.

Simplify "resolve as" drop-down list:

    * fixed
    * duplicate
    * invalid (and comment on *why*)
    * junk (mostly used for bogus entries)

Rename ticket type "defect" to "bug".

When creating tickets, next to the description field there should be a little
note:

 For "bug" reports, please specify:
 * how to reproduce
 * experienced behavior
 * expected behavior

Remove Keywords field.

Remove Severity field. Priority should have these values:

    * blocker (MUST be fixed ASAP, mostly used for bugs)
    * critical (MUST be finished for the affected milestone)
    * high (important; might sometimes be moved to next milestone)
    * normal (don't know exactly how important it is)
    * low (nice to have; may never get done; first target of rescheduling)

Priority should always be seen in the context of the assigned milestone.

Disable wiki.

Disable SVN plugin.


Now, is that simple enough to get someone working on this? We can't get any
simpler! This is my last offer! :)

Bye,
Waldemar Kornewald


-----------------------------------------------------------------------
haiku-web@xxxxxxxxxxxxx - Haiku Web & Developer Support Discussion List