On Mon, 2011-09-12 at 15:57 +0200, Karsten Loesing wrote:
On 9/6/11 11:01 PM, katmagic wrote:
Sorry for the late reply — I haven't checked my email in a while — but I'm replying anyway because I've some strong feelings on this issue. In short, Trac sucks. My issues with it are as follows:
- The design sucks.
You're right, it needs more green!
- There's no AJAX. Now, I know a lot of people on this list hate Web
2.0, but I really think its irrational. Especially over Tor, reloading pages as many times as Trac makes you do is time consuming and cumbersome. Of course, I'm not advocating making it *require* JavaScript, but it would certainly be a nice feature.
This isn't something we can influence. Well, assuming that we want to keep using Trac for a while.
Why should Trac be assumed?
- An unreasonable number of pages must be navigated through in order to
perform simple functions. The difficult of doing this prevents people from finding bugs, and therefore discourages contribution.
Can you be more specific how we could fix this?
Maybe hierarchical CSS menus on the header? There are a myriad of ways to do it, though I don't think Trac can implement any of them.
- There are too many options. There are oodles of options that must be
fiddled with every single time a ticket is created, and if one makes a mistake, it's not possible to go back and edit the ticket.
The survey had questions about all statuses and ticket fields to evaluate their usefulness.
1.9 How relevant are the following ticket fields for you?
1.9.5 Component
There are way too many of these for a flat list. A hierarchy of some sort might work, but the component could just as easily be a keyword.
1.9.6 Version
Wow, that list is long.
1.9.7 Keywords
It would be helpful to have a (perhaps hierarchical) list of previous keywords to choose from, in addition to creating custom ones.
1.9.9 Parent ID
Tickets need to be in a hierarchy. Entering the parent ID manually like this is really cumbersome.
1.9.10 Points 1.9.11 Actual Points
What are these things for, anyway? If only mikeperry uses them, maybe they should be local to a user? Maybe there should be a generic, user-local field for annotations.
The fact that it's not possible to go back and edit a ticket may be a permission problem. What permissions are you missing? On the other hand, you can always add another comment saying what you really meant.
How am I supposed to know what permissions I have? And having to correct things in separate comments will lead to a bunch of poorly worded, inaccurate, or superfluous comments or tickets.
- Searching for tickets is a confusing and somewhat difficult task. In
order to search for one's own tickets, for example, one must navigate a menu with FORTY choices with unclear labels.
Do you mean the custom query form? Which parts of it do you find hard to understand for new
Even the 'View Tickets' view is confusing. Firstly, sorting shouldn't be listed on the View Tickets page, but as an option chosen on that sub-page. Secondly, the option descriptions are ambiguous. What does 'My Tickets (all)' mean? Does it mean tickets I reported? Tickets assigned to me? Tickets I'm CCed on? Tickets I've commented on? or some combination of these?
- Searching in general doesn't work very well. Whatever algorithm Trac
uses for search is awful.
I don't think we can change this [without switching from Trac].
- Trac sends email about your own modifications, and about a lot of
things people probably don't want email about (i.e. every comment on a ticket). A significantly improved method would be to offer notifications on the website itself.
I think two other people stated that they don't want to have emails for their own modifications. Actually, I find that useful, because I'm using my inbox as an archive that I can search even when I'm offline.
I'm not sure what you mean with notifications on the website itself.
There'd be a notice on the website navigation header alerting you that you have messages. When you click on it, you'd be taken to a page with a list of new tickets, replies, etc. You could also have notifications for saved searches here, rather like Twitter.
- Trac does not integrate with Git. It should allow you to reference
commits from tickets, and reference tickets from commit messages (viewed in the web interface). Being able to close tickets from commit messages would also be useful.
We need to install the Git plugin for that. This is one of the things we should change, yes.
- HTTP Basic authentication could be confusing for some users. A
cookies-based system would probably be easier, and allow for persistent logins (which most people consider a good thing).
I don't think we can or should change this.
- "Points" are annoying. I'm not personally a fan of 'agile
development', and I really don't want to get notifications about it. Again, finer-grained control over notifications would probably solve this.
Finer-grained control over notifications is probably the answer.
Because of these reasons, I think Trac actually discourages contribution. It's *much* easier to report a bug, say, on GitHub than on Trac, and it's much easier to get updates about progress on it; both of which are things that are important to the average person reviewing a bug.
I still believe we should first try to tweak Trac to fit our needs before moving on to the next tool.
Thanks for your input!
Best, Karsten