Re: [boost] "To Be Determined" milestone

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

David Abrahams wrote:
> 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?

Hm... Bjam has releases, but not usually milestones. And I don't know 
ahead of time which releases bjam will have. For example I didn't plan 
to have a 3.1.16 release and was planning for the 3.1.15 to be the end 
of the line for the 3.x.y sequence. But reality stepped in. Boost.Build 
follows it's own release and milestone sequence, which is not recorded 
in the Boost trac since it has it's own trac. The website will likely 
only ever have the 1.0 milestone, and continuous "releases". Quickbook 
has releases, but has never had milestones, and likely never will. 
Releases for it, just happen. The other tools have never had releases as 
such, and hence wouldn't have milestones.

So overall, no they don't have milestones and releases in the sense you 
seem to be using.

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

No, that's not what I said. I said that if there isn't already incentive 
to fix tickets *without* a "next version milestone", having a "next 
version milestone" will not create such incentive. But being an 
optimist, I believe that there is already incentive to close tickets. 
And hence question any rationale that is based on creating incentive to 
close tickets.

>> 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 was only pointing out something I've learned from managing projects: 
You can't force management on people. And I'm feeling like I am being 
forced to accept the "next release milestone" concept as applicable to 
the tools/code I maintain. Because you are wanting to remove one 
mechanism I am using to keep track of the tickets I work on.

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

And I see a "next release milestone" with the policy that you defer 
tickets at each new "next release milestone" as equivalent to a "to be 
determined" milestone. It's just as "wishy-washy" in that it doesn't add 
any more guarantee that you will fix the issues on the current "next 
release milestone". To put it another way... I don't need a "next 
release milestone" to tell me that I need to work on tickets.

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

We have three people indicating that such a milestone is useful in some 
form.

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

Given the response rate from the Trac people to tickets in their trac 
system I suspect that they are as busy as we all are. And adding an 
additional management task that we have to do seems like a waste of 
time. And from my conjecture above, tasks that are seen as wastes of 
time end up not getting done if people think they are being forced into 
it. Because it's much easier to ignore them than to deal with them. 
Hence I suspect the tickets will remain with the default "next release 
milestone" and on the next release cycle some will have go poking 
everyone to adjust the tickets. And hence creating animosity toward the 
ticket management and release process, again.

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

OK. Perhaps you would benefit from "Boost Python x.y.z", "Boost Python 
x.y+1.z", etc. milestones?

> and from the
> (admittedly small amount of) study I've done on the subject of task
> management, the experts agree with me.

I can't argue against unnamed experts ;-)

> In my opinion, the system should be set up to encourage resolution and
> discourage lingering unresolved issues.

That ends up sounding to me as "force the next release milestone 
management style onto others". You might think it's encouragement, but 
the people having to follow your style will see it as force. I'm not 
trying to be contentious here, just pointing out a psychological aspect 
you may not be noticing. You are the "lead" of Boost, whether you 
realize it or not, and if you tell people we should do it this way they 
are likely to follow even if it's sometimes grudgingly, and silently.

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

I guess that would be a key psychological disagreement. Technology (I'm 
reading that as tools for now) is meant to be helpful and to be used as 
one sees fit, not to constrain. If I thought about constraints in 
technology the way you do, I would have given up on programming as a way 
to get what I want/need long ago... We use tools, tools don't use us.

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

Thank you :-)

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

It's not radically different, but it a different between one "future" 
milestone (as many different "future" milestones) we all share if 
there's a point other than more bookkeeping.

> 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

One I used today was "You only know the plan when the plan is 
accomplished" -- myself.

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