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

[Roger Dingledine]

On Mon, Aug 22, 2011 at 02:29:09PM +0200, Karsten Loesing wrote:
> 1 Using Trac features
> 
> 1.1 Which of the reports (stored ticket queries) do you use most often?

Basically none of them. Every once in a while I use
"{12} Tor: Active Tickets by Milestone"

> 1.2 What are typical custom queries that you run?

In almost every case it is "custom query", press the "-" to get rid of
the "owner is arma" constraint, scroll down on add filter to 'component',
click somewhere so the new box appears, then pick the component I wanted
to get a list of trac tickets on.

If it's a big component, I put a bigger number into "max items per page"
so I can see all the tickets I asked for (and be able to search their
titles using ^F).

> 1.3 How do you use milestones and roadmaps?

I use the Tor 0.2.x.y-final milestones to categorize Tor tickets by which
version they should go in. I don't pick (or look at) milestones on non
tor components, since I assume people have their own policies that vary
by component.

By 'roadmap', do you mean https://trac.torproject.org/projects/tor/roadmap
? If so, I don't use it. In fact, I went so far as to make my own
roadmap-like thing for Tor 0.2.2:
https://trac.torproject.org/projects/tor/ticket/3032

> 1.4 Are you subscribed to tor-bugs and/or tor-wiki-changes, and how do
> you use the mails sent to these lists?

I'm subscribed to tor-bugs. I put them in a separate mailbox. If I'm not
travelling, I read them all and use them to know which tickets other
people are active on, so I can be most useful at helping them make
progress. If I am travelling, I let them pile up and generally don't
look back.

I run a nightly r2e on the trac wiki rss. I generally delete the mails
it sends me, unread -- mostly because the wiki notification mails don't
have any useful content about what changed, and getting a useful diff
is too klunky to be worth it. ("Besides, they're just wiki pages.")

> 1.5 Which wiki pages do you read/edit most often?

I use the wiki faq page to point people to faq entries that haven't been
transitioned yet. (Basically nobody knows about the wiki faq now that
we moved the faq over, but we left most of the answers on the wiki. Oops.)

I use the sponsor pages, mostly sponsorf, to remind myself of the various
things we've promised, and to help keep them updated on our progress. I'm
happy to hand the 'keeping them updated' part to somebody else though.

> 1.6 How do you search for wiki pages?

