Plone Release Manager Wichert Akkerman sent the following email to the plone-developers list today, outlining the schedule for Plone 3.1, which will end with a final release in March 2008.  Plone 3.1 will be a small release with a few new features and no major architectural changes.  It will be a seamless and safe migration from Plone 3.0.

In coordination with the new framework team I am happy to be able to announce the timeline for the next Plone feature-release: Plone 3.1. The release process for 3.1 has very specific goals:

Safe changes only: since this is a minor release which should not destabilize Plone 3.x only changes that are risk-free will be considered. This means that no or very minimal migration steps are allowed, everything has to be properly tested, documentation has to be in order and the user interface has to be finalized. This also means that 3.1 will be based on the 3.0 codebase: Plone trunk has far too many major changes already.

Do not overload the framework team: the deadlines are fast and strict, so making it easy for them to rest proposals is important. The best way to do that is to create a buildout based on the latest Plone 3.0.x release and include only the changes relevant for that proposal.

Quick release schedule: we do not want to take 9 months to get this release it. This means that all proposals have to be completely done and polished in order to be acceptable. The migrations, if any, have to be in place and working, there have to be working tests and the user interface must be complete.

This is the timeline for 3.1:

  2007-12-14 : PLIPs for all features have to be finished and submitted

  2007-12-21 : framework team gives verdict on PLIPs only, not an implementation

  2008-01-19 : review bundles have to be submitted to the framework team

  2008-02-02 : framework team completes reviews

  2008-02-08 : 3.1 pre-release tagged

  2008-02-11 : 3.1 pre-release with installers released

  2008-02-15 : 3.1 release candidate tagged

  2008-02-18 : 3.1 release candidate with installers released

  2008-02-29 : 3.1 final tagged

  2008-03-02 : 3.1 final with installers released

Note that there is a change from the procedure we used for Plone 3.0: there is now an extra PLIP-review step. This has been added to allow us to check of a proposal is not too invasive or for some other reason undesirable for 3.1. That makes sure that nobody will be trying very hard to make a deadline only to hear that their work is not going to be considered.

As you can see this is an ambitious schedule. This means that we have to be very strict in what will be accepted and what won't. There is no shame in missing a deadline - we are all busy people and sometimes a deadline is just not attainable. Anything that does not make it in can be reconsidered for 3.2 or 4.0.

Many of us are familiar with the One Laptop Per Child project, which is making technology and information more accessible. Eben Moglen talked about this at his keynote at the 2006 Plone Conference (link to video, youtube version). What struck me as most powerful about the project was the clear, concise design principles. From the principles, you know exactly what the project is, and without any of those things, it would not still be OLPC.

At the Moglen talk, I asked about what Plone's design principles are. The question was more for the community, and a lot of people seem interested in the question (and it's answer!) over the last year...yet nothing happened. So, a year later, I started an informal survey at the Naples conference.

With the idea of making a draft of what Plone's core design principles are, I have been asking people around the conference, including core developers, board members, integrators, end users, new developers,...though there is obviously a diversity that we would expect from our community, I am trying to synthesize here the responses, with the intent of submitting the words of the community back to the community for review :)

And with no further ado...my attempt at articulating Plone core values:

1. Easy to use (to add/edit content)!
Responses: Easy to use (highest hits of any), usability (high number of hits), intuitive

This is the bread and butter of Plone, the part that every one of us experiences when we see it and use it, and the fundamental part of . Plone's commitment to usability since the beginning is apparent in the product and the community, and it is core to Plone to make it easy to use for content management.

2. Approachable
Responses: sensible defaults, easy to get, easy to deploy, easy to download and install, opportunity/potential, giving technical people (though not necessarily developers) a great system that they can gradually get more into the customizing with a steady and approachable learning curve.

This principle is about making it easy for people to get into Plone and get hooked on how cool it is, and then be brought through a manageable learning curve as they do more of their own custom implementations. It means out of the box, the settings make sense and that we empower people with tools that give them lots of potential. It also means that smart scripters (even without Plone development experience) can get into doing custom work also.

3. "Developer Nectar", ie Built to Last, quality framework
Responses: Safe customizations, smart adaptability, easy to extend, extensible, easy to develop, user centric, use case driven, best practices, web standards, accessibility, good error messages, cross platform, test-driven, solid development, open source, scalable (up and down), passion for the technology (doing things the right way, even if it is a new technology).

