Jurko Gospodnetic' wrote:

Hi.

...

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.

Should those even be assigned to a milestone?

But we need a default milestone. Right now Dave changed it to be "Boost 1.36.0" as default. How can we assume every new ticket applies to the Boost releases? We could make the default be "None" (i.e. the empty one). But IIRC there was objection to that because it would remove tickets from some of the reports. -- -- 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

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? 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. If dealing with the ticket means deferring to an even later deadline, that's fine. 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, 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. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

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

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