> 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
