Re: [boost] "To Be Determined" milestone

From: Rene Rivera (grafikrobot_at_[hidden])
Date: 2007-12-06 09:38:51

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.

> 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. 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.

> 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?

> 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.

> 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. I'll just create "bjam future", "build future", "website 
future", and "quickbook future" milestones.

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo