Present: Alexander, Andy, Cris, Érico, Paul, Steve from the board, plus lots of foundation members.

Paul opens the meeting. Everyone is welcome, only members can vote.

Items on the agenda: the old board leaves, new board enters, annual report.

Thank you ambassadors. We had new members, let's give them an applause. Thank you sponsors. Thank you sprint organisers and sponsors. The Foundation sponsors sprints, but that is only a beginning amount to help start things off.

We made a slight loss, we are not super rich, but we are secure. We have seen that the more money we spend the more money comes in, so I recommend to continue that.

Steve moves acceptance of the annual report, Philip seconds. Motion passes unanimously.

New board: seven nominations for seven positions, so no elections needed. If you prefer elections, run for the board, we love it.

Steve moves to appoint the board. Érico seconds. Motion passes unanimously.

Thank you to the outgoing board members, Érico, Andy, Spanky.

Welcome new board members: T. Kim Nguyen, Chrissy Wainwright, and Carol Ganz, who join Paul Roeland, Alexander Loechel, Steve McMahon, and Cris Ewing.

Officers will be appointed in the board meeting next week.

Chris C. moves to adjourn the meeting, several people second. Unanimously approved. Meeting is adjourned until next year. Place is hardly a secret, but will be announced later today.

More info on the Plone Foundation can be found at https://plone.org/foundation

Led by Philip Bauer and Martin Aspeli.

Roadmap on Plone 2020 was started in Brasilia last year at the conference. Was mostly focused on underlying technology, maybe moving from Pyramid to Zope. Sparked a discussion. Finding common ground. Where do we want to be? Which Python version? Which audience? What are our key strategies to be better?

Take ten minutes, write one or two items on a sticky pad: why are we here? Why are we using Plone? Maybe because it pays the bills, maybe because it does something that no one else does.

[Maurits: 1. Professional and friendly community. 2. It is my job (that I love).]

Martin summarizes.

• Absolute number one: community.
• Learn from clever people.
• Wisdom, shared experience.
• Zope Component Architecture, technology.
• Directly usable.
• Open source managed by a foundation.
• user friendly
• jobs
• out of the box features
• Allows my customers to do more.
• Great security track record.
• I don't know yet, I am new to Plone.

So: if we are going to change Plone, can we please not mess the above up?

Critical mass: lots of people use Plone, so customers do not depend on only you: other companies can take over or assist, if needed. That is good.

Now look to the future. Write down on sticky notes: one or two things that you want to change in Plone in the next five years. Be specific, concrete.

[Maurits: less ways to do stuff, one canonical way, for example plone.api. Confusing for new (and old) developers that you can add something in a skin layer or a browser view or a utility or a tool. The move to storing every config option in the configuration registry is a good example of progress. Have a stripped down Plone with the old ways removed, though still addable as option if you include some extra packages and know what you are doing.]

Martin summarizes and we have a discussion. No one said: use Pyramid.

• Python api, one canonical way. plone.api mitigates risk. Empower people that can build such an api to get things done, instead of reaching 80 percent of a finished product.
• Javascript api, embrace javascript, REST, web service. We agree on that it is good to have a RESTful json api. Some don't care, but are not against. It will help enable new stuff.
• Improve end user experience, better portlet handling, simple, intuitive, beautiful, flexible layout editor, more UX designers in community, fix default pages. Intranet, mockup, mosaic. Target specific audiences. Already Plone is usually only one of the systems that a client is using; someone may have Wordpress as front-end and Plone that does a few pages as well, we should be a good citizen and enable that.
• Documentation and training, engage computing students, cookbook, single entry point knowledge base, standards to do certain things.
• Deployment, be on every CPanel like platform, wsgi, mr.bob template engine, improve caching performance.
• TTW theming and templating, unify theming solutions, theme editor for real use in production, TTW customization export.
• Simplify code base structure, less methods when I list the methods of an object, legacy removed, only two ways of doing things ;-), reduce number of eggs, do not break if one part breaks.
• Removing things, cpy/cpt code, remove cmf. It is possible to remove stuff, but that will break things, which means pain. How much pain can we accept? If we get the Python api correct, we will have less pain; it is a step in the journey. Irritating if for every small release a few things might break; better have more breakage in a major release, that is less problematic. Some don't do in-place migration of content with plone.app.upgrade anymore, using transmogrifier. Add-on developers: use plone.api. DeprecationWarnings: can help, but usually they are annoying and ignored until stuff really breaks. We may be able to say to add-on developers: use plone.api and we can protect you from breakage, be stronger about saying what is safe. Be clear about what the correct way is.
• Forms, merge z3c.form, or kill it.
• Motivation, less bitching, empower leaders, bring Martin and Lawrence back in the community (twice), more fundraising, help Plone companies market Plone, success stories, bring more people from broader Python community and other communities (js, wordpress, you can put Diazo in front of wordpress too), be more inside the broader Python community.
• Give Zope some love, roadmap communication.

