on Thu Dec 06 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
on Wed Dec 05 2007, Rene Rivera <grafikrobot-AT-gmail.com> wrote:
David Abrahams wrote:
I am planning to remove the "To Be Determined" milestone since we now have a 1.36.0 milestone to which things can be assigned. Please let me know if there are strong objections. OK, I object. I'm fine with moving the appropriate tickets to 1.36.0. But not all tickets correspond to a Boost release, past, present, or future.
Like what?
Like bjam, build, website, quickbook and the rest of the tools.
Don't they have their own milestones and releases?
If such tasks do exist, then we should create a milestone for what they _do_ correspond to. "To be determined" adds nothing, and if there isn't a thing with a deadline attached to it, there's no incentive to deal with them.
That seems like a prejudiced assumption to me. There's as much incentive to clear tickets regardless of a milestone IMO. If there isn't then we might as well abandon using trac altogether.
I can't believe you mean what it sounds like you're saying: if the incentive to deal with a ticket were increased by having a milestone assignment, the whole Trac system would be useless? Is that really your claim?
You just can't force people into dealing with issues by imposing management onto them. Even if this weren't a volunteer effort, people would find ways of avoiding the work.
That seems like a misinterpretation of my words as some kind of power play. I never had the slightest thought of forcing anything on anyone. I don't want any of *my* tickets in "to be determined" because I don't think it's useful, and I think tickets are more likely to languish there without ever being closed one way or the other. I think a milestone helps to separate the urgent tasks from what can be dealt with later. I think having wishy-washy categories in the system like "to be determined" results in a less powerful and less useful tracking system. If "to be determined" is going to have a practical use for a significant number of people, we should keep it. To me it just seemed as though it does not.
If dealing with the ticket means deferring to an even later deadline, that's fine.
What about when I explicitly know that I haven't decided which deadline I will be dealing with a ticket? How will users reporting issues know not to choose the "Boost x.y.x" milestone?
You get notices of tickets assigned to you; it's up to you to change them to the appropriate milestone at that point. This is how dozens of projects use milestones, including the Trac project. Sometimes, when getting near a release, a request will go out that users not choose that milestone. If they do, the ticket owner corrects it.
This is basic task management, in my opinion: there should be no "things to do" without a target by which they should be done or at least reviewed and deferred,
People do this all the time. We all have things we want to do in our lives at some point. It seems perfectly obviously to me to do the humane thing and reflect that aspect in trac. And I prefer the process whereupon when I know I'm going to have a release I look at the to-do list and pick the 20 issues that will be in that release. As opposed to having to delay 300 issues on each release to the next release. The former seems like much less management pain to me overall. And hence more likely to be used, and hence useful.
Your way certainly is a system that makes it more tolerable to carry around 300 open issues for an indefinite amount of time. But having 300 open issues at any time, at least for me, leads to a sense of intractability that tends to decrease productivity, and from the (admittedly small amount of) study I've done on the subject of task management, the experts agree with me. In my opinion, the system should be set up to encourage resolution and discourage lingering unresolved issues. That sort of encouragement would be useful to me personally. If it seems inhumane to you, I'm sorry, and I guess I may have to give up on the idea. To me it seems just about as inhumane as using a static type system: the constraints provided by the technology are there to help us.
and when it becomes clear that a "thing to do" won't actually ever be done, its ticket should be closed to avoid cluttering the mind-space of people working on real milestones.
The only time I know things won't ever be done is when I die, and I'm trying to avoid that ;-)
But if removing the to-be-determined milestone is so important to you... Go ahead.
Not making people feel as though they're being treated inhumanely or forced to do anything is a lot more important. So, no, I'm not going to go ahead.
I'll just create "bjam future", "build future", "website future", and "quickbook future" milestones.
Consider this: the Python project for years used a the name "Python 3000" to denote a milestone that was way off in the future, where major language features could be reconsidered more fundamentally. "Good idea, but that's definitely a Python 3K feature." Well, eventually Python 2.x ran its course and in April of '06, Guido started http://www.python.org/dev/peps/pep-3000/. Now Python 3000 has a development plan, and any tickets that were assigned to that milestone will be newly considered to make sure they fit in with the goals of that release. So I'm not proposing anything radically different from "build future." It's just slightly more concrete. I am not a big fan of American football, but somehow I know this quote, which seems particularly apropos: "Always have a game plan, but be prepared to turn on a dime" -- Don Shula Regards, -- Dave Abrahams Boost Consulting http://www.boost-consulting.com