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

[Erinn Clark]

I'm replying to Roger's email because he condensed Karsten's email, but I can
probably answer lots of Trac questions in general. Will try to do so in this
thread.

* Roger Dingledine <arma at mit.edu> [2011:09:12 09:51 -0400]: 
> On Tue, Sep 06, 2011 at 10:44:11AM +0200, Karsten Loesing wrote:
> > 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?

I just tested this:
https://trac.torproject.org/projects/tor/ticket/2926#comment:1

I created a Version (called Test), assigned a bug to it, then deleted the
Version. It appears to still be in the bug, so I think it is probably safe to
delete old versions. We could try a few more times with versions we don't
really care about anymore just to be sure. How useful are the versions when
deciding a bug applied to a very old version of Tor and is still present in a
current one? That mostly gets mentioned in the changelog and not on Trac,
right?

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

I can't see an obvious way to suppress these, looking through our trac.ini. 

In general, I think we should let the firehose spew and try to give people
methods for dealing with what comes out. Randomly 'hiding' parts of automatic
communication seems sketchy, and doing it because people can't figure out how
to configure their mail doesn't seem like a good reason. If we could figure out
a way to differentiate between 'mostly useful to everyone' and 'only useful to
information sponges' -- i.e., the latter gets Mike's emails, all ticket changes
and notifications, and the former just gets whatever we decide is important --
then I could see an argument for making a separate tor-bugs-full that gets
everything and letting tor-bugs keep the high-level stuff (opened tickets,
replies, reassignment, closed tickets).
 
> How about a word that captures them all, like 'open'?

I think we can do this in Trac. (And I 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
> consistently.

There were a few plugins for this that we tried last year and they totally
sucked. This is a very old problem with Trac, in fact:
http://trac.edgewall.org/ticket/31

We could try again!

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

It isn't a hassle. It is literally one screen which asks for all your
information, at which point you hit 'Submit' and you have a trac account. The
whole process takes about 20 seconds.

I don't like the cypherpunks account either, for all reasons mentioned above.
But people creating new accounts in general are not required to provide an
email address either, so even if we removed cypherpunks's ability to create
tickets, we could potentially have the exact same problem anyway, unless we
decide to enforce email as part of account creation.

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

Can I take this opportunity to plug ikiwiki again, if we do make a separate
wiki? It uses git, and we can use text editors to write documentation, rather
than writing in web boxes. For people who travel a lot it would be very useful
as an offline tool. (Inability to do bug-stuff offline is one thing that annoys
Roger, but I can't remember if he already mentioned that.)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 495 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110913/a5749bde/attachment.pgp>