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

Tue Sep 13 10:48:34 UTC 2011

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:
>>>
>>> 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?

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.

>>> 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.

OK.

>>> 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.

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.

>>> 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?

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.

>>> 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.

Sounds useful, but unless it's in Trac 0.12, we won't have it.

>>> 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!

Again, thanks for taking the time!

Best,
Karsten