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.
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)
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).
...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.
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 (like I
ended up doing to LogDaemon for Adrian, and the recent contract for you).
Amos
--
Please use Squid 2.7.STABLE4 or 3.0.STABLE8
