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

[Robert Ransom]

On 2011-08-22, Karsten Loesing <karsten.loesing at gmx.net> wrote:

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

I just used https://trac.torproject.org/projects/tor/report/40 (Tor
tickets by milestone) today as a starting point to find a submitted
patch that I had forgotten to put in needs_review when I saw it in
#tor-bots (#3923).  I also used
https://trac.torproject.org/projects/tor/report/23 (Tor tickets
needing review), and I think I've used it more than once before today.

> 1.2 What are typical custom queries that you run?

I frequently search for tickets in a component with the default set of
statuses, and sometimes search for all closed tickets in a component.
I have also used the default custom query (Owner = me) fairly
frequently.

I occasionally search for tickets containing a keyword in the summary
or description fields, mainly when I'm looking for a particular closed
ticket whose number I have forgotten in a component containing many
tickets.

> 1.3 How do you use milestones and roadmaps?

I use the 'Milestone' ticket field to indicate which version of Tor a
bugfix or feature needs to be applied to.  I would do that with
Vidalia, too, but there is no Vidalia 0.2.x milestone.

What are roadmaps?

> 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.  Back when I was using a tolerable MUA, I
used unread tor-bugs messages to indicate tickets that I needed to
work on or monitor.  Now tor-bugs just fills my unusable inbox.

I am not subscribed to tor-wiki-changes, and I would not subscribe to
it even if I could read the messages.

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

None.

> 1.6 How do you search for wiki pages?

I type "https://trac.torproject.org/projects/tor/wiki/TitleIndex" into
Firefox's URL bar and vgrep the list.  If I'm looking for a wiki page,
I usually know the last component of its title, but I no longer know
its exact URL.

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

If a search term were typical, I would bookmark the wiki page or
remember the ticket number.

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

I use the 'easy' keyword for tickets that I suspect would be trivial
for someone who knows how to use grep and a TAGS file to
fix/implement.

What is 'the tags page'?

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

Very useful for finding tickets that I have filed.

> 1.9.2 Owned by

Useful.

> 1.9.3 Priority

I use this field to indicate the severity of a bug or lack of feature.

> 1.9.4 Milestone

See above.  Very important for tickets on Tor itself; would be
important for Vidalia tickets if I could use it; not useful for
anything else.

> 1.9.5 Component

Very important.

> 1.9.6 Version

Useless.  Current versions of products are never in the list.

> 1.9.7 Keywords

Useless.  No one looks for 'easy' tickets.  Other keywords are chosen
too haphazardly to be useful (usually by users who have never used our
bug tracker before).

> 1.9.8 Cc

Only useful for CC-ing people that notice when they are on a ticket's
CC list (i.e. Erinn), and only useful since yesterday (when Erinn gave
me the Trac permission needed to set the CC field arbitrarily).
Previously, I could only set the CC field when creating a new ticket
or add/remove myself in the CC list; the latter was useless.

> 1.9.9 Parent ID

Rarely useful.

> 1.9.10 Points

DIE DIE DIE

> 1.9.11 Actual Points

DIE DIE DIE

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

Equivalent to 'assigned', 'new', and 'reopened'.

> 1.10.2 assigned

Indicates that a ticket's owner has been changed from the default
owner for its component.

> 1.10.3 closed

Indicates that a ticket has been handled or discarded.

> 1.10.4 needs_information

Sometimes indicates that more information is needed before we
can/should continue to handle a ticket.  Sometimes does not (e.g.
#1705).

> 1.10.5 needs_review

Very relevant.  Indicates that a patch exists to fix a bug/add a feature.

> 1.10.6 new

Indicates that a ticket has not had its 'owner' field set explicitly
since it was created.

> 1.10.7 reopened

Often indicates that a user is being an idiot or jerk.  Otherwise,
equivalent to 'accepted', 'assigned', 'new', and 'reopened'.

> 1.11 What other features do you use in Trac?

The 'Timeline' is occasionally useful for finding tickets opened or
modified during some period of time.

> 1.12 What features are you missing in Trac?

A 'ban' feature to get rid of idiots/jerks.

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

The Trac wiki should die.

Most of the contents of the wiki consist of obsolete and/or bad
advice.  These pages should be archived in a tarball where they will
not be readily accessible to web browsers and search engines, then
purged from our Trac installation.

The rest of the pages in the Trac wiki should be moved to a wiki which
allows a user who edit a page concurrently with another user to merge
his/her/its changes into the wiki page.  Perhaps we should just use
Git and give up on browser-based wikis.


Robert Ransom