Re: 3.2 plans

On Thu, 2008-08-21 at 20:57 +1200, Amos Jeffries wrote:
> Alex Rousskov wrote:
> > On Wed, 2008-08-20 at 15:06 +1200, Amos Jeffries wrote:
> >> At the AusMeeting08 we also laid out a few features needed in 3.2.
> >>
> >> I've cleaned up the quick roadmap notes we made live. Now seemed like a
> >> good time to experiment with the priority-based ordering system
> >> discussed a few months back.
> >> Could people please have a look at the Squid-3 roadmap page and give
> >> their opinions on that new ordering system. Better/Worse/Ugly?
> >>
> >> http://wiki.squid-cache.org/RoadMap/Squid3
> >>
> >> We will also shortly need to set a deadline for feature requests to 3.2.
> >> I'm minded to say end October (mirroring the suggested 3.1 release date).
> >
> > I am not quite sure what Priority rating gives us in practice and I am
> > not sure we should order items by priority rather than by likelihood of
> > completion.
> >
> > If a developer commits to adding a feature, what effect will priority
> > have on that person?
>
> Um, for them little, or additional help from the rest of us when goals
> coincide. It's a team effect, for enhancing collaboration more than an
> individual TODO list. As individuals we already have our own lists and
> methods. This is for the public face and team effort.
>
> > As for users, their priority is usually more
> > complex than a 1/2/3 rating _we_ can assign. User priority is very
> > context-dependent and is relative to other features, budget, time, etc.
>
> Also irrelevant to a developer priority, if users want something and
> think its too low they can pay someone to raise it. Same situation as
> now, only more transparent and with a more realistic achievement
> estimate for them in the end.

I am not arguing with the above, but I still do not understand what
priority value really means. Can you define its meaning? How is the
value assigned? What does it affect procedurally?

> As brought up in the first discussions...
>
> 1)
> Prioritizing instead of blocking release on a feature both keeps us
> out of the embarrassing position of having promised one which then get
> bumped (ie LogDaemon, probably eCAP)

I do not know about LogDaemon but eCAP is almost done and I do plan to
finish it.

> 2)
> All the remaining features listed for 3.1 you committed to complete
> before end of July. It's clear reality stepped on you this time, the
> other estimates were also all out by months. Thats very likely to be a
> repeating pattern with the fixed-time model when we don't all have
> fixed-time to allocate (not to say the same people slipping though).

Commitment, delivery estimate, and priority are three different things.
We are talking about the value of a priority tag here. I do not think
that assigning any priority will make delivery estimates more accurate
if that is the point you are trying to make.

I fully admit that I am late with completing a few features. I am happy
to discuss this if needed, but I do not think this thread is the right
place.

> ...and new bits I've realized also support it since we last discussed it:
>
> 3)
> Lets us add items which are high-priority but non-developer'd right
> now. What gets done gets released, no blockers. What gets delayed, too
> bad, it'll be out next time.
> But its more likely to be picked up sooner if clearly high-priority.
> CollapsedForwarding I was reminded on Tues has been 'high' priority for
> years, yet languished halfway down the wishlist.

Which probably means it was not such a high priority for folks working
on Squid3 (for whatever reason). Again, let's start with a basic
definition. Priority for whom? How is it assigned? What does it affect
procedurally?

> 4)
> If we have two developers with different priorities on one feature, we
> all can see what the current priority is for the committed developer and
> someone else can step in and give a hand if they need it more

Does this imply that the person responsible for the feature assigns the
priority?

For example, is the following an accurate definition?

        Priority value (1 being the highest) may be assigned by the developer
responsible for the feature to represent the relative value of that
feature to other Squid projects by that developer. When no developer is
responsible, the priority may be assigned by the Project to represent
the overall importance of the feature for developers. Priority has no
effect on feature acceptance.

Thank you,

Alex.
Received on Thu Aug 21 2008 - 15:01:55 MDT