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.