Thus spake Karsten Loesing (karsten.loesing@xxxxxxx): > 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
Attachment:
pgpBRqAsH4Rgn.pgp
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev