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.
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:
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.
This allows us to achieve a loose coupling between our frontend and our backend.
[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:
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…).
Do not reinvent the wheel.
Evaluate different options.
Let code decide. Talk is cheap.
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.
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.
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.
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.
We have a great, and improving, set of training materials at http://training.plone.org.
And now, we also have a Training Team!
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
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
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.
A great live-blog of many of the discussions was kept by Maurits van Rees, seehttp://maurits.vanrees.org/weblog/archive/2015/04/