Plone Governance Process 2020

Rethinking the structures of the community

The Plone Foundation Board of Directors, July 2020

Introduction

The Plone Foundation Board of Directors calls for a proposal to update the current Plone organizational structure to serve the needs of existing and new projects/teams. As the Board we are here to protect and secure Plone.

Disclaimer: We are not addressing any technical issues, code or tools here. This is about us as the community of Plone. We know - since we are mostly technical people - it is difficult to keep the technical part away. Please stay focused.

Problems

Plone is both growing and shrinking.

Structures from the past

Plone has been growing in the number of projects, and so in the number of people. The Plone Foundation has become an umbrella for several projects. While in the past we were one project - Plone - we are now Zope, Plone, Volto and Guillotina. While the Plone Foundation in its base is very flexible, our current organizational structures were once created for one project. Unfortunately, these do not work as well for multiple projects. Recently, valid complaints and questions were raised and those need to be addressed. 

Decision making

We have received concerns about how the framework team is created, as the members are not elected, but assigned by other team members. Questions have come up about naming of projects, like is it a good idea to refer to Volto as "VoltoCMS"? Who makes those decisions? Another one is about the priority of projects, like Volto first vs. both Plone core and Volto at the same level.

New unofficial ad-hoc structures

Where is Zope located in the Foundation and who is responsible for what? Are there unofficial structures formed around Volto or RestAPI?  How are decisions made and communicated? Who is the Guillotina project, where are they communicating? There is an initiative to form a Plone Core Roadmap team, what is behind this?

All these new and upcoming structures are not official and often not well communicated. While it is greatly appreciated that people care enough and take initiative, we do need to make sure that these initiatives remain transparent and accountable, and are coordinating with the other teams.

Adapt to shrinking and growing community

We are shrinking in the number of people involved in Plone, the core project (mostly server side logic and UI). However, there is still a large active group pushing the core project further. 

New community members are attracted by new shiny technologies in growing numbers. We need to adapt to be welcoming to these changes while also not leaving anyone behind.

Branding lost focus.

In the past there was a stereo focus on “Plone, the product” and “Plone, the framework”. Today there is also “Plone, the API” (aka Plone IO, Plone headless or RestAPI). Additionally we have Volto as “Plone, the UI”.

Then we have Zope, the Application Server, also known as the foundation we're built upon. Not to forget the spin-off, Guillotina, the modern, shiny backend with RestAPI compatibility. 

But we do have a brand: Plone. It would be a waste not to use it.

Do-ocracy: both a good thing and a problem

Many decisions in the Plone community are made on the basis of being a “do-ocracy”. In one way this is good: the people actually having an interest in further development are taking initiative. And we do have a long-lasting, close-knit and very knowledgeable community. 

On the other hand, this can lead to a lack of transparency, and more difficulty in on-boarding newer community members. It can also lead to less influence by people who are systemically disadvantaged and therefore less articulate and outspoken in the traditional developer sphere; from varying cultural, linguistic, gender backgrounds or any other kinds of underrepresented people.

Description of the status quo

History helps to classify things better.

A rough history of the current structures

Plone was created by Alan Runyan and Alex Limi starting in 1999. They published Plone, established a very open development process, and release 1.0 was already a community effort. Once accepted as contributor, pushing directly to VCS main branches was fine. Sprints, a concept taken from the Zope community, were organized around the world. Alan and Limi were our stereo dictators - they decided on larger changes. A culture that may be described as a type of "do-ocracy" was established.

After some years the community grew. New structures were established by Alan, Limi and the community leaders. 

After version 2 was released in 2004, the Plone Foundation was established as we know it: The board of directors with its goal to protect and safeguard Plone; the merit based membership; the culture of teams was established. The stereo dictators passed their power of decision making to the framework team led by a release manager. The security and marketing teams were founded. 

Even in the past it was a community experiment. At this time it worked mostly well. Overall Plone grew - the community in numbers, the product and the framework in features. And we reinvented parts of Plone in more modern ways. 

We never touched these structures - they worked for us, so why should we? 

In recent years

Plone the community changed in the last few years. We have Plone, the product and framework (now called "the core"). 

The Zope community joined us - with its own culture of development and decision making - and lives under the legal umbrella of the Plone Foundation.

One group of innovators took the best of Plone's ideas, thought ahead, and created a new application server called Guillotina - and a sub-community was created, too. 

Another group of innovators created a RESTful API securely exposing almost all features of Plone, kept in sync with Guillotina’s API. Headless Plone was born: Plone, the API. Again, a sub-community was born.

With the headless Plone new "heads" (front-ends) were invented: Modern JavaScript-based front-ends, using Angular and ReactJS. Eventually, more time and people went into the ReactJS project now called Volto. Another sub-community was born, the first to have new people not coming from the Python community; those used to different community cultures - if to any community at all.

Teams

We have many teams. It is easy to form a team. Creating teams became an established way to work together towards a goal.  Most of the time this worked well. There are basic guidelines on how to form a team. There are active teams, like framework, security, AI, marketing, etc.

The downside: We have several inactive teams, teams with lots of inactive members, one-/two-person teams or a few members who are active in multiple teams. The latter often results in lost focus, not enough resources, and sometimes too much influence.

Often the team's work lacks transparency, the unwritten rule to regularly report the outcome of meetings to community.plone.org is only followed by very few teams.

The communication between the active teams is also not transparent. While there are meetings by the team leads, the outcome is not communicated.

We also have an issue with the "non-developer" teams. We need more people-power for the Documentation and A11Y (accessibility) teams, for instance. These are not the most visible teams, and they do not have enough people. Plus, the people working in these teams require more support from the developer community.

Release Management

We have official release managers for Plone core and Zope, two for each. 

Volto is released by the driving company behind it. The plone.restapi - even if part of core - follows its own release cycle bound to Volto. While Volto has a faster pace than Plone core, it’s bound to its features and changes. This resulted in conflicts of interest. Here we need a process for solving those kinds of problems.

Guillotina is a project on its own released by its creators. 

Off-the-record

In the do-ocracy sense, a lot of decisions are made off-the-record by those who do the actual work on the code. While it pushes the Plone universe forward in one way or the other, a lot of stakeholders - like the users of Plone - are not heard.

Rethinking the structures of the community

The Plone Foundation is a flexible vehicle made for the future of our community. 

Without offering a solution here we are asking the community for ideas for a better process.

Since this is a process, we decided to start with two actions, with more to follow based on discussions. 

1. Introducing the Steering Circle

We introduce the new Plone Steering Circle. It is organized by the Board, and invitations will be sent out by the Foundation's President. Having a meeting every two months ensures everyone is on the same page. First meeting - to be announced in detail soon - will be in September.

Each team and the board sends one or two members to the meeting, avoiding having one person be representative for more than one team (if possible). Unofficial teams (those not yet on plone.org/community), like Zope, Volto, RestAPI and Guillotina are invited too. In the past we had team leader meetings, and this is its successor. The new Plone Steering Circle is more open, so also non-team people can request to be invited. 

Each team will be required to send a representative, but it can be a different person each time. If a team is consistently unable to send a representative, it is a sign of an inactive team.

The Steering Circle will have a process for setting an agenda, and will take minutes that will be posted community.plone.org.

Agenda topics may include: short two-minute reports of the team activities, coordination between the teams, discussions on questions from community members with the goal of an official answer if possible, open discussions, and organizational topics. Having an agenda helps us to focus and not waste time and - together with the minutes - to communicate openly what is going on.

2. Open Organizational Discussions 

Starting with the November 2020 Plone conference, the Board plans to set up a series of open discussions about the organizational structures of Plone - including all the projects under its umbrella. To keep it open we will make sure to have virtual participation possible. Details are to be defined together with the Steering Circle.