Of course! We are flexible and would love the help.
I've updated (cleaned up) the roadmap discussion notes at https://plone.org/roadmap/plog-2017-roadmap-discussion
Here they are for your convenience (but this copy is missing links I have on the plone.org page):
These are the results of the roadmap discussion at the Plone Open Garden 2017 sprint held in Sorrento, Italy, in April 2017.
- Plone 5.1 will be released shortly (currently in beta). See the detailed release notes.
- We will end support for the old Archetypes content type framework (Dexterity is the current content type framework) as part of moving Plone to Python 3, which must take place by 2020.
- Beginning with the Plone 5.1 release, we will warn about the impending end of Archetypes support.
- Plone 5.2 is projected to include:
- Zope 4 (currently being worked on)
- RESTAPI, the plone.restapi interface package that allows JavaScript and other web software to use Plone as a back end service
- Accompanying Plone 5.2, we will have some add-ons that make use of RESTAPI, such as:
- the new Pastanaga user interface design
- the React JavaScript reimplementation of the Plone user interface (led by Rob Gietema)
- an Angular JavaScript client front end for web and mobile applications using Plone as a back end service (part of the Plone Headless CMS initiative)
- Plone 5.3 is projected to include:
- plone.app.blocks and plone.tiles
- the Mosaic layout editor (plone.app.mosaic) will continue to work with Plone as an add-on (that is, Mosaic will not be in Plone core)
- possibly the option to disable portlets, but this would require the "slots" feature from Castle CMS, possibly as an add-on, but requires further investigation
- Plone 5.4 is projected to include:
- some Castle CMS features (the recycle bin; repositories for images/files/videos; replacing the "Add New" toolbar menu with an "Add" button that presents a popup dialog box allowing editors to add multiple instances of allowed content types in place; the built-in content quality check on state transitions that checks content for various things)
- Plone 6 is projected to include these major breaking changes:
- the new Pastanaga user interface design
- a complete tile layout solution including content editing, site layouts ("site designs" in Castle CMS terminology), slots (instead of portlets and viewlets), and with Diazo rules disabled (replaced by site designs as implemented in Castle CMS)
- no more Archetypes support
- The Plone Headless CMS initiative is well under way; implementations of the Pastanaga user interface design (using either Angular or React, or both) will be released probably before Plone 6.
- Plone will be able to move to Python 3 since legacy Archetypes support will have been dropped.
- Reimplement Plone logins to work better with modern distributed/centralized authentication solutions.
3 Likes
I agree with @hvelarde, although its great there is some output from this discussion in italy every year, what seems to be missing is the rationale or "why". What input went into these suggestions? What were the pros and cons of the options? what were the other options? What is Pastanaga trying to fix? What user input went into it? What is a react UI angular vs vs Pastanaga and why have all or any? Why disable diazo when is a needed way for themers to adjust plone and plugins html to fit a theme? What problems is site layouts fixing? Is here are strategy here, ie an end goal and idea about how these get us there? What do the quality checks try to fix? Compliance to WCAG for content or is it something else? Is there a fix for default pages (https://github.com/plone/Products.CMFPlone/issues/519) and the display menu (https://github.com/plone/Products.CMFPlone/issues/704) in here anywhere? Whats wrong with plone logins? Is there a ticket for this problem?
At least some of the castle ones are based on actual use but it would be good to see anecdotes of how these features did solve problems, ie reduced training time, reduce support requests etc. Why these features and not others from castle? The only one I can see from that list that has a rationale is the add button allowing multiple items at once but how how big a problem was that? I'm guessing for some style of sites it is, but which ones? I believe the castle design for add also solves some of these problems - https://github.com/plone/Products.CMFPlone/issues/1371 but is the plan to solve those too? A toolbar that is easy for addons to add items/menus into and has more sensible, shorter list of items (so many tickets).
but you can see how deflating when it's hard to see why or reasons we are going somewhere. I'm sure there are good reasons for each idea and it would be doing the community a big service and help inspire people if what went on at these geographically isolated events was spread out into the global community of plone.
Thanks for the explanation @ebrehault. I suspect what is going on here is that diazo provides two main benefits, and wildcards way of working only needing one of them. I suspect wildcard doesn't reuse a lot of other peoples plugins and when has python developers who create custom tiles and other files system packages. They may also use jbot which requires an experienced developer. We on the other hand use diazo, not just for layout, but to fiddle with html from 3rd party plugins to get what we need for a given them. We do multisite exclusively so never pollute our add-ons with theme specific overrides of html, like you can do if you have one server per site.
The other reason why the diazo approach is still useful is when working with external themes and designers. We recently did a theme that had to get redelivered for various reasons. Each time it cost us almost nothing just reupload that theme overtop. Sometimes a couple of rule adjustments. If you go with dismantling a theme into seperate html parts then you can no longer do that. This only works when you have designers who are very technical and in lots of communication with your plone developers.
That is just our experience. There are probably other ways people theme out there that should be considered.
Do you think its wise to make such a big direction change without wider consultation with people who theme a lot of sites?
It's really important to have the right people in the room when these discussions take place. The way the big boys do things is not the way everyone does things. This is why rationales and wider community outreach is so important.
2 Likes
Dylan asks good questions. It's important to have community members speak their mind and ask questions.
However, I do take issue with Dylan's (frequent?) comments about in-person sprints. Our community recognizes that things get done and progress is made much more quickly (and sometimes "at all") when groups of us gather in person and work in a concentrated way on a task. That is what PLOG has been, and even though we didn't declare it a strategic sprint this year, that's what it has become. Yes, that does not preclude using the conference as a venue for strategy, but we also know that the conferences get so big and busy that it's hard to lock many of us in ONE ROOM for a day or two to focus.
The pros and cons were discussed. I hope others who were in on each discussion point will jump in here or in the relevant GitHub issue to provide you with their perspective, but it was impossible to capture the entire discussion in written form.
I've never said in person sprints are a bad thing. My point is that I'm not sure its a good idea assuming that you will get a good strategy by a process that only includes input from those who can afford a week off work and away from family or who live in europe. From what I can tell, a lot the people who go to sorrento don't even actively engage with users of plone anymore but this year I couldn't see a list of who was there.
I don't think its that hard to find ways to include input before, during and after a sprint. It would certainly increase the value of what comes out of a sprint. Pretty much the only time I can think of where someone tried to get input from the wider community was @zopyx doing an internet survey before his talk in bristol. The only time I've seen a serious attempt at involving remote sprinters was the APAC sprint where teams used hangouts with screen-sharing enabled the whole time.
It's also important to not presume to know the answers but actually research what the needs of the community are. To ask.
Great. A good place to start would be to find out who wrote this and how Plone seems to not really have a key differentiator other than being harder than others to host and "good security record" (which isn't a differentiator).
let me ask this again:
other important stuff that needs to be addressed:
- deprecation and removal of portal_view_customizations as it can lead to broken sites (according to the 2015 Strategic Summit Summary)
- we need a canonical way of getting metadata from content to avoid repeating code all over the place (for instance, to discover if a piece of content has a lead image, to get the URL of it, etc.), plone.api?
I actually think that this echos the messages that we've put out there.
Three of the five things emphasized on plone.com were addressed to some extent:
- enterprise integration (they did address integration)
- industrial strength security (they addressed this)
- limitless extensibility (they did mention the fact that it isn't average and can address multiple purposes)
What wasn't captured in the write up was
- flexible workflows
- robust scalability
I think they were pretty accurate, stating 512MB being the baseline for Plone hosting.
I feel like we're almost there with a trivial deployment story, it could be achieved with a tiny layer on top of ansible.
We did a Foundation membership survey I think in 2015 to try to determine overall strategy.
This discussion is also a mechanism for obtaining feedback on the discussion questions. Nothing is set in stone, certainly not in the roadmap. The results of PLOG discussions are always posted with the intent of getting feedback.