Part 1: Collaboration rules. I have a very large file with rules that I use for prompts. For example:

• Rule 1: documentation first. Look in the official docs.
• Rule 11: no false security. Never say "this will work" unless proven.
• Rule 10: success is functional. Claim a success ONLY when there is a fully functional, useful, tested result.
• Rule 8: Loop detection. If the AI is repeating the same pattern, stop.

Part 2: What makes a good documentation prompt?

• Context: what is this code/module/function?
• Constraints: what format/style/standards?
• Output format: docstrings? Markdown? API reference? And can you save intermediate output so you can check the reasoning afterwards?
• Verification: How to check accuracy?

Specify what kind of docs you want? "Generate API docs." "Add verbose comments." "Create an architecture overview." "Compare v1 and v2 of this API and write a migration guide."

There are some tasks an AI can confidently do. Others not. I am a newbie in Plone, and have totally relied on AI for this presentation. I have had about 4000 hours of experience in AI though. It took about 10 minutes to prepare. That it can do well.

I gave it a task: "Create an architecture overview document." This took about 20 minutes. It could then self-critique the result. Some parts it thought it had done fine. But it confessed that performance numbers were made up. It could not have done this kind of self-critique a few months ago.

A documentation workflow:

• Developer writes code and creates prompt.
• AI generates initial docs.
• Developer reviews
• Dev adds missing content.
• AI validates technical claims.

You can create (or find) prompt templates for different doc types.

To reduce hallucinations:

• Require AI to cite sources, actual lines numbers, function names.
• Ask AI to state uncertainties explicitly. It is good to be very verbose about this, be really challenging.

Key takeaways:

• AI generates structure quickly, and then humans add context.
• Follow collaboration rules to avoid loops.
• Good prompts lead to good documentation.
• Documentation as code: part of the PR process.

Closing remark:

There are different AIs out there. I am using every single one of them. They all have different personalities. It is actually addictive in the way that gaming is. You have immediate feedback, visible progress, creative problem solving, that flow state where you lose track of time. That is powerful, because it means developers will actually want to document instead of avoiding it. Just... set a timer, because you can iterate forever!

In your prompt, always start with the collaboration rules.

Yes, it is Plone. But no forms, no news items and events. We use react views: single page, speed.

We have a unified citizen portal, 'Publik', using secure authentication, via trusted national digital identity systems. Publik is a Django framework. Citizens can login for administration. They can also make suggestions to the local government.

Ideabox: citizen participation. This uses to be a Plone instance, but now a React view that is talking to the Publik app.

Are the editors happy with the new Plone? Yes, it is better than SmartWeb with Plone 4. There are some restrictions, but that is to keep the mobile experience nice, so it is good.

It is used in different municipalities. Each site has its own layout. We make a template and integration for each city.

We use the Plone restapi to get the json from the backend.

Mari: Finnish

I study Finnish language at the university here.

Today's lesson: the pivotal 'No niin' for beginners. It can mean: OK, let's go, or meh. It depends on the innotation.

Martin Peeters: Board elections

There are only two nominations for the three seats that open in the board. So no elections this year for now. But you have time until midnight to send your nomination on the website. Contact me if you need help

Erico: State of State

These are some of the talks of today:

• Keynote: State of Plone
• State of Plone 6 backend
• State of Plone restapi
• State and direction of Plone community IT

Come on, we need better talk names!

But this is a community of people who step up and actually do things. You are all invited to my talk, over here, tomorrow 3 pm, on how to create your own conference website.

Astrid: Where in the world is Plone?

When I am in Stellenbosch I sometimes wonder if other people are using Plone. I can tell you, we are not alone. [Showing some screen shots of Matomo.]

If you feel lonely, you can go to community.plone.org, join a team, go on Discord, etc. We have a monthly news letter. Please sign up!

Eric Brehault and Jakob Kahl: France to Finland by train

I went from France to Finland by train. It took 3 days. I know that I am lucky, not everyone can do that. It would have taken 3 hours by plane. But that takes a lot of carbon dioxide, so bad for the planet. So I took responsibility. And I took more Plonistas. And I am trying to plant a seed: if Eric can do that, I can too!

I created some software to show information about my travels, the route and photos. Using GitHub user content, and a Svelte frontend.

And Jakob did the same from Bonn via a different route.

Dante: Plone MCP

Let's see how much the Claude AI can do in five minutes.

MCP is Model Context Protocol. This is a protocol for an AI to interact with other systems. We have on GitHub plone/plone-mcp, very early stages. We can use this to add blocks, create pages. I have a demo which does this.

