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: > > > > 1. The design sucks. > > You're right, it needs more green! > > > 2. 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? > > 3. 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. > > 4. 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. > > 5. 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? > > 6. 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]. > > 7. 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. > > 8. 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. > > > 9. 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. > > > 10. "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
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev