[Framework-Team] Re: Re: Release roadmap for 3.0

[Alec Mitchell]

On 5/10/06, Martin Aspeli <optilude at gmx.net> wrote:
> On Wed, 10 May 2006 21:05:04 +0100, whit
> <d.w.morriss at gmail.com> wrote:
>
> > /me dons grumpy old former FWT member hat
> >
> > remember, all that SoC stuff has to have bundles and be approved by you
> > guys.  No implementing proposals after the fact.  That's about the only
> > standing rule for this team.
>
> I agree entirely.
>
> > So if you are looking at this sort of
> > schedule, likely almost none of the SoC stuff will go in until until a
> > later 3.x release.
>
> And, as I just replied to Rocky, this isn't something we can just take
> lightly. It may not matter to you or me, but it matters a hell of a lot to
> the guy who is debating whether to put the effort in to deliver some
> killer feature. If the battle is lost before it's even begun, he won't
> bother, and it'll more likely be 4.5 than 3.5 before it gets picked up
> again (there's a reason why versioning is PLIP #8 and we have 157 PLIPs
> spanning several years).
>
> > Also, 3.0 really should be just one louder than
> > 2.5, regardless of the number.
>
> I don't agree with this - and I don't think this was the intention with
> the UI release/framework release split. As I recall it explained to me,
> the plan was that .0 releases would be the big bang - once a year, we
> release a new version of Plone with impressive new features, where we
> progress and make some hard decisions about what we may need to break or
> strongly deprecate to move Plone-the-product forward.

I don't think the sentiment that whit was expressing is really one
that you can disagree with.  It's a simple fact that we only have six
months for 3.0, and as a result there is a real limit on the amount of
stuff we can reasonably expect to include.  If we want if Five louder,
then we will need a lot more time.  However, because it is ui focused
the changes will be user visible, and therefore from a marketing
perspective it will be much "louder".  Nonetheless, there are real
limits on how much can be done, primarily determined by the number of
developers actively participating in the release and the time they are
capable of committing.  Fortunately, the Norway sprint and the SoC
project have potentially given us a fair amount more available
man-power than we had for 2.5.

...

> I'd argue that Plone-the-product, as far as end users is concerned, hasn't
> really progressed very much since Plone 2.0. We still don't have
> versioning, locking, staging, taxonomy/categorisation in anything more
> sophisticated than a folder, we still have a very static UI, with many
> slow page reloads, we have a fairly inflexible portlets infrastructure
> that makes it awkward to make the CMS personalisable. And some of the cool
> things we've talked about for years that real users really love, such as
> contextualised help and actions, or UI improvements to selection widgets
> and folder navigation, are still unrealised.
>
> Meanwhile, there *is* competition. The big name right now is Alfresco, and
> they are *killing* us on many aspects. We still have a stronger community,
> we still have a better business model, we still have a better UI (though
> their's ain't that bad). The other big one is (slightly awkardly) Rails,
> where all the innovation in web UI seems to be happening. If Plone is to
> survive, it needs to stay ahead of the curve, to be sexy and intuitive. It
> also needs to avoid having too many red crosses in the feature matrices.

We all agree that there are a lot of great thing we should do, and
need to do in the long and short term.  But your job as the framework
team is to make a realistic assessment of what we can actually get
done in a 6 month time frame given the available resources.  What
Alfresco is doing and what customers are looking for in a CMS is at
most a peripheral consideration for you guys, and should rarely be a
factor in any FT decision (the only cases where it would be are when
there are two proposals of equal viability that are competing for the
same developer resources).

> But 2.5 is a whisper to our end users, to the people who review Plone in
> magazines and online journals. About the only innovations I can think of
> off-hand are drag-and-drop folder re-ordering, placeful workflow (which I
> fear most people won't need), and maybe the history tab making a
> re-appearance for a poor-mans audit trail. PAS? Views? Users don't care
> (developers do of course). If 3.0 is no louder than that, we'll get maybe
> two or three of the Archipelago PLIPs in place, and Plone will make what I
> fear is another release that goes the world quietly by, and then community
> gets tired of the release frenzy, settles down to do other things, and
> very little happens.
>
> Take a look at http://plone.org/products/plone/releases/3.0
>
> How great would it be if Plone could have even the majority of those
> features? Let's not give up before we've begun.

Nobody is talking about giving up, but as the Framework team, all you
can do is encourage the people working on those PLIPs to get them into
a viable state and create a review bundles before the deadline.  You
job is not marketing or cheerleading, nor should your job be
influenced by marketing once the review process starts.

> > I would argue that the proposal freeze *is* the feature freeze *is* the
> > last date that the framework team accepts bundles for review.
>
>  From that point of view, sure, though there is a much greater informal
> period before that (which has arguably already begun) where we work out
> what we would like people to work on and what to push for. The process of
> even starting on a bundle isn't random, we have a pretty strong list of
> features we really want Plone to have at 3.0, that have something to do
> with how we want to market Plone and how we want to ensure it's not being
> left in the dust by the competition.

I think there's no argument that this informal period has already
begun, if it hasn't, then 3.0 will either be very late or even less
exciting than 2.5.  But in the end it doesn't matter what you really
want to see in plone, except insofar as you can encourage development
of those features during this informal period (which you do outside
your job as a framework team member).  All that matters to the team is
what gets done.  I think Hanno's proposal to model the dates around
the SoC dates makes a good deal of sense, though I think the mid-term
date is a bit optimistic to expect the SoC coders to have a reviewable
product ready.  Some of the SoC projects stand a good chance of making
it into 3.0 (especially those that are part of larger endeavors
involving multiple core developers), so it would be a poor decision to
use dates that might marginalize their contributions.

Alec