Andre: Publication with timestamp

This is about https//:deliberations.be, used by Belgian municipal governments. We added publications with ASIC timestamps. Extra behavior. This adds verification so you can check that the document is the original one. This is done with collective.timestamp.

Rikupekka and Rita: Photo competition

Just like in the Eibar conference, we want to do a photo competition. We will add a Discord channel that you can post your photos to, and we will see who gets the most thumbs up, to win a special price.

Mike Metcalfe: Finnish

I was here in Finland in 1988 for a year. I don't know many words, but I know how to pronounce them. Finnish is phonetic: if you see a letter, pronounce it Each letter has one sound, so not in English where you have 'mat' and then an extra 'e' changes how you pronounce the 'a': 'mate'. Not so in Finnish.

'ä' is pronounced as in 'hat', for example 'Jyväskylä'. 'a' is pronounced as in 'art', for example 'Asko' or 'Mari'. The 'r' in 'Rikupekka' is a rolling 'r'.

In 'Kiitos' the 'i' is long.

Sally: Add-on voting

We had an add-ons panel, and they wanted the add-ons competition back. It can be hard to start if you are not that into the community. So fill in the ballot, there will be more on the registration desk tomorrow.

This is a talk about migrating from Plone 4 to 6 with the newest toolset.

There are several challenges when doing Plone migrations:

• Highly customized source instances: custom workflow, add-ons, not all of them with versions that worked on Plone 6.
• Complex data structures. For example a Folder with a Link as default page, with pointed to some other content which meanwhile had been moved.
• Migrating Classic UI to Volto
• Also, you might be migrating from a completely different CMS to Plone.

How do we do migrations in Plone in general?

• In place migrations. Run migration steps on the source instance itself. Use the standard upgrade steps from Plone. Suitable for smaller sites with not so much complexity. Especially suitable if you do only a small Plone version update.
• Export - import migrations. You extract data from the source, transform it, and load the structure in the new site. You transform the data outside of the source instance. Suitable for all kinds of migrations. Very safe approach: only once you are sure everything is fine, do you switch over to the newly migrated site. Can be more time consuming.

Let's look at export/import, which has three parts:

• Extraction: you had collective.jsonify, transmogrifier, and now collective.exportimport and plone.exportimport.
• Transformation: transmogrifier, collective.exportimport, and new: collective.transmute.
• Load: Transmogrifier, collective.exportimport, plone.exportimport.

Transmogrifier is old, we won't talk about it now. collective.exportimport: written by Philip Bauer mostly. There is an @@export_all view, and then @@import_all to import it.

collective.transmute is a new tool. This is made to transform data from collective.exportimport to the plone.exportimport format. Potentially it can be used for other migrations as well. Highly customizable and extensible. Tested by pytest. It is standalone software with a nice CLI. No dependency on Plone packages.

Another tool: collective.html2blocks. This is a lightweight Python replacement for the JavaScript Blocks conversion tool. This is extensible and tested.

Lastly plone.exportimport. This is a stripped down version of collective.exportimport. This focuses on extract and load. No transforms. So this is best suited for importing to a Plone site with the same version.

collective.transmute is in alpha, probably a 1.0.0 release in the next weeks. Still missing quite some documentation. Test coverage needs some improvements. You can contribute with PRs, issues, docs.

We saw that cookieplone was coming up, and Docker, and as game changer uv making the installation of Python packages much faster.

With cookieplone you get a monorepo, with folders for backend, frontend, and devops. devops contains scripts to setup the server and deploy to it. Our sysadmins already had some other scripts. So we needed to integrate that.

First idea: let's fork it. Create our own copy of cookieplone. I explained this in my World Plone Day talk earlier this year. But cookieplone was changing a lot, so it was hard to keep our copy updated.

Maik Derstappen showed me copier, yet another templating language. Our idea: create a cookieplone project, and then use copier to modify it.

What about the deployment? We are on GitLab. We host our runners. We use the docker-in-docker service. We develop on a branch and create a merge request (pull request in GitHub terms). This activates a piple to check-test-and-build. When it is merged, bump the version, use release-it.

Then we create deploy keys and tokens. We give these access to private GitLab repositories. We need some changes to SSH key management in pipelines, according to our sysadmins.

For deployment on the server: we do not yet have automatic deployments. We did not want to go too fast. We are testing the current pipelines and process, see if they work properly. In the future we can think about automating deployment. We just ssh to the server, and perform some commands there with docker.

Future improvements:

• Start the docker containers and curl/wget the /ok endpoint.
• lock files for the backend, with pip/uv.