On Wed, 10 May 2006 21:05:04 +0100, whit <[EMAIL PROTECTED]> 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.

Then, we let the dust settle. We don't introduce anything that rocks the boat too much, but we enable a .5 release to improve the framework, to give developers better tools to build upon, to ensure consistency and currency with the lower parts of the stack (e.g. new Zope/CMF versions). These versions are easier to migrate to, they are about safety and stability. And it may take until the subsequent .5 until some of the users of the *previous* .0 are willing or able to upgrade.

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.

So, the step from 2.1 to 2.5 was a natural evolution, to incorporate Zope 3 much more into our stack, which in turn has unleashed a lot of power that we can use to drive the more real use cases. It was a joy to see how much power we could get out of this discussing implementations of PLIPs in Norway.

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.

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.


"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006

Framework-Team mailing list

Reply via email to