Moving on from those getting into the customizations, there is the more serious development work in Plone, which is solidly built on best practices (web standards, accessibility, development process, test-driven, etc). This is about helping developers learn about and adhere to good practices, as they get deeper in the system, by having defined processes and practices. It is also about using cool technologies that keep developers interested and having fun. Finally, it means that we provide direction to the developers that originates in the way people want to use the system, captured as use cases.

4. Fun! Community!
Responses: fun, fun atmosphere, entertaining, community (one of the more popular responses, though without certainty that it applies to Plone the software, but knowing it is essential to survival and sustainability of Plone)

Some intertwined concepts here, that I am calling Fun & Community. First on the fun: this is about being fun to use and develop with, as well as being a thriving community with amazing people. The community is an obvious part of anyone who already participates. It is amazing, whether it is the "mindshare" or finding others working in your area, or just having a great time with passionate, bright people, Plone's community is a huge asset. Without it Plone wouldn't be Plone. The community also provides lots of support, which helps sustain it and make it more approachable.

So, that's the core. Definitely needs language refinement and maybe also refactoring, but I submit it for your review :)

There is one item I am on the fence about. It is something that is not core now, though important, and which, if it were to be core, would affect certain decisions and involve some tradeoffs. That item, is "collaboration" as a use case for Plone the software (there is tons in the community itself, which is not what I am referring to here). There are definitely some collaborative features in Plone, but most are through addons or configurations (a few new ones in 3.0, but still lacks several).

Conclusions

The idea of core values or design principles is that they are the things that never change, that, if removed, would take away the Ploneness. The core principles don't necessarily have to unequivically describe the current product. The fact that we don't already have these principles articulated means that it may not be true, but it should help us to enhance the product in the future.

This is being submitted for comment and review from the community. The idea is *not* (did you miss that? I said NOT) to make a long list. Core principles lists should be as small as possible; the goal is not a comprehensive list of things we like, but instead the smallest list of things we can't live without.

One note about timeliness...as announced at the conference in the State of Plone talk, there will be a Plone visioning/strategy meeting in Feb 2007 at the GooglePlex. I strongly believe that we need to identify the core principles[1] before we engage in visioning, so here's my small contribution to that.

From talking with others in this process, I got a lot of good, complementary ideas as well as clarification on this excercise. I want to thank Paul, Jon, Martin for supporting the inquiry process. 

References:

[1] The book, Built to Last, is a classic presentation of the concept of core values as necessary for a company/organization/movement's longterm success. It defines these as the small collection of values that *never change*. These are the heart, stability of the institution.

With a huge thanks to the authors of Updating add-on products for Plone 3.0, Limi, Martin, Geir, Sisi, and others, it was a breeze to get Salesforce Base Connector working for Plone 3.0.  We just pushed out another release, so that it doesn't appear DOA after putting out a non-3.0-compliant release last Friday.  It's still very experimental, but now testable with the latest and greatest.

The word from Wichert Akkerman, Plone 3.0 Release Manager is out: Plone 3.0 has been tagged, installers are being built over the weekend, and Plone will be formally released on Tuesday, August 21st!

Plone 3.0 is a big release, perhaps the most ambitious Plone release ever, the product of over a year of work from the Plone team. For a quick overview of the highlights, see "8 Really Cool Things About Plone 3.0" which I wrote a few weeks back.  Alex Limi has also written more in-depth information on Plone 3.0's features.  Long story short: it will blow your socks off. :-)

Congraluations Wichert, Martin, Alex, Hanno, and to the hundreds of other folks who have helped deliver Plone 3.0 to the world.  I'm looking forward to the honor of introducing Plone 3.0 with Martin and Wichert at Plone Conference 2007 in Naples this October.

While creating a working demo for my post on Saving PloneFormGen Data Directly to Salesforce.com, I was reminded of and discovered several new irritating bugs present with the current field mapping user interface.

Jesse Snyder and I were able to pick of several of these during today's ... er, yesterdays ... Open Source Friday session and package up a 1.0 alpha 2 release. Fixes include:

• Due to some trailing and proceeding character stripping that happens within DataGridField's FixedRow implementation, inadvertently named fields like "My Form Field with Trailing Spaces   " (spaces intentional), could never be successfully mapped to a Salesforce.com SObject field. NB: We're still using the Title of form fields as the "key" for our mapping, which has its limitations, but is easiest in this more proof of concept phase of work.
• Because we're eliminating a user's ability to wipe away form fields by disabling DataGridField's add/remove row features (this is by design, as a "read-only" paradigm is much clearer for users), re-titled and deleted fields were polluting our available form fields for mapping user interface. We've now got code that cleans up those form fields which are unmappable to Salesforce.com SObject fields anyway.
• We've also got a nice little, fully passing suite of 25 tests, which is starting to get into the realm of respectable for our code base.

