[haiku-web] Re: [haiku-admin] Re: Website

Again, cross-posting. Axel and Marcus voted against switching to Trac.

Axel Dörfler wrote:
Besides that I'm very happy with Bezilla as is (you need to come up with something better and working to make me wanna switch - and you would also need to be able to import our existing bug database, of course), I also have the following comments:

1. You can disable SVN for Trac. Then it becomes a simple ticket tracker (I already installed it without SVN. It works!).
2. Trac can import the Bugzilla DB.
3. Trac looks *much* simpler and visually more appealing than Bugzilla
4. Trac is easier to use than Bugzilla (enter your bug on *one* page; no
need to go through multiple steps, better organized, much cleaner)
5. Bugzilla has an interface that is aimed towards developers, not
end-users reporting bugs. as an end-user I would simply not report a bug
at all when I see this interface (I would (and people often enough do!)
just say: "this is too much for me. find the bug yourself!"). That may
be not very important ATM, but we *will* have non-developers reporting bugs.
6. Trac unifies our task management (main website) with bug management
(Bugzilla)
7. Trac automatically generates progress statistics for all milestones,
you can enter a nice list of goals and description for every milestone,
and in a milestone's details users can inspect status per component, for
example. this is a full replacement for our website's task manager and
bugzilla. everything is in one place
8. Trac can be extended to integrate with subversion (later, when the
repos does not have to be on the same server, anymore), so you can even
close tickets from within commit messages, etc...
9. Trac can be integrated with build-automation tools (what our build
factory does, but it's integrated)
10. You can track progress of *all* ticket changes (Timeline).
11. We have to install/write a new task manager for the new website,
anyway. Trac allows us to also manage bugs, so why not take the
opportunity and unify both?
12. Our changes will allow for more flexible bug categorization by users
(Drivers->Audio->auvia). This is especially important if we have many
drivers (and other entries) to select from. That's better than the
current "hack" of using the "[audio-drivers] auivia" naming scheme. It
does not fill up the list so much. Also, the interface will be reduced
to a *reasonable* minimum amount of information a user must enter. No
more unimportant fields.

Okay, hopefully this is a better solution that makes everyone happy:
* use RSS to watch for changes per ticket or all ticket changes
* use Timeline to watch tickets
* maybe have a mailing list
* no subscription or Cc

Why no subscription? It's a damn nice and practical feature. While RSS could be nice, I would hate it as the only solution. 

We had a debate about this. I actually prefer subscriptions (in form of
a simple "Subscribe" link, not a Cc list that everyone can edit), too,
but it seemed to me that the majority does not want them. The next
problem is whether to auto-subscribe every contributor/author or to
require manual subscription. It's probably too annoying for normal
users, so it's better to have the possibility to mail authors manually
for more information.

earlier mail is still valid (in this case: users can't assign, but see who is working on it, users can only create bug reports, but not tasks, ...)

Why shouldn't they? Unless we have someone very enthusiastic about assigning bugs to developers, this doesn't help anybody. If you (as a user) cannot even tell the component, who says you're qualified enough to write a good bug report?

I guess you agree that users should not create tasks, so let's talk about assigning:
Users are not qualified for assigning tasks/bugs to developers. This
is only something that developers should do. How do users know who is responsible for a certain component? Or do you want people assigning their bugs to "axeld" in the hope that it gets fixed more quickly because you are the most active coder? Others may misunderstand and think that you *must* enter a value in "Assigned To". The best solution is to define default-developers per component. So, when someone selects "Networking" Philippe is automatically assigned. But on "Networking->PPP" it's assigned to me, for Kernel it's you, and so on...

And what does that have to do with components? Users *should* select the component that is affected by the bug. That is all we need from a user:
(For users, Type is always Defect and can't be changed)
* summary
* details
* version
* component
* hardware: x86 (Intel/AMD/...), PPC (Apple/...)
* after creation: allow for attachments and further comments
We are responsible for the rest. Only we can decide which priority something gets and who will work on it and only we change a ticket's status. Also, only we can plan milestones. Users can only make "wishes", but they can't tell us what to do, so why ask them for that information, at all? This requires more time to enter a bug, it's a source of potential confusion, and we would have to review it, anyway.

The more people are using Haiku, the more bug reports will come in - and most of these bug reports will be unusable, anyway - IMO that's not even mean, just realistic :)

Here, I agree with you. We can at least try to add a little note:
* how to reproduce
* experienced behavior
* expected behavior
next to the details field, so users at least know what information we need (it's still up to them to read that note and actually write a good bug report, but maybe it helps).

As I said, I'm happy with Bezilla, and I see absolutely no reason to waste any time with searching for (or even writing!) an alternative solution.

I'm extremely unhappy with our bug tracker. Actually, I'm a little bit ashamed of it. This is not what Haiku stands for. It's disappointing that so many developers don't see any problems with Bugzilla.

Bye,
Waldemar

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

Other related posts: