[Framework-Team] What is Plone 3.3?

[Raphael Ritz]

Martin Aspeli wrote:
> Hi,

Hi Martin,


I hear you loud and clearly ;-)

Actually I even share all of you concerns.

And I was just about to propose the add-on approach
while reading your message. I would agree that if
we are providing such changes in the 3.x series
site admins should be able to decide what they want
(and some things wouldn't even need add-ons like the
moving of the 'manage-portets' link: adding an invisible
site action and giving the link a dedicated CSS class
should make it pretty straight-forward for people who
want that change *if* it is properly documented).

In particular the printed books are a strong argument
from my POV. Just imagine a brand new book coming
out in a few weeks from now and parts of it are already
outdated. That wouldn't fit my understanding of what
we want 3.x to be.

Raphael
 
>
> Over the past three days of conference chatter, we've been talking a 
> lot about how we're proud of Plone 3.x being "boring". It's stable. 
> Upgrading is safe. Improvements are incremental. You and your users 
> don't need to re-learn lots of things when moving from one 3.x version 
> to another.
>
> Now, several PLIPs are being proposed for 3.3 that I feel would break 
> this mantra. They are not accepted yet, obviously, but I think it's 
> important to be explicit about our intentions.
>
> *If* we agree that we want to retain stability and predictability 
> across the 3.x series, then we have to accept that:
>
>  - We can't remove, change or move major pieces of the UI.
>  - We can't break add-on products and (sane) customisations.
>
> This means that we sometimes have to delay perfecting things until at 
> least a new major release.
>
> There are books in print (and about to go to print) about Plone 3. 
> There is documentation on plone.org that we can't (and shouldn't) 
> "just change". People have received training and  spent time learning 
> how to use Plone. If the UI changes, they have to be re-trained. "Just 
> moving a link" may not seem like much, but I guarantee you that it 
> will cause a lot of pain and frustration.
>
> Right now, the things that concern me are:
>
>  - Adding a new way to add content (the "add sibling" proposal)
>  - Moving the contextual "manage portlets" link somewhere else
>  - Removing the "display" menu and putting the behaviour on the fieldset
>
> (the last one is doubly bad, because it would require any add-on 
> product that used this menu to be updated in a possibly 
> backwards-incompatible way, to add a field to replicate this, and we'd 
> need a unique solution for non-AT content).
>
> Note that I actually agree with all these changes: The display menu 
> causes confusion; the manage portlets link is ugly; adding a sibling 
> object is too cumbersome. However, we should solve these problems 
> properly in the context of Plone 4, not make tactical changes in 3.x 
> that cause confusion and break documentation.
>
> Luckily, there's a "workaround". :) All of these changes could be 
> provided with easy-to-install add-on products. These could be tested 
> on real users and used by those who want different behaviour.
>
> Cheers,
> Martin
>