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

[Damian Johnson]

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

"{28} Open Arm Tickets", of course :P

> 1.2 What are typical custom queries that you run?

I don't since I found the search interface to be a pita. I track
tickets via email instead, flagging those I'm interested in and using
gmail's searching functionality.

> 1.3 How do you use milestones and roadmaps?

I keep a wiki with my todo plans for arm
(https://trac.torproject.org/projects/tor/wiki/doc/arm).

> 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 but not tor-wiki-changes (I use my own
rss2email instance since I want prompt notices but tor-wiki-changes
seems to be on an hourly batch).

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

I maintain...
https://trac.torproject.org/projects/tor/wiki/doc/arm
https://trac.torproject.org/projects/tor/wiki/doc/badRelays

> 1.6 How do you search for wiki pages?

Most of the time I use my browser's address autocomplete. Otherwise
I've rarely had a need to search or navigate the wiki.

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

N/A

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

Nope

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

Useful

> 1.9.3 Priority

Meh, it's a rough indicator of somebody's opinion on the importance
but that's it.

> 1.9.4 Milestone

Not used for my project

> 1.9.5 Component

Most important field there is :)

> 1.9.6 Version

Not used for my project

> 1.9.7 Keywords
> 1.9.8 Cc

Not useful (I ignore this)

> 1.9.9 Parent ID

I don't use this

> 1.9.10 Points
> 1.9.11 Actual Points

I don't use this, iirc this is just some metadata field for Mike

> 1.10 How relevant are the following ticket statuses for you?
> 1.10.1 accepted
> 1.10.2 assigned
> 1.10.3 closed
> 1.10.4 needs_information
> 1.10.5 needs_review
> 1.10.6 new
> 1.10.7 reopened

Several of the statuses (accepted/assigned/new/reopened) have
identical meanings since trac assigns them automatically, so they're
not an indicator of a human's intent. The only ones that matter are
'needs_information', 'needs_review', and 'closed'.

I'd like to see this narrowed to just a small set of useful statuses
with a combo box for the reason...
- assigned
- pending
  - requester information
  - code review
  - code push
  - schedule
  - ... etc
- resolved
  - no issue
  - requester disappeared
  - duplicate
  - fixed / implemented
  - ... etc

> 1.11 What other features do you use in Trac?

I use trac as a basic bug tracker and wiki - that's it.

> 1.12 What features are you missing in Trac?

None, I'm happy with it for my use cases. Once upon a time it would
have been nice to have MediaWiki syntax, but the trac derivative is
fine.

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

For my use cases I'm happy with it. Assuming that you already know
what you're looking for trac is fine. That said, our landing page,
searching functionality, etc makes it a nightmare for newcomers. From
my point of view it's suitable for our current pool of developers and
if adding something makes a person's life easier (for example, the
"Points" field) then great, go for it.

For everyone else trac serves just two purposes:
1. The wiki, which houses content (ie, we link to it from non-trac
pages like the site and blog) but I don't think we expect people to
navigate trac itself... at least I hope not!

2. Ticket reporting, which we should certainly improve. 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...

> 2 Solving typical software development tasks
> 2.1 How do you decide what to work on, both when fixing bugs or when implementing new features?

My priorities are as follows:
1. time critical issues facing arm users (hotfixes for recent releases and such)

2. features, fixes, or answering questions to make someone's life
nicer (where the more involved the requester is, the higher priority
it is for me)

3. whatever I feel like at the moment, usually something that works
toward the next arm release

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

N/A

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

Not sure if I understand the question. If you mean 'how do I keep
track of todo notes' I usually email myself the relevant snippets of
irc discussions so I remember to go back and address the issues they
mentioned later.

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

There's precious few projects I work with others on, unfortunately.
I'd love to change that but there's little interest in controllers or
UI development (and what little there is focuses on Vidalia). Oh
well...

Mostly this question would just concern my work with TorCtl where I
write a patch, add a link for the branch on a ticket, then pester Mike
every so often until he reviews and merges it.

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

Not sure I follow. If I have questions about another project I talk
with the project owner, as listed on:
https://www.torproject.org/getinvolved/volunteer.html.en#Projects

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

I dislike the idea of overloading trac. For me it's just a bug tracker
and wiki. If others want to use it for things like project management
then great, but I'd be weary of trying to jerry rig solutions it's not
intended for.