In my browser history. All the important ones (there aren't many)
are there.

> 1.7 What are typical search terms that you use when using the search
> features?

A few times I've tried searching for trac tickets using phrases I
remembered from them. It always gave me way too many pages, and they
were not easy to thumb through, so I stopped.

> 1.8 Do you use keywords and the tags page, and if so, what are keywords
> that you typically use?

Woah, there's a tag page?

I use the keyword 'easy' sometimes, but ignore keywords generally.

> 1.9 How relevant are the following ticket fields for you?
> 
> 1.9.1 Reported by

Important, since it tells me how likely the trac ticket is to make sense.

> 1.9.2 Owned by

Important, since it tells me either who has promised to work on the
ticket, or who somebody else hoped would work on the ticket.

> 1.9.3 Priority

Important. I can signal to other people whether I feel strongly that
the task should be done (major) or think it's not a big deal or at least
not a big deal soon (minor).

> 1.9.4 Milestone

Important for the Tor-component tickets. I don't pay attention to it
for other components.

> 1.9.5 Component

Important since it tells me who is (hopefully) paying attention to the
ticket.

> 1.9.6 Version

I try to fill this one in when I can, but the consistency here is so
spotty that we would not lose much if it disappeared (especially since
it's most useful for bug reports, which mostly come from users who don't
successfully report the right version).

> 1.9.7 Keywords

I ignore it.

> 1.9.8 Cc

We've been using this one increasingly. People who've added themselves
to the cc list indicate that they care about this ticket in particular.
Sometimes I add people to the cc list to indicate that I think they
should care -- but I try to do that only for people that I've witnessed
signing themselves up to some cc list.

> 1.9.9 Parent ID

Rarely used, but relevant when it is used.

> 1.9.10 Points
> 1.9.11 Actual Points

Mike uses these to trac his agile hours. It's a little bit interesting
to see him learn lessons from attempting estimates, but I wouldn't miss
them if they disappeared.

> 1.10 How relevant are the following ticket statuses for you?
> 
> 1.10.1 accepted

I treat this as equivalent to 'new' for most people, and equivalent to
'assigned' for a few people. Not all that useful.

> 1.10.2 assigned

If somebody assigned a ticket to themselves, it's meaningful. If somebody
else assigned it, like happens automatically when you switch a ticket
from one component to another, it's not all that useful.

> 1.10.3 closed

Very important. If we couldn't close tickets, where would we be? :)

> 1.10.4 needs_information

New but promising.

> 1.10.5 needs_review

Very useful. It means there's a patch I should read.

> 1.10.6 new
> 1.10.7 reopened

I wouldn't mind if these merged, but there is a little bit of information
to be gained by knowing that somebody thought it was fixed and somebody
thought it wasn't.

> 1.11 What other features do you use in Trac?

Nothing else comes to mind. I spend most of my trac time going to a
specific trac ticket using a number I found in my tor-bugs mailbox,
looking over the whole discussion, and adding a comment.

> 1.12 What features are you missing in Trac?

Listing tickets for a given component could sure be easier.

One of the main problems we have in general is the proliferation of
tickets. Originally that was a good thing -- "have something we need to
do? Make a ticket, then we'll remember." But now we have so many darn
tickets, especially in some components, that they're tough to manage,
which leads to less active maintenance, which leads to having it get even
more out of control. I'm not sure what to do about it, but sometimes it
makes me less excited to add more tickets since I feel like I'm adding
to the problem. So some feature to do large-scale ticket management
would be good.

> 2 Solving typical software development tasks
> 
> Note that the questions below don't just focus on Trac, but on any tools
> or communication media you use for solving a task.
> 
> 2.1 How do you decide what to work on, both when fixing bugs or when
> implementing new features?

I generally pull from a) whatever is on my todo list, b) whatever people
are working on on irc, and c) whatever is arriving to my tor-bugs mailbox.

Often the urgent items on my todo list are not development tasks, so I
use development work as a break from the 'real' work.

> 2.2 How do you keep track of what things you're supposed to do for
> sponsors and for when?

They're on the sponsors wiki pages. As they get closer I move them to my
internal todo file. Recently I've started keeping my todo list in three
priority categories ("rsn, soon, and eventually") so hopefully others
can have a better chance of following along or predicting me.

> 2.3 How do you memorize new ideas to work on when they come up?

Ideally I make a trac ticket about them right then. Otherwise (offline
or no time), I put a line in a todo list somewhere, which sometimes
works out and sometimes gets lost.

> 2.4 How do you coordinate working together with someone on something?

For a lot of the topics I work on (e.g. being at the center of the
research web, or keeping people informed about other parts of the Tor
world they need to know about), I coordinate via eventually sending
emails. There isn't really that much near-term interaction.

Aside from the (increasingly small amount of) development work I do,
a lot of my interactions are helping everybody to move forward on their
own tasks, helping people know the big picture of where we should go,
keeping track of what everybody is up to, and helping to grow the
community. A lot of this happens in person, and some happens over irc.

I would be a more useful developer if I ignored the big picture more,
and then picked out more deep Tor bugs/features to work on. But I can'd
do that and also be keeping the big picture in my head to interact
with other communities, funders, etc. In any case, that's a topic for
a different thread. :)

> 2.5 How do you learn who you could work together with on something?

By watching trac, irc, the mailing lists, and interacting with people
in person, I try to know generally what everybody is up to. Then *I*
can be one of the people that people can come to when they want to know
who else would be a good match for some project.

--Roger