Plone Open Garden in Sorrento next year may be a good time to have a strategic planning summit. The Plone Foundation may be able to help people get there, with travel stipends. Also: it is good to pay the foundation so they can continue to do that.

Let's continue discussion on mailing lists too. Python and JSON api seem clear winners to work on. Consensus on removing things, but there are risks. Continue the conversation on UX improvements.

This right here is the roadmap team, not some secret group. This is where Plone happens.

Can we put this somewhere in documentation? [Feel free to copy this somewhere and improve it; Maurits.] Communicate it, add a news item. Can we do that? Yes, Eric will sit down with Christina.

Can we somewhere let people vote on ideas? Not just developers here, but users everywhere, without needing to subscribe to a mailing list.

I am the founder of http://pocketspacecraft.com

I am a physicist. Working in meteorology and ocean ventilation models and tools. Voyager and ROSAT analysis. Att Imperial College. Software developer, computer scientist. Aerospace. Co created the KickSat project.

Founded in 2010, operations in China, Isle of Man, UK, US.

Space is bug and relatively unexplored. Missions are expensive and infrequent, funding is tight, missions are risk averse, it is scary to try really new ideas, processors are often ten years old because we know all the bugs there.

Goal: before I retire (say in the next 25 years) I want to send a spacecraft to orbit and/or land on the surface of 'every' body in the solar system. Every is too much, but maybe one million objects?

We need a pocket space craft, that individuals can buy. Personal space age: everyone can get involved.

We want to explore. Consumer projects: how are you going to support that, on that scale? We want instant gratification for people, but it normally takes years to get something up in the air. Work together.

Help different communities involved. If you do something good for the science community, your project may be able to get on board a mission to Mars. Lots of legal hurdles, insurance. Small space crafts, but big problems.

Video games are a good metric for this. People are prepared to pay 50 dollars for that. Lots of challenges there.

What helps, is open source. An Open Source Space System is being worked on. This is done by individuals in their spare time, but also by big names in space. Bring the International CubeSat Consortium in the mix.

Using open source actually helps against some of the legal hurdles, making you exempt from them.

The CubeSat standard defines a standard space craft. One unit is en by ten by ten centimeter, using 1 Watt, 1 kilogram. You can combine a few. About 50k dollar to launch one. That was started ten years ago. About 70 made in that time, and about 70 in the last six months. So it is being picked up. Much much more planned for next year. Launched from the international space station.

How is it possible? Moore's law. A KickSat, much smaller than CubeSat, already has more computer power than Voyager had, so don't knock it.

Standard 3 unit CubeSat launch is available today. Not tied to any launch vehicle or nation. We need to get it close to where we want to get (moon, planet). Then we deploy and do whatever we want (except introducing bacteria, so there are rules).

Pocket Spacecraft prototype, 32-96 millimeter diameter, less than 50 micrometer thick, 10-100 milligram, 5-100 MIPS, up to 100 GB storage, optical communications. Can be manually produced.

Long term goal: print space craft in space. Design your space craft, send the instructions in the direction of the printer in orbit around Mars, wait 20 to 40 minutes depending on time of year, and you can launch your space craft.

There is now Open Mission Control software, and Pocket Mission Control for your Android.

You need to be able to talk to these space craft, via ground stations. We can do that amateur radio based. See http://mygroundstations.com

But with a credit card and some convincing you can rent NASA communications by the hour and use the same stuff that still talks to Voyager, at 80 light hours distance.

But there also is the LOFAR network, for radio astronomy, which you could use to pinpoint your space craft. Lots of data, several Peta byte for 15 minutes. Expensive, but prices will drop: Moore's law again. There is an awful lot to do, but that is fine.

Where do you want to explore today?

Standards and info:

• http://cubesat.org
• http://cubesatcookbook.com

Spacecraft parts:

• http://cubesatkit.com
• http://cubesatshop.com
• http://clyde-space.com

Questions?

50 percent of CubeSats fail. But 50 percent of large space projects fail as well. Interesting, isn't it?

Space junk? We are responsible about that, making sure we do no harm, otherwise we may no longer be allowed in space.

Watch the video of this talk.

I am CTO at Six Feet Up. Doing Plone since 2003. Lineage was one of my first contributions.

