Difference between tickets and bugs
I've received a couple of comments from people about the "daily bugs list" from people who want me to separate out the "bugs" from all the other kinds of tickets in the trac system. [ For the record, the other types of tickets are "Feature Requests", "Tasks", "Support Requests" and "Patches" ]. With that in mind, I will be sending out a smaller list every day, of just the "bugs". Less frequently, I will be sending either a full list of all open tickets, or separate messages for each kind of ticket. If you think this is a great/good/poor/awful idea, please let me know. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
On Sep 5, 2007, at 10:05 AM, Marshall Clow wrote:
With that in mind, I will be sending out a smaller list every day, of just the "bugs". Less frequently, I will be sending either a full list of all open tickets, or separate messages for each kind of ticket.
If you think this is a great/good/poor/awful idea, please let me know.
I think this is a good idea. Bugs should take a much higher priority than the others, so we need to be prodded more frequently to fix bugs :) I'm not convinced we should even keep "Support Requests" as an option... we're better off if these requests come in through one of the mailing lists. - Doug
Marshall Clow wrote:
With that in mind, I will be sending out a smaller list every day, of just the "bugs". Less frequently, I will be sending either a full list of all open tickets, or separate messages for each kind of ticket.
Great, thanks Marshal! -- Eric Niebler Boost Consulting www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
on Wed Sep 05 2007, Marshall Clow <marshall-AT-idio.com> wrote:
I've received a couple of comments from people about the "daily bugs list" from people who want me to separate out the "bugs" from all the other kinds of tickets in the trac system. [ For the record, the other types of tickets are "Feature Requests", "Tasks", "Support Requests" and "Patches" ].
With that in mind, I will be sending out a smaller list every day, of just the "bugs". Less frequently, I will be sending either a full list of all open tickets, or separate messages for each kind of ticket.
If you think this is a great/good/poor/awful idea, please let me know.
It's a fine idea, but IMO it would be best if you could integrate the results into one message somehow. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
In article <p06210218c30467347348@[192.168.16.228]>, Marshall Clow <marshall@idio.com> wrote:
With that in mind, I will be sending out a smaller list every day, of just the "bugs". Less frequently, I will be sending either a full list of all open tickets, or separate messages for each kind of ticket.
If you think this is a great/good/poor/awful idea, please let me know.
I think that the important question here is "What are people trying to find when they are looking at the ticket list" and the likely answer is "Things to work on" for people who are not managing a release and "An idea of a release's progress" for people who are managing a release. I therefore think that when someone asks you to take something out of that list (in this case, non-bugs), then they are doing that because they think that including that something decreases the signal/noise ratio. I also think it would be appropriate to disregard the suggestion to exclude non-bugs if you can find another way to improve usability of those emails. A few things I would consider: - The list of ticket count by owner is not useful enough to be at the top - Tickets for each owner should be arranged by priority, not by ticket number - It should be easier to scan for where one owner ends and the next begins - Release managers would be happier with a list that's organized by priority, then by owner. So, combining those, I would do this: *** *** *** High priority tickets *** *** *** == None == Some high priority ticket Another high priority ticket == agurtovoy == Some high priority ticket Another high priority ticket == etc etc == *** *** *** Medium priority tickets *** *** *** == None == Some medium priority ticket Another medium priority ticket == agurtovoy == Some medium priority ticket Another medium priority ticket == etc etc == If you are willing to ignore the needs of release managers and make things easier for developers, make the priority grouping secondary. Of course, this all assumes that tickets are assigned useful priorities. If not, then I guess what people are telling you that non-bugs are inherently lower priority. However, as long as you are sending out a big long email, you are hamstrung by including information about everyone's tickets, thus guaranteeing that everyone who reads it is ignoring most of it. An individualized message to each user would be more useful, and a summary to the whole list might still be a good idea. Finally, the email could gain a lot of in terms of readability if you used some basic styling, but I realize that this is Usenet/mailing list, so there's an inherent ASCII fetish. Ben -- I changed my name: <http://periodic-kingdom.org/People/NameChange.php>
participants (5)
-
Ben Artin -
David Abrahams -
Doug Gregor -
Eric Niebler -
Marshall Clow