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