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?

I'm not sure myself, we have never worked out any hard-and-fast
prioritization system. The levels I stuck in there so far are my own
estimates of priority order based on the AusMeeting talks.
Basically the priority items needed by the users who were present there.

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

I need LogDaemon, and apparently one other user needs it, but less than
me. As I'm the one done the code, I have formally pushed it to after 3.1.
It's waiting on time to run-test. But I don't want to create any more
excuses for not releasing 3.1.

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

We already discussed it way back, you, myself, and Henrik came to the
conclusion that priority milestones rather than time-based ones would be
better for releases.

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

priority for a) developers doing the work, and b) customers paying for
things to be done earlier than otherwise planned.

> How is it assigned?

By any of us who plan on doing it, even 'eventually'.

> What does it affect
> procedurally?

How each of us think about the features earmarked, and how we discuss them
amongs ourselves, how they block or non-block a release, how they get
sponsorship, (all my points earlier).

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

Yes. I hoped to state it explicitly rather than implying, sorry on that.

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

Yes. Maybe a priority 0 'hands off I'm already neck deep into the code
here' as highest though.

Amos
Received on Fri Aug 22 2008 - 02:24:00 MDT