2015 Strategic Summit (Sorrento) Summary

in April 2015, a strategic summit was held during the ever-so-lovely Plone Open Garden in Sorrento, Italy. This is a summary of those discussions.

A summary of the results and topics of the Strategic Summit, held in Sorrento in April 2015. Some take the form of more or less concrete roadmaps towards Plone 6 and beyond, others are community processes that should become part of our mindset and culture.

Note: the order of the various topics here does not mean a rating by importance or urgency; various tasks can be taken on by differing parts of the community simultaneously.

 

Preliminary: it is helpful to read at least the intro sections of the 2012 Roadmap and also the results of the “2020” discussion

 

Consolidating the backend stack

 

A process and policy decision was reached: since we are the primary consumer of CMF, and of Zope2, we want to bring these more in line with our normal development practices, testing and CI. This would eliminate some unreliable infrastructure (svn.zope.org) and can simplify developer process. We would like to do this with the blessing of the current Zope2 and CMF owners.

From there, a range of potential cleanups and simplifications were identified, but also challenges (time, money, process). Still, this will be a longer running effort that we want to get started as soon as possible.

 

Future of Archetypes

Furthermore a discussion was had on Archetypes maintenance. Suggested: deprecating in Plone 5.1, stop officially supporting in 6. What would be needed for that is:

  • decision & clear roadmap

  • more helper scripts to help people migrate content

  • better documentation on how to migrate business logic

  • a clear path forward for some vital addons, like PloneFormGen

 

Frontend JS development

It is clear that we need to move ahead with JS. On the other hand, the JS world is far from stable, and lacks a clear roadmap. Not only do the frameworks come and go, they also have vastly different approaches, so comparing Angular with React with Meteor becomes comparing apples, oranges and limoncello.

Yet we can decide upon two strategic decisions for now:

Patternslib/Mockup

Consolidate Patternslib and Mockup. Patternslib is lightweight, Mockup has the parts that are Plone-specific and should not replicate anything in Patternslib. Within the Intranet Consortium this consolidation has already been worked on. This should provide us with a sane, testable way to do JS in the years to come.

New RESTful Backend API

Work on a RESTful api, which can — and should — serve as the way to open up the core technical strengths of Plone towards various frontends.

So: Build a RESTful hypermedia API as a foundation for modern Javascript development/frontends.

This allows us to achieve a loose coupling between our frontend and our backend.

https://github.com/plone/plone.restapi

 

Actions:

  • [CODE] Finish plone.restapi as a minimal viable product (version 0.1, just content, just read)

  • [CODE] Write proof-of-concept implementations for HTTP verbs in ZPublisher

  • Evaluation possible async/sockjs options

  • [COMMUNITY] Find people that are willing to contribute to this

  • [COMMUNITY] Discuss ways of how we could fund this work (people, money)

Example - Django REST Framework funding campaign:https://www.kickstarter.com/projects/tomchristie/django-rest-framework-3

And a decision on the third step is purposefully postponed:

 

A modern, state-of-the-art Javascript Frontend (decision postponed)

Different purposes may require different frameworks, and actually waiting half a year is not a bad thing at all; some more stability and convergence may very well appear in the JS world (or a new framework to rule them all…).

  • Build a modern “state-of-the art” Javascript frontend based on existing Javascript frameworks/technology.

  • Do not reinvent the wheel.

  • Evaluate different options.

  • Let code decide. Talk is cheap.


Actions:

  • Write down our requirements

  • Evaluate the different options we have

  • Evaluate possible upgrade paths

  • Build prototypes with different frameworks

  • Make a decision on a technology stack



“Power” / “Through the Web” Plone

This discussion covers various topics, and has also gone under other names: Through The Web (TTW), Hackable Plone, etcetera. The reasoning behind it is well explained in a blog post by Eric Brehault

It is also a reflection of the way Plone is actively being used, not only by ‘tinkerers’ but also by people running large and multiple instances.

There was agreement that putting as much power into the hands of power users and site admins as possible is a good thing, and that this should be a normal, supported and not frowned-upon practice. However, to make this viable, we should stick to some rules and guidelines:

 

  • Configurations should be repeatable. Clearly defined export and import of both content and configuration can form the basis for ‘distributions’ (combinations of add-ons, configuration and content to get people off to a flying start)

  • Recognize limits. TTW installable add-ons, for instance, will be unacceptable to many larger clients and security-conscious admins; yet we can make it easier to discover add-ons.

  • If changing something TTW is an option, it should be in the Control Panel, and we should support users by having a nice editor with syntax checking, informative error messages, versioning.

  • The same goes for import/export: there should be buttons in standard places.

 

Some options that were discussed:

  • Editable PO files. This allows users to change wording in something that fits their organization.

  • Editable labels on Dexterity behaviours, per content type. The field definitions and logic do not change, but the user-facing labels do. (Caveat: it’s unclear whether this is viable, code-wise)

  • collective.jbot as a solution for the Custom folder and portal_view_customizations (that have issues with restricted vs unrestricted python and now can lead to broken sites). Although there are also voices that say it should go into theming. But there are different use-cases here: some have customizations that are repeated into many themes/subsites, or sites where the theme changes often.

  • Other recent efforts, like collective.themefragments, collective.ttw, collective.themesitesetup.

 

So, while different use-cases may require different add-ons, and some of these need some more gelling time, the philosophy behind it is supported and should be kept in mind.

 

Mosaic

Special mention should be made for Mosaic. It would be a major step in giving power — and fun! — into the hands of site admins and power users. Therefore we should devote time and effort to make it into a reality. Efforts to make it compatible with Plone 4.x will be dropped, instead an alpha release for Plone 5 is now a priority, to get people to play with it.

More info at https://github.com/plone/plone.app.mosaic and https://community.plone.org/t/mosaic-the-new-layout-solution-for-plone/548, and you can easily deploy to Heroku for risk-free testing.



Marketing & Branding

Productive discussions were held on how to re-think marketing in a way that supports our multi-polar, multi-lingual, multi-continental community; without falling into some of the pitfalls of the past.

As basic assumptions:

  • Top-down, micro-managing marketing does not work well for us

  • There are language and cultural differences: what sounds positive in the US, may sound negative in the EU. The same goes for ‘vertical’ or marketing position: the conversation with nonprofits will differ from the one with large enterprises

  • On a more basic, ‘emotional’ level we may very well agree on a common underlying message, as we do share a whole range of values and principles (think archetypes in the Jungian sense, or other methodologies)

  • This is a longer-term process, but can lay the groundwork so that shorter-term campaigns can have different focal points depending on time, location, audience yet still be coherent in underlying message.

  • And while we have talent also on these topics in our community, we should not hesitate to call in outside help

On the basis of this, the marketing team, comms team and the Board can make further plans.

 

Plone.com

The site is soft-launched, and this has already led to more interest, more sponsorship requests and more participation by solution providers. Challenges remain: currently there is a (perceived) focus on the US, this needs to be more global. But see above for language and cultural issues.

However, just the fact that it is now live is a nice solid basis for iterative improvements, and shows that the work of the team behind it is starting to pay off.

 

Plone.org

There was a detailed report on the current status. Victor has done incredible work, but needs help.

So, after discussing some more, it was agreed:

  • To form a project team ( Víctor, Paul, Gil, Christina, Fulvio)

  • To take pragmatic decisions (roll out on Plone 4.3, finish critical stuff but worry about the rest later)

  • Have it clearly focused on community

  • Roll out soon!



Diversity and a Welcoming Environment

 

To begin with, we established the scope and aim of our discussion. Diversity is not just about ‘increasing the number of women within the community’. While that would certainly be a desirable outcome, diversity takes many forms (gender and gender identity, sexual identity, ethnic background, geographical background, language, age, social class, phase of life, just to name a few). We agree on the intrinsic value of having more diverse communities and teams, and the fact that this will allow us to make better decisions.

Some concrete steps that were discussed:

  • Break down the ‘programmer myth’ that you need to be young, male, not responsible for dependents, and 100% obsessed with code and code alone.

  • Highlight the fact that a sustainable community (and sustainable businesses!) have both the opportunity AND the pronounced need for balanced work/life (including parenting, social activities, hobbies, education), and a much wider variety of skillsets.

  • Start reflecting this as much as we can already in the program for Bucharest, in cooperation with the organizers—both in the topics for talks (not only code talks, have a diverse reviewboard, have buddies/coaches and a preference for first-time speakers, …) but also the social program. (laid-back picnics or high tea, significant-others activities, …)

  • And also start to reflect this better in our communications.



Training

We have a great, and improving, set of training materials at http://training.plone.org.

And now, we also have a Training Team!

 

Documentation

We will need, as a whole community, to step up the documentation efforts for Plone 5 and beyond. While the framework for presenting our documentation has been massively improved, in order to make it a real first-class citizen we can — and should — always strive for better.

  • Tutorials and screencasts are a missing area

  • We should make sure all new features have documentation before being released

  • Care should be taken to keep the docs in line with best practices

 

Installers

One major point decided is that we seriously consider the option of hiring outside help to have a proper Windows installer, as the need for such an installer was affirmed.

Mac OS X installer no longer maintainable because Apple has made it very difficult. Instead, we are recommending the Vagrant installer.

Besides that, the Ansible recipes for deploying are getting traction. There are also (unofficial) one-click installers for cloud services like Heroku, Bitnami, Digital Ocean, Docker containers.

Communication With(in) the Community

The newsletter should get more prominent attention, and will include a collection of activity, regular updates of team activity, job openings, recent launches. Furthermore, we want to develop a more coherent and planned social media plan.


Community.plone.org will be the discussion platform, rather than mailing lists, except for the dev list.



Enterprise Search and ZCatalog

A separate discussion was held on search within Plone. ZCatalog is slow but it has important characteristics that make it difficult to replace in the short term:

  • Its simplicity, being part of a single process in the out of the box "instance" installation of Plone, requiring no external dependencies

  • Its transactional nature, which ensures that users see consistent navigational elements when they create or modify content

  • Its acceptable performance in at least small scale installations

 

Alternatives discussed included Solr (using collective.solr), Elastic Search, Google Search Appliance (using collective.gsa). We will:

  • Set up performance tests

  • Make ZCatalog more pluggable

  • Make collective.solr more visible in docs.plone.org, and improve collective.solr documentation



Intranet Consortium

A special track was held by the Intranet Consortium, a grouping of (by now) nine Plone providers that have joined forces to come up with a social intranet. Not only the product itself is showing remarkable progress, also the process is working out. Over the next few months, the Consortium will even step up the (already massively impressive) development effort. The approach is very clearly defined as “Design First”, which makes for a radically different process than traditional website development.

 

Yet they do remain very much aligned with the general Plone community, and all code is donated to the Plone Foundation.

 

New site has launched! ploneintranet.org. The documentation can be found athttp://docs.ploneintranet.org




Further resources:

A great live-blog of many of the discussions was kept by Maurits van Rees, seehttp://maurits.vanrees.org/weblog/archive/2015/04/