Re: [boost] "To Be Determined" milestone

From: David Abrahams (dave_at_[hidden])
Date: 2007-12-06 15:12:45

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