Lineage is an add-on for Plone. Enabled by the pieces that are built into Plone, like INavigationRoot, IPossibleSite, together as IChildSite. So we are using the ZCA (Zope Component Architecture).

With Lineage you create one site and lots of sub sites for departments. Advantages compared to having lots of Plone sites:

• You only need to upgrade Plone once.
• You can share content among the sites. You can link to it in the TinyMCE editor.
• Performance is better: you get a smaller footprint for all sites combined.

Disadvantages:

• Want to split them up into different Plone sites? That is a bit more difficult.
• Add-ons and configuration are global, not per sub site, so your sites need to be really alike.

There are various add-ons/extensions that build on Lineage, for example lineage.themeselection for giving sub sites a different theme.

Add collective.lineage to the eggs in your buildout. Activate it in the add-ons control panel. Go to a folder, to the actions drop down and enable this folder as a sub site. Within this folder, the home will be this folder. You can add sub sites within sub sites if you want. You can exclude a sub site from navigation if you want to.

I want to show you some cool tricks you can do.

You can use custom site types. As long as they are IFolderish types, you can enable a sub site on it. At Penn State we used that to ease creating a new course.

Some add-ons:

• lineage.registry, for storing some config per site
• lineage.index: adds a separate index to the catalog per site.
• Resonate is new and does moving and syndicating to sub sites.

With Resonate it is possible to move content between sub sites, via the workflow, giving control to the content managers of the sub sites.

With Resonate you can syndicate content to various sub sites, still using standard Plone workflow machinery. A teaser of a news item can then be shown on the other sub sites, where they point to the original item, so that one remains the canonical one, which is good for SEO. The editor can see which sub sites accepted and rejected the share.

How does it perform? I set up two Zope instances, one with 100 Plone Sites, one with 1 Plone Site and 100 sub sites. Advantage of Lineage, with blank sites: about 9 MB against about 130 MB. Startup memory did not differ much, slightly better for Lineage. (Audience: may be influenced by the ZODB cache size too.)

Lineage is actually Plone 5 compatible. Version 2.0 released last night.

Code: https://pypi.python.org/pypi/collective.lineage

Example usage: http://www.la.psu.edu

For migration from the old separate sites to sub sites we used transmogrifier.

Watch the video of this talk.

This is about Plone's new front-end library. Mockup is a framework for adding Javascript functionality from other libraries to Plone. Will be part of Plone 5.

For example the 'moment' pattern:

some date

That will output a nicer date using the client browser language.

Currently, on Plone 4.3, we are still developing js as if it were 2004. 41 Javascripts registered in a default site. The resource registries have a packer functionality, with last commit from 2009. Maybe not so good anymore. No tests.

History of mockup. Based on Patternslib, created by Cornelis Kolbach and Wichert Akkerman and others in 2011. Forked by Rok Garbas in 2012, split up in Mockup and Mockup core in December 2013. plone.widgets and plone.app.widgets by Nathan van Gheem in November 2011, an attempt to bring more modern UI to Plone.

Build environment:

• Yo: used to generate base skeleton
• Grunt: comparable to buildout for js
• NPM: node package manager
• Front end: RequireJS.
• Testing: Karma, Mocha, ExpectJS/CHAI

[Showing some code.]

We made a generator for mockup:

npm install -g generator-plonemockup
yo plonemockup

Then you answer a few questions and you get a base pattern.

Now do some coding and call make and it will minify, create a bundle, etc.

There is a training that you can follow online:

http://mockup-training.readthedocs.org

Alternatives:

• Patternslib is still being developed and is of course similar to Mockup due to the shared history.
• Web components, w3c draft. Some experimental projects, Google Polymer, Mozilla X-Tags. Limited browser compatibility. Status: html templates is completed, shadow dom and html imports are in draft.
• AngularJS directives are similar to Mockup. Angular is full stack framework. It will switch to Web Components once it is ready. Hard to migrate Mockup to using AngularJS of course.

Our opinion about Mockup: great framework, big improvement to current situation, nice workflow, but uncertainty about future, maybe Angular could be better. Open space tomorrow at 11:00.

Audience: mockup (or patternslib) is an abstraction layer, Angular is something really different. Don't use Angular as base for the Plone JS. We have to get the whole community into thinking 'Javascriptish', really push it into the head of more developers. It is actually pretty easy to change a Mockup pattern into a Patternslib pattern or the other way around. Changing a date picker pattern into a different one? Not so difficult either. Not enough people are currently feeling secure developing with Mockup, but that will come.

Watch the video of this talk.