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

[Mike Perry]

Thus spake Karsten Loesing (karsten.loesing at gmx.net):

> 1 Using Trac features
> 
> 1.1 Which of the reports (stored ticket queries) do you use most often?

https://trac.torproject.org/projects/tor/report/14
https://trac.torproject.org/projects/tor/report/38
https://trac.torproject.org/projects/tor/report/39

> 1.2 What are typical custom queries that you run?

All kinds, but mostly to add extra filters, columns, grouping, and
sorting to existing reports and milestones.

> 1.3 How do you use milestones and roadmaps?

I use milestones to track TBB development and my deliverables for
sponsors.

> 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 am subscribed to tor-bugs. It goes into a folder and is unread.

Trac mail sent directly to me as the Owner, Cc, and/or Reporter goes
directly to my inbox, though.
 
> 1.5 Which wiki pages do you read/edit most often?

The abuse templates, chrome bugs, sponsor pages, HTTPS-Everywhere
design.
 
> 1.6 How do you search for wiki pages?

Urlbar history search.

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

I don't use the trac query to find tickets. Also don't use search
engines, as I've not found one capable of deep-indexing trac. If I'm
not at least Cc'd on a ticket, it does not exist to me.
 
> 1.8 Do you use keywords and the tags page, and if so, what are keywords
> that you typically use?

Agile iteration tracking keywords.
 
> 1.9 How relevant are the following ticket fields for you?
> 
> 1.9.1 Reported by

Only insofar as it makes trac email the account that is in this field.
 
> 1.9.2 Owned by

Email+knowing which bugs are mine, and who to pester about other bugs.

> 1.9.3 Priority

Useful for iteration and release planning.

> 1.9.4 Milestone

Useful for release planning and sponsor deliverables.
 
> 1.9.5 Component

Useful for reports, release planning, and filing.

> 1.9.6 Version

Don't use it.

> 1.9.7 Keywords

Useful for agile iteration tracking.

> 1.9.8 Cc

Useful for alerting other people to bugs (unless they send all trac
mail to /dev/null).

> 1.9.9 Parent ID

Useful for tickets with many subtasks, either because the task is too
large for one ticket, or because the task spans multiple components.
 
> 1.9.10 Points

Useful for recording an estimate of how long a ticket will take.

Points are also useful for estimating how much work remains to be done
on a given release. The Point completion rate minus the Point open
rate for a release can be used to project when that release will be
ready.

> 1.9.11 Actual Points

Useful for recording the actual amount of time+effort spent on a
ticket.

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

Useless.

> 1.10.2 assigned

Useless.

> 1.10.3 closed

Very useful.

> 1.10.4 needs_information

Useful.

> 1.10.5 needs_review

Somewhat useful.

> 1.10.6 new

Useless.
 
> 1.10.7 reopened

Useless.

> 1.11 What other features do you use in Trac?

Embedded queries. See for example:
https://trac.torproject.org/projects/tor/ticket/3410

> 1.12 What features are you missing in Trac?

1. Git commit hooks.

We should be able to mention "Bug #XXX" at the start
of a commit message and have that commit get posted as a comment to
trac w/ a link to the gitweb url for the commit. I believe we have a
trac plugin for this, but it is not yet properly configured.

At other employers, commits could only go into stable releases if they
referenced a bug # in the first line. I thought this was a good
policy. Back in the SVN days, this property was actually enforcable on
the server. Git may make this bit more difficult..

2. Trac 0.12-stable.

I would like some of the embedded query syntax that is available in
0.12.x-stable of trac. In particular, 0.12 would make it much easier
to compute the rate of Opened tickets against a given project in a
certain period of time.

3. Better handling of duplicate bugs.

The "dup" feature should have a bug field that causes both bugs to be
updated automatically with links to eachother.

4. Field updates should perhaps not send email

Some field updates don't require emailing everybody on the ticket. I
*think* 0.12 might provide the ability to solve this one, too, but I
am not sure.
 
> 1.13 What features would you want our Trac not to offer anymore, because
> they're making things only more confusing for you (and for people who
> are new to Tor)?

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.

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

Every two weeks I sort the tickets opened against me by priority and
by component. I then take approximately 20 Points worth of tickets and
assign them to that iteration to work on.

As emergency issues arise during this two week period, I give them a
"Fire" keyword for that iteration. I tend to get anywhere from 5 to 20
extra Points of fires in a given two week iteration, with 10 being the
most common.

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

I mostly use the Sponsor deliverable pages, but I plan to also use the
milestone field.

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

If it is development, it goes into trac immediately. Otherwise, it
goes into my personal TODO list, which I try to run similarly to the
trac iterations.

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

I first try to use the Cc field in trac. It doesn't always work. I
fall back to IRC, and then email a couple days later. Sometimes I
forget to email and the task falls on the floor and gets forgotten.
 
> 2.5 How do you learn who you could work together with on something?

The trac component owner.
 
> 2.6 What other software development tasks do you have that may be
> supported by Trac or a Trac-like system?

I could envision Trac having better support for agile, but really that
would just amount to it creating graphs of iteration progress rates
and auto-computing ticket completion rates and ticket open rates.
Since all of the agile plugins for trac seem rather invasive, I can do
this myself for now.

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20110823/f42c5723/attachment.pgp>