[tor-dev] Survey on Tor Trac usage and how you manage your tasks

[katmagic]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110912/719865bb/attachment.pgp>