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

[Karsten Loesing]

On 9/12/11 3:51 PM, Roger Dingledine wrote:
> On Tue, Sep 06, 2011 at 10:44:11AM +0200, Karsten Loesing wrote:
>> The Component field (10, 1, 1) is used to find/filter tickets and guess
>> who's paying attention to a ticket.  1 person said that the many Tor
>> components make it hard to refer to the software "tor" and that it's
>> easier to look at milestones itself.
> 
> I guess that would be Nick. I wouldn't object to making some other Trac
> field besides 'component' to categorize things. But lumping 500+ Tor
> tickets into one component, with no way to break them down by category,
> is going to make it much harder to find tickets.
> 
> (I search for tickets by pulling up all the tickets in a given component,
> and then using my browser's search feature to thumb through them.)

Well, I don't know what to do here.  I think changing the component of
500+ tickets and adding, say, keywords for the category is a lot of work
and will generate a lot of mail for people on tor-bugs.  Is it worth it?

>> The Version field (3, 3, 5) is not used by many components and is
>> considered not very useful, because bug reporters get versions wrong in
>> most cases anyway.  Also, current versions of products are never in the
>> list.
>>
>> [Suggestion: Delete all obsolete versions from the list, and try harder
>> to add new versions.]
> 
> When you delete a version from the list, does it vanish from tickets
> that reference it? That is, will we be destroying history by deleting
> an old version?

I just tried this in #4005.  The version in the ticket will remain the
same, but one cannot create new tickets using this version or change the
version field of existing tickets to it.  So, breaking history shouldn't
be a problem.

>> The Points (1, 0, 10) and Actual Points (1, 0, 10) fields are actively
>> used by only 1 person and read by 1 other person.
>>
>> [Suggestion: Investigate whether it's possible to suppress email
>> notifications for changes to the Points and Actual Points fields.]
> 
> I actually find these mails about as useful as the other mails, insofar
> as they tell me that Mike is thinking about working on a given ticket.
> 
> But I can see how people who don't care what Mike is going to work on
> soon would not want to see them.

The question is: how much will you care if these notifications go away?
 I think the majority of people wouldn't mind if the Points and Actual
Points fields would go away entirely, so suppressing notifications was
already a compromise.

>> The new (2, 1, 4), assigned (1, 3, 5), reopened (1, 2, 5), and accepted
>> status (1, 1, 6) have slightly different meanings for some people, but
>> are mostly equivalent for the majority.  There are 5 persons who'd like
>> to see these four statuses merged into one, e.g., assigned.  1 person
>> suggests to narrow down statuses to three statuses: assigned, pending
>> (with a combo box for reasons: requester information, code review, code
>> push, schedule), and resolved.
>>
>> [Suggestion: Investigate whether we can merge "new," "assigned,"
>> "reopened," and "accepted" into a single "assigned" status.]
> 
> If we merge them, why on earth would it be called 'assigned'? So
> new tickets start out assigned, but sometimes not to anybody? That's
> confusing.
> 
> How about a word that captures them all, like 'open'?

'open' it is then.  (Assuming we can even change this.)

>> Better handling of duplicate bugs: The "dup" feature should have a bug
>> field that causes both bugs to be updated automatically with links to
>> each other.
> 
> Great idea. I sometimes do that manually for the other bug, but not
> consistently.

I'll see if there's a plugin for that.  Or maybe 0.12 does that already.

>> Better anonymous reporting (3 mentions): (First reporter) I'd like
>> better anonymous reporting and commenting.  (Second reporter) 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...  (Third reporter) 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.
> 
> Good idea. It is true that tickets created by cypherpunks very often do
> not get any good followup. I would be tempted to say that cypherpunks
> shouldn't be allowed to open tickets.
> 
> I wonder if the real problem here is that it's such a hassle to make a
> trac account. (Is it?)
> 
>> Voting on issues.
> 
> This isn't a democracy here. :)
> 
>> Separate system for users and developers: Trac is used for user support
>> too much. I wish we had a system that was JUST developer centric, no
>> user wiki pages or other crap that turns up in searches.
> 
> Yes!

I'm not opposed.  Should we set up a poll somewhere? :)

>> Landing page: Our landing page is a nightmare for newcomers.
>>
>> [Suggestion: Write a new landing page.]
> 
> That sounds really valuable. In particular, the first flaw with our
> current landing page is that it is not clear that you are looking at a
> combination bugtracker and wiki.

Yup.  We should decide first whether we want to solve that by moving
away the wiki.  Though I know at least one person who won't be thrilled
that there will be new URLs for wiki pages---again.

Best,
Karsten