Up next is likely to be i18n work, improving usability around a chosen SObject's required fields, and enabling the mapping of PloneFormGen's DateTimeField to Salesforce.com's Date/Time string format. 

Let us know if you come up with anything that's not currently on our todo list. 

One of the signs of a mature open-source community is that community's ability to grow new leaders and to evolve leadership processes that are appropriate to the community's increasing size and ambition.

So, it's really cool to see that Plone's first "Framework Team" (Alan Runyan, Alec Mitchell, Michel Pelletier, Benjamin Saller and Whit Morris), which took responsibility for the upcoming Plone 2.5 release, has handed over the reins to a new, larger group for the Plone 3.0 cycle.

These are the folks who are officially responsible for making the final decisions about what code to recommend for inclusion in Plone 3.0, and for driving the overall process of reviewing PLIPs (Plone Improvement Proposals) and bundles of submitted code. 

Your love, appreciation and code bundles with unit tests they all deserve.

Here's Whit's announcement to the plone-devels list.

I'm proud to present to you the new voting members of the framework team. Based on interest, we have a well rounded seven!

========
FWT II
========

Wichert Akkerman
Martin Aspeli
Rocky Burt
Raphael Ritz
Hanno Schlichting
Vincenzo Di Somma
Helge Tesdal

This voting body is effective now. In their first vote, they elected Martin Aspeli to act as the official spokesperson for the group. You, plone-at-large, may start submitting PLIPs w/ code bundles for their review for inclusion in Plone 3, the (enter tagline here).

-----
FAQ
-----

To clarify any confusion, I've included some answers to some frequently asked questions.

Q: What does the framework team do?

A: The framework team is responsible for recommending code for inclusion in a Plone release to that release's manager. In the release cycle, they drive the PLIP and bundle code review cycle.

The voting members do the formal duty of collecting information from the community about bundles offered for review, and making the formal decision by voting whether to recommend them to the release manager. One
member of the group is chosen from within the group as the framework team lead and is responsible for communicating all decision of the team onto the plone-devel list.

Q: Who is on the team?

A: Anyone who wants to review code and is interested in actively participating with shaping the technical vision of Plone's future. Each release, a small group in a similiar timezone is chosen to cast the actual votes on proposals (PLIP + bundle) on the advise of the larger team.

Q: How/when are the voting members chosen?

Currently, voting members are chosen arbitrarily on a rigorous *wink* criterion of general interest, recent contribution, timezone and who the former voting members thought would do a good job. As the framework team is dedicated to evolving process, this is open to become a more formalized democratic process.

New voting members are active after the first alpha of a new release and remain active until the first alpha of the next major release.

Q: What happened to the old framework team?

A: The former voting members are still part of the team and will help out with code review. Whit Morriss (aka me) has offered to stay on as a non-voting member (oxymoron, yes) to help with continuity and as a community liaison (read, svn-nanny).

Q: Sounds groovy! How can I participate? (I just can't get enough e-mail from Martin...)

A: Thought you would never ask... the new voting member probably have some ideas, but here are some broad strokes that go from early in the release cycle to late:

* Participate in / start technical discussions of possible PLIPs on plone-devel (preferably with prototype code). This also includes discussions of use-cases and end-user needs.

* Join framework-team@lists.plone.org and participate in discussions of
refining development process and codification of developer best practices.

* As plips come in, help plippers make bundles and prepare their code for review.

* As bundles get ready for review, review code and report your findings to the voting members.

* take off your framework-team hat and help get that release out!

If after this the experience moves you, and you want to bear the responsibility of voting and encouraging others to review code, let the current lead know of your interest.

cheers!

-w

A couple of random thoughts about this:

• I noticed that the new members are listed on the Plone.org Framework Team page, but that much of this helpful FAQ is not yet on there.  (Hint, hint, hint.)
• Chosing Martin Aspeli as the "official spokesperson" was really smart; in recent months, I've been extremely impressed by the clarity, smarts and grace of his communications with the Plone world.
  
• Recruiting a new team for each release is smart -- this helps avoid burnout and makes sure that there is fresh perspective brought to each cycle. 
  
• I have to think that Plone's model of decentralized leadership within a well-defined, transparent framework is a huge long-term win for the platform as it navigates a complex landscape of peers, competitors and collaborators.