Manual QA: install prereleases when Eric Steele announces them? Partially. Also: make sure people other than consultants can use it, so having updated documentation, if only a note that most add-ons have not been updated yet.

We had a Launch Team, with representative of other teams. Can we turn that into a QA team? Meeting say once a month, coordinating, checking if existing teams can handle things.

Isn't it then a Process Team? Another layer. Multiadapter.

Sounds a bit like a daily executive team.

No, the release team may say we are ready for a release. But then we need to check with other teams. The technical side has a process, but the non-technical side not really. With Plone 5 a lot of technical stuff has happening and the non-technical side was rushing along trying to catch up.

The hotfix was there, the community was informed. But then there were updates to the hotfix and the communications team was not informed.

For releasing, we may start doing real alpha, beta, release candidate releases, and then do an actual final release with only a version number change. That may also give you time to update other parts, like communication and docs. And you can tell the release team to hold off. For docs, we need to include the latest stuff, even if it is automatically, but we need a moment to check it.

Problem is when technical is moving along fast and other teams cannot catch up. Technical is used to just pushing on regardless.

Have email addresses for teams.

Changelogs: declare if something is a bug fix or feature or something else. Check this automatically if possible, see if it is declared. Have best practices. Have a CONTRIBUTING.rst file in each repo: this automatically ends up on github when creating an issue or pull request.

Make it visible if all teams are ready, whether manual or automatic.

For major releases, you can prepare better, because there should be plips.

What checklists do we need?

Communications team:

• Input: changelog, the interesting 'cherries'. Saying how to get to the new features (go here, check this box). For changes: is it a feature, a bug fix, is it for developers or end-users.
• Output: news item, newsletter, social media, progress report, update feature list on plone.com. What's in it for end-users, developers, that decides what output we need. How are the changes significant.

Everyone is welcome, only members of the Plone Foundation can vote.

There is a report of the last year. Together with other documentation, see https://plone.org/foundation/meetings/membership/2015-membership-meeting

Thank you to the membership committee, ambassadors, Google Summer of Code, including talk of student Prakhar Joshi today.

Some activities this year: Plone Symposium Tokyo, Strategic Summit Sorrento. Sprints funded: FourDigits Anniversary Sprint, Munich Theming Sprint. There were lots more sprints.

Launch of http://plone.com. Many thanks to many people!

We were present in PyCon, EuroPython. Hardly any marketing money applied there, more guerilla marketing, with lots of T-shirts at the right time.

Plone 5 launch, which we had nothing to do with, except that we launched a Launch Team for issues that are not code related. Much better than the Plone 4 release which was basically dumping a tarball on the website. Thanks!

CMS Garden Brochure with a section on Plone, working together with other open source CMSes. We are not each others enemies, we have other fish to fry. Thanks Maik, Armin, Christina.

Relicensing of Mockup to BSD.

Trademarks renewed or reissued, for another ten years.

New foundation members: Kees Hink, Sally Kleinfeldt, Guido Stevens, Alin Voinea, Christina McNeill, Peter Holzer, K K Dhanesh, Fred van Dijk, Roel Bruggink, William Fennie, Cris Ewing. You are very welcome to nominate yourself for membership, don't be shy, no impostor syndrome please. :-)

Nathan van Gheem is representative on TinyMCE user advisory board. OSI membership. Social media support by Christina.

Thank you to all our sponsors. New: university sponsors. The first is the University of Namur, Belgium.

Financial balance: we are more or less even.

Philip Bauer moves to approve the report. Cris Ewing seconds. Everyone says aye. Report is approved.

Now a new Foundation board of directors.

Cris and Steve are leaving the board. Nominees for the next board. Existing: Kim, Alexander, Paul, Carol, Chrissy. New: Philip, Victor.

Christina moves to approve the new board. Alexander seconds. All say aye. We have a new board.

Any pressing concerns that you want to ask?

Alexander moves to adjourn the meeting, Philip seconds. All say aye.

[I missed the first lightning talks.]

bin/hostout app01 docker

I am working with Plone since 2006. Also involved in writethedocs.

I like to complain. Sometimes too picky? Working with Plone documentation I can get grumpy, sad, annoyed, angry. I will give a heavily opinionated talk. Please do not feel offended if I talk negatively about the documentation (or lack of it) of your package.

This talk is from a user point of view. You must realize that a good product is not just about the code. You look at the whole package. If the docs are broken, your product is broken.

On the Plone 5 release day, we had links to at least three different versions of Plone in the installer part. Confusing. Lots of old and not working or not checked code examples. Lots of confusing mixups between Archetypes and Dexterity. There were pending (not published) docs about theming. If you are a Plone consultant, you can find your way, or know who to ask, but as a user... No note that lots of add-ons are not working with Plone 5 yet. No note telling that some of the docs are not updated yet. The answer to a lot of questions on irc was: "The docs about X are not finished yet."

We forgot all of that, or had no time: our fault.

The technical stack is great. Plone 5 is ready as consultant-ware. For normal humans, the docs were not ready yet. Strictly spoken, we forgot to care about normal users.

You are done when it works and it is elegantly documented. Do at least something.

Documentation is marketing. It gets you new users much quicker. It can save a lot of time, effort, money.

Think about the process of documentation for your project as the true act of creation. Documentation Driven Development. I did not make this up!

1. You write Documentation.
2. You write Tests.
3. You write Code.

Simple!

You give yourself the chance to think the project through, without getting bogged down in a detail that you will rip out five minutes later.

Developer documentation is not end-user documentation.

It is much easier to write documentation at the beginning when you are still happy and excited about the project, instead of at the end when you are glad you have finally squashed most bugs and can ship it.

It is much easier to have a discussion based on something that you have written down.

Create an easy and friendly landing page. Make it easy to report a bug. Telling people to create an issue on github, is already too hard for some. We should add a link in the overview-controlpanel to docs.plone.org. Make it easy to find articles on docs.plone.org, the search is not great.

Know the audience you are writing for. Are you targeting end-users or developers. Don't assume readers have your skill set.

Always write a readme, even if it is not perfect. At least it is a starting point, and people can help you out.

Don't postpone writing docs, just add a few lines when you are coding.

Include docs testing in your CI setup. If you want to, you can even include automatic screen shots.

Configure your editor. There are plugins for editors, to check pep8, pyflakes, but also docs: ReStructuredText, spell check, maybe link checkers.

Use a git hook to check your documentation when you commit. Look at mr.butler, mr.docs. mr.docs is a Docker image with the same Sphinx setup that we use for docs.plone.org.

There is not one solution to fix it all.

Let's have an open space about improving the situation. Maybe a QA team?

And: docs or it didn't happen!

Questions?

The English of the documentation is sometimes really clear, and sometimes really complex. Simple is better, you may not even need translation then.

The new patterns have tested documentation in their Javascript. I don't think this gets included in docs.plone.org? No, it is not nearly enough. Nathan has written blog posts. The mockup documentation is not maintainable, at least it cannot be included currently, we need ReStructuredText. We are getting there, but the Javascript parts need much more work.

Patternslib has its own documentation. Do we just link to this, or do we want to include it? If it is in core, we want to include it. Patternslib documentation is in MarkDown, but that will work fine. We will have to try it and think what is in the long run most suited.

Barceloneta is a neighbourhood in Barcelona. It is also the default diazo theme in Plone 5.

Every resource has its own purpose, like scaffolding, normalizing. We have variables.plone.less that defines all the variables that we use in the theme. You can change them in the Plone UI, or on the file system.

It is based on bootstrap 3, but is not dependent on it. We took a 'photo' of bootstrap at some point, and went from there. We prepended plone- whenever possible. Oriol Marti and Albert Casado Celma helped a lot creating the Barceloneta theme. The original bootstrap resources are included on Plone.

