Collections are hard to explain in user trainings. In most cases you have to explain default pages first. Can we make this simpler? In Volto we do this by having folderish pages.

What if we kill all content types, and rely on one content type to rule them all? Confession: I actually voted against folderish pages in the Framework Team twice. So I was sceptical. With Volto we thought, let's give it a try, and we got overwhelmingly positive feedback. It avoids cognitive overhead.

Same with the Save button. Pastanaga puts this in the top left corner of the page, and I hated it. Then I actually tried it for 30 seconds and loved it.

Composite pages. The idea has been around for ages, and there have been lots of add-ons that do this, but it was never really good enough for core. Always a problem for migration.

Naming things. Some names are open for discussion. We renamed tiles to blocks. We renamed proxy to teaser. Topics, Smart Folders, Collections: in Volto we simply call this Listings.

I rediscovered a blog by Alexander Limi, one of the original creators of Plone: https://limi.net/things-plone Still an interesting list after all these years. And I recognize parts in the Pastanaga UI.

Plone in 2019 is tiny. This means we cannot afford to reinvent the wheel over and over again. So Volto builds on React, which has far more contributors. We tried Angular and Vue too, but React seems the best system. And we use the standard stack with React, Redux, Semantic UI. This will be very familiar to most React developers.

We have trained people with zero experience in html and css, and in three days they could basically theme a Plone Site, even though we only started talking about Plone and Volto in the last two hours of the last day. It was really amazing.

With Plone 6 we aim to simplify the stack. There are several PLIPs (PLone Improvement Proposals), like having the Plone Site root be a dexterity item. Most of these are optional, they would be nice to have for cleaning things up, but they are not strictly necessary. You can use "Plone 6" today:

• Plone 5.2
• Python 3
• Volto 4

Carrot and stick: selling a Plone upgrade just because you get Python 3, and not the unsupported Python 2 (stick), may not be enough to convince your customer. As extra carrot you can say: you can have Volto.

You can try Volto out live: https://volto.kitconcept.com (Still Volto 3 at this point.) This weekend, come join the code sprint at the conference.

The upgrade-step:directory ZCML directive allows us to use a new upgrade step definition syntax. Less room for typos. Upgrades in the given directory are auto-discovered. Each directory is a generic setup upgrade profile. You no longer need a profile version in metadata.xml.

With the bin/upgrade command you can upgrade your Plone site, install an add-on, upgrade an add-on. This includes progress logging, so you see that something happens during long upgrade steps.

Why do we write upgrades? We want to consistently alter content and configuration. Prevent undocumented changes through the Plone UI: your policy package should have the needed configuration, without relying on manual changes done on the live site. We want to apply a minimal set of changes, instead of reinstalling an add-on.

We have several helpers methods, for example for:

• class migration and in-place migration
• rebuild, add, remove indexes
• update object or workflow security

And there is much more, like deferrable upgrade steps, possible because we separately track which upgrade steps have been executed.

We are working on getting it running on Plone 5.2.

Code: https://github.com/4teamwork/ftw.upgrade

My first Plone conference was in Vienna. Glad to be here now.

Everything begins in ancient Babylonia. They had problems like measuring the size of fields after a flood. So they developed geometry (in Egypt too). They had to solve quadratic equations, like this:

a*x*x + b*x + c = 0

They used a different formula than what we are used to, because they had difficulty with the concept of negative numbers: you cannot have a field with a length of minus one meter.

This is basically software engineering, right?

Fast forward to the Renaissance. It is the year 1494, and Luca Pacioli publishes a book on mathematics. He said that the cubic equation (similar to the last, but raising to the third power) would probably never have a general solution. He was wrong. I show you a solution in Python, taken from Wikipedia.

Scipione dal Ferro found a solution a few years later. He seems to have come up with an algorithm to calculate it. Start with a formula, turn this into a series of instructions, and you have an algorithm.

Enter Gerolamo Cardano, Niccolo Tartaglia, and Lodovico Ferrari, all from the sixteenth century. Tartaglia also found a solution, shared it secretly with Cardano, who taught it to his student Ferrari. Cardano found the original solution from Dal Ferro, thought himself no longer sworn to secrecy, and eventually published the solution with Ferrari, together with a solution for the quadratic equation. Tartaglia (nickname for stutterer) became an enemy, and they fought mathematical battles, and we have some papers from this.

When you calculate with cubic roots, part of the solution uses the square root of minus one. At the time this was garbage. Currently we know this as an imaginary number. So it raised questions, which were finally answered two centuries later by Lagrange, Gauss, Ruffini, and Abel, between 1770 and 1826.

Why did this take so long? They lacked the abstractions needed to move forward. Babylonians did not know how to deal with negative numbers. Dal Ferro and company did not know how to deal with imaginary or complex numbers.

Moving forward. Is there a field where the lack of abstractions is preventing progress. I think yes, and it is called software engineering.

• How do we specify what a software should and should not do?
• How do we validate the behavior of code we write?
• How do we describe our architectures?

The answer is currently text: sentences, diagrams, graphs.

The history of the discovery of the mathematical solutions was a tale to tell that in science, progress usually stalls until we are able to go from one language to another. In software, of course there are new programming languages, but I don't mean that.

The Agile Manifesto tells fruitful and interesting things, and gives important results. But it does not improve how we do the software thing.

Software has built a different world, just for example the internet. It should also be a better world. Privacy is going down, are we building a police world, without intending to?

We need a quest to find a better theory of software.

Panel with Paul Roeland, Philip Bauer, Timo Stollenwerk, Asko Soukka, Kim Paulissen. Panel chaired by Tim Nguyen.

This panel is not about Plone 6, but about what happens after: what could be in Plone 7, without thinking about limits.

What would you like to see as the biggest changes in Plone 7?

• Some sort of machine learning, for example to provide tags for all images. Important for accessibility. The same for giving keywords.
• Scheduling that works. Press release to go out at 9.00 on Monday should not be visible even when you know the url, which is what happens now.
• Reliable intelligent pasting from Word and email.
• Get rid of lots of old cruft in Plone. Not have so many ways to do the same thing. No more browser views, because we have a REST API and front end.
• Get rid of the server rendered interface. Move all Plone UI to the ZMI, for admins who know what they are doing.
• Make it easy for users to customize things without knowing Python.
• Get rid of ZODB, ZMI, pickles, GenericSetup.
• More Python, not too many different technologies.
• Make Plone friendlier for smaller websites. Custom easy themes.
• A form editor that can easily be reused as schema editor. Export as json schemata, and the Python schemas.
• Customization is really hard. We had Products.Gloworm a long time ago. Click on a part of the site, and it shows you where it comes from, and allows you to customize it. This would make the first step of customizing easier.

What are the main pain points you have with Plone today?

• When you create a new content type, and you add it to your site, it does not show up in the navigation. We should fix this. It bothers me that no one created an issue for that. We have a smart community, but people think that things have been decided by a secret committee, and there must be a good reason for it, so they never question it. Usually decisions are made five minutes before a final release, so it may not be the best solution.
• The byline: I don't want the author to show, and you can switch this off, but it always shows somewhere.
• Language and date/time notation should not be linked.
• Accessibility should be more enforceable.
• The entire front end stack: that is why we wrote Volto.
• Behaviors: how we structure behaviors is done differently in Guillotina. We have lots of layers of flexibility, which is good, but also too much. At some point we have to take a step back.
• I hate our TinyMCE link dialog.
• Sane key bindings please, like CTRL-Enter to save the page.

What makes you envious when you look at other systems?

• I regularly use the web forms from Drupal. Immensely powerful and user friendly.
• Castle CMS has content quality checks.
• Doing migrations is hard, so I am envious about systems that don't care about their users. I am joking.
• Speed of GatsbyJS
• Stability of Guillotina
• Quick-start documentation. Short screen casts.

How can we remain approachable for enthusiasts?

• Django had a perfect introduction. We need people that grow up with Plone. Easy tools to get your content in and out: we have those ways, but can be improved and documented more clearly.
• For beginners it is hard to install add-ons. Buildout is new to them. Installing add-ons in a live site would be helpful.
• Our developer team got energy from using the latest front end technologies. Keep up with the pace.
• The feeling of the Plone community is very good. We try to do that for React as well. Building a community is incredibly important. Plone can give this to the JavaScript communities.

What will our theming story be? Will everything need to be done through Volto, and where will that leave Diazo.

• Technically you can still use Diazo. With or without Diazo, theming has basically taken the same amount of time. Diazo gets you in the right direction faster, but you still need to do more.
• Keep things simple: don't create and maintain our own difficult tooling. Volto builds on React and Semantic UI, who did the heavy lifting.
• Plone is a do-ocracy: do what you want, you can use and improve Diazo.
• For non-programmers, Diazo is still hard.

When will Plone drop server side rendering?

• We have server side rendering of JavaScript. But I guess the question means Page Templates.
• Plone 6 will keep the classic UI fully functional, is the plan.
• After that, we can decide what to do. We could reduce two thirds of our code if we drop it.
• It hurt when we moved to Python 3, because it was a lot of code. Currently it does not really hurt. But we can propose to remove it.
• For Plone 6 we can say that PLIPs do not need to have traditional Page Templates.

How much of the REST API would Django CMS need to implement before we can call it Plone?

• If the API contract is implemented 100 percent, then I don't care whether it is Django or Plone.
• 180 percent, because Plone is also add-ons. Or 240 percent, because Plone is also the community.
• Guillotina could replace Plone eventually. Django is just really different, making it hard to match the API.

How will Plone run 30 percent of sites on the Internet. In other words, how would Plone recapture mind share?

• I refuse to discuss marketing in a bigger group than two.
• Be better at introducing new types of developers to Plone. One for Python developers, one for React developers, for tinkerers, for users, etcetera. Make it easier to get into, and to grow.
• Have plone.io website where people can try out Plone, deploy small sites.
• Reaction to Volto was overwhelmingly positive.
• Creating custom content types is really important for a CMS now. If we can provide that in an easy way, that really helps. People create things of which I think: Why are you doing this, Plone does that out of the box.

If you have improvement ideas, please do not suffer in silence. Talk with people, create a PLIP issue.