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
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.
"You can just adapt yourself out of it..." // Archipelago sprint 26/04/2006
Framework-Team mailing list