We preserved Plone legacy classes and ids, to try not to break old themes. Things like: .portlet, .formControls are still there.

We updated breadcrumbs, images, portlets, alerts, control panels, buttons, almost everything.

New viewlet manager: plone.mainnavigation, with the folder sections in it.

We used http://fontello.com to build a customized set of icons. Used in plone bundle and Barceloneta. See Products.CMFPlone/static/fonts. Just load config.json in Fontello and start adding your own icons.

Plone Toolbar. See plone.app.layout and plone.app.contentmenu. Small changes since last year. You can change the orientation in the site control panel, so make it horizontal at the top. Do not forget to make space for the toolbar in your Diazo theme.

For the control panel we also used a Fontello font. Add a CSS class with the normalized name of your new control panel item, something like:

icon-controlpanel-FilterSettings: before {content: \e844}

Easy backend customization, by reusing Barceloneta resources. You can use the backend.xml Diazo rules and related css. In the future you can use the Plone Intranet theme switcher.

We use the new Resource Registries introduced in Plone 5. A resource is a collection of less files and javascript. So it is more like a web component for Plone.

Then you can register a bundle: a collection of resources.

You can do easy customization of ++plone++ resources. Why only allow exactly those resources and not others? I think it can be very useful.

Automatic variables:

@import url("@{mockup-patterns-select2}");

This is available for every resource, used in compilation.

You should no longer fill the javascript_head_slot or style_slot in a template, but in a view do add_resource_on_request, or add_bundle_on_request. Use this if you are going to use it just in one view.

Console script helpers:

bin/plone-compile-resources
bin/plone-generate-gruntfile

Call them with:

--site-id=myplonesite --bundle=mybundle

A pure Diazo theme is easy for a designer to jump in. Distributed through a zip file for import and export. Diazo bundles preserves this pureness. This uses new attributes for the manifest.cfg file of the theme, like enabled-bundles, tinymce-content-css, production-js.

Some best practices:

• Probably no best practices that fit every scenario.

• Reuse Barceloneta as far as you want. There is an optional Barceloneta profile to register its resources. If you want this, then in your metadata.xml add this as dependency:

  profile-plonetheme.barceloneta:registerless
  

• You are not tied to bootstrap, you can use what you want. Bootstrap is probably easier though.

• Don't be obsessed with the number of requests your site is doing: HTTP 2.0 is almost here, which helps a lot. It is still important, but it will be less so.

• Skin layers are not allowed. Okay, they are still there, but please don't use them. Use plone.resource instead.

• For overriding resources: use z3c.jbot.

• You can use the extend feature:

  .context:extend( .btn-primary) { }
  

• Adapt the grid in Diazo if you want, or via a custom transform like Mosaic is doing.

• Do not create a theme from scratch yourself, but use bobtemplates.plone. Understand the structure of the default theme.

• TinyMCE: custom generated style sheets. Define the new Diazo Tiny content specific css in manifest.cfg. TinyMCE content templates are now in core.

• You can define an nginx passthrough for static plone.resources, so ones that are ++something++. Point it to the local file system for that package, probably using collective.recipe.omelette.

Useful tools:

• Chrome reloader: Eric Brehault's button.
• ?diazo.off=1 and ?diazo.debug=1 in the url
• @@test_rendering page with the common rendering items of Plone.

TTW (Through The Web) is back. You can change the logo in the UI now. plone.app.theming has more power than ever before. It can attract new people. It is easy to do things that should be easy, so non technical people can try out Plone fast. And complex things are possible.

You can try out collective.jbot as customization story, not to be confused with z3c.jbot. Should work on Plone 5 soon, please help.

Overriding ++namespace++ would be nice, especially for sites where you have different parts that want to look slightly differently.

If five add-ons add five bundles, this may be much. We may need to find a better way for this. Also, if all those bundles depend op jQuery, you will get five big bundles, plus the default big plone one.