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.)
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?
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 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'?
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.
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!
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.
--Roger