On Thu, 11 May 2006 16:11:30 +0100, whit <[EMAIL PROTECTED]> wrote:

"But in my opinion, if it's November or December instead of October
that's necessary to make this happen, that's a pretty small price to pay
for a release that we can market as a great step forward, not just
another trickle. "

I appreciate the enthusiasm, but 2 points:

1. code is ready when it is ready.  for projections made now, it is
wiser to leave things that don't have bundles out of the equation.
Better to have interesting releases across the 3.0 series.

I think that this vision of the roadmap and the future is one perspective - and it's a slightly different one from my own. In a way, you're proving my point, because if this is the underpinning assumption you're making as a (former) framework team member, then that has an effect on what you vote in or out.

If the consensus is that we need a big, flashy, marketable release, it changes perceptions compared to a scenario where we want a slow and steady release. Since the framework team and the release manager are the custodians of that decision, this thinking (one way or the other) will profoundly affect how Plone looks the next time we roll a release. And if that is the case, then why are we not more openly engaging in *that* debate earlier on.

2. worrying about marketting and the "meaning" of release number imho
has had a negative impact on discussion and effective planning in the
past.  two things to remember in this regard::

- we have more features that have been released than have been marketed
or made truly usable to the market we claim to be aiming at.  Therefore,
needing to make the 3.0 release "marketable" is a non-starter to me (we
need to get people to market).  Having one or two important features to
focus on per release is more important than a ton of features.

At least it is to you (and I'd agree with you, mostly, although I fear one or two new features every 6-8 months is too slow a pace). But we need to be cognizant also that when Plone-the-product hits 3.0, there should be excitement. There should be reviews. There should be marketing. And we can't have that if the innovations that people see are minor. To the developers and integrators, this possibly doesn't make much difference, except it's through this kind of ooomphf that we get new users, and ultimately new business.

- the meaning of a release is a marketing question.  if marketing says
"we need SoC for publicity reasons", then it makes sense to wait. but
otherwhise, this should just be a discussion of technical merit and
preparedness.  the framework team should not be effected by the
marketing vacuum.

How can they not be? I mean, if their role is to vote things in our out, naturally they will (and I'd argue should) be influenced by what we as a community want the release to look like. Do we want a slow-and-steady release to stabilise the framework (which is what I was under the impression that the .5 releases were for), well then we'll value stabilising improvements over new-UI improvements, possibly even rejecting some new UI concepts because we want to give users and third party developers the time to adjust to the innovations made in the previous version. Do we want to make those kinds of innovations once again, to stay ahead of the curve and make Plone seem like it's still the best CMS out there (which is what I thought the .0 releases were about)? Well then we may take a few more risks at the expense of making real progress in what Plone-the-product can do.

Martin

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

_______________________________________________
Framework-Team mailing list
Framework-Team@lists.plone.org
http://lists.plone.org/mailman/listinfo/framework-team

Reply via email to