On 9/13/11 5:20 AM, katmagic wrote:
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?
This is primarily a question of effort. We should first try to improve the current situation by making simple changes to Trac. Then we can try more difficult changes to Trac. And then we can think about moving to another tool. It's also unclear though whether another tool would solve all our problems without introducing new ones.
- 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.
OK.
- 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.
There's already a hierarchy in the list in the naming. Tor Client, Tor Relay, etc. are all related to (little-t) tor. What we can do is rename a few components to make it clearer what's a Tor sub-component and what's a different tool:
"Tor Bridge" -> "Tor (Bridge)" "Tor Browser" -> "Browser" "Tor Check" -> "Check" "Tor Client" -> "Tor (Client)" "Tor Cloud" -> "ServerCloud" "Tor Directory Authority" -> "Tor (Directory Authority)" "Tor Hidden Services" -> "Tor (Hidden Services)" "Tor Relay" -> "Tor (Relay)" "Tor VM" -> "VM" "Tor Weather" -> "Weather" "Tor bundles/installation" -> "Bundles/Installation"
I think I wanted to suggest something like this in my mail with the other suggestions, but forgot.
1.9.6 Version
Wow, that list is long.
It is! Therefore the suggestion to throw out old versions.
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.
I don't think we can restrict what people are writing there.
1.9.9 Parent ID
Tickets need to be in a hierarchy. Entering the parent ID manually like this is really cumbersome.
I think we can assume that whoever wants to create child tickets is capable of typing in or pasting a ticket number. This is nothing that the average bug reporter needs to do.
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.
I don't think we can implement either of these two suggestions.
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.
Well, your statement was that you cannot go back and edit a ticket. I didn't look into the permissions in detail and don't have a non-admin user to test this, which is why I asked which permissions you think you need. But I guess I can find out myself.
- 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?
I agree that the current list of Active Reports is confusing. It seems that Tor devs have quite different opinions on how to fix this, so I'll save it for the second round of changes. Easy fixes first.
- 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.
Sounds useful, but unless it's in Trac 0.12, we won't have it.
- 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!
Again, thanks for taking the time!
Best, Karsten