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

Roger Dingledine arma at mit.edu
Mon Sep 12 13:51:26 UTC 2011

On Tue, Sep 06, 2011 at 10:44:11AM +0200, Karsten Loesing wrote:
> The Component field (10, 1, 1) is used to find/filter tickets and guess
> who's paying attention to a ticket.  1 person said that the many Tor
> components make it hard to refer to the software "tor" and that it's
> easier to look at milestones itself.

I guess that would be Nick. I wouldn't object to making some other Trac
field besides 'component' to categorize things. But lumping 500+ Tor
tickets into one component, with no way to break them down by category,
is going to make it much harder to find tickets.

(I search for tickets by pulling up all the tickets in a given component,
and then using my browser's search feature to thumb through them.)

> The Version field (3, 3, 5) is not used by many components and is
> considered not very useful, because bug reporters get versions wrong in
> most cases anyway.  Also, current versions of products are never in the
> list.
> [Suggestion: Delete all obsolete versions from the list, and try harder
> to add new versions.]

When you delete a version from the list, does it vanish from tickets
that reference it? That is, will we be destroying history by deleting
an old version?

> The Points (1, 0, 10) and Actual Points (1, 0, 10) fields are actively
> used by only 1 person and read by 1 other person.
> [Suggestion: Investigate whether it's possible to suppress email
> notifications for changes to the Points and Actual Points fields.]

I actually find these mails about as useful as the other mails, insofar
as they tell me that Mike is thinking about working on a given ticket.

But I can see how people who don't care what Mike is going to work on
soon would not want to see them.

> The new (2, 1, 4), assigned (1, 3, 5), reopened (1, 2, 5), and accepted
> status (1, 1, 6) have slightly different meanings for some people, but
> are mostly equivalent for the majority.  There are 5 persons who'd like
> to see these four statuses merged into one, e.g., assigned.  1 person
> suggests to narrow down statuses to three statuses: assigned, pending
> (with a combo box for reasons: requester information, code review, code
> push, schedule), and resolved.
> [Suggestion: Investigate whether we can merge "new," "assigned,"
> "reopened," and "accepted" into a single "assigned" status.]

If we merge them, why on earth would it be called 'assigned'? So
new tickets start out assigned, but sometimes not to anybody? That's

How about a word that captures them all, like 'open'?

> Better handling of duplicate bugs: The "dup" feature should have a bug
> field that causes both bugs to be updated automatically with links to
> each other.

Great idea. I sometimes do that manually for the other bug, but not

> Better anonymous reporting (3 mentions): (First reporter) I'd like
> better anonymous reporting and commenting.  (Second reporter) I've
> bolded the 'New Ticket' and cypherpunks info on the landing page, though
> creating a ticket via cypherpunks really should be a fist sized cherry
> red button on that page...  (Third reporter) I think the 'cypherpunk'
> user should have to add an email address in the Cc field. If they put
> mailinator in there, so be it. But they at least need to know we need to
> talk to them, or their bugs will probably just sit around forever.

Good idea. It is true that tickets created by cypherpunks very often do
not get any good followup. I would be tempted to say that cypherpunks
shouldn't be allowed to open tickets.

I wonder if the real problem here is that it's such a hassle to make a
trac account. (Is it?)

> Voting on issues.

This isn't a democracy here. :)

> Separate system for users and developers: Trac is used for user support
> too much. I wish we had a system that was JUST developer centric, no
> user wiki pages or other crap that turns up in searches.


> Landing page: Our landing page is a nightmare for newcomers.
> [Suggestion: Write a new landing page.]

That sounds really valuable. In particular, the first flaw with our
current landing page is that it is not clear that you are looking at a
combination bugtracker and wiki.


More information about the tor-dev mailing list