Minutes of Plone Steering Circle first meeting 2020-09-22

Minutes of Plone Steering Circle Meeting Sept. 22, 2020

First meeting!

Attendees (may have missed some - apologies)

Chrissy Wainwright, Maik Derstappen, Jens Vagelpohl, Timo Stollenwerk, Alexander Loechel, Eric Bréhault, Eric Steele, Jens Klein, Kim Paulissen, Maurits Van Rees, Michael Howitz, Paul Roeland, Philip Bauer, Ramon Navarro Bosch, Rikupekka Oksanen, Rob Porter, Sally Kleinfeldt, Stefan Antonelli, Sven Strack, Victor Fernandez de Alba, Vincent Fretin, Erico Andrei, Kim Nguyen

Minutes by Kim Nguyen, with notes from Sally

  • Chrissy: we will meet once every other month and will last one hour. It’s about coordination between teams, creation of new teams, retirement of teams, similar to the old team leader meeting led by Eric Steele, checking we’re not blocked, remind us what we’re trying to do. There should be a representative from each team, not necessarily the team lead but maybe the same person. There will be an agenda before each meeting. The community is welcome as long as we stick to the agenda. Minutes will be published on the forum https://community.plone.org

Zope team

  • Jens Vagelpohl had concerns about expectations of the Zope team, which uses GitHub to track issues and does not have formal or regular meetings and would like not to have a public channel become a place for support requests. After Zope 5 release it will go into maintenance mode.
  • Philip: no formal meetings are required.
  • Alexander: these meetings and structure are useful for onboarding new members, could help attract people to Zope.
  • Jens Klein: more transparent communication will help surface what’s going on. We are four groups now! Plone, Zope, Guillotina, Volto. We need team communications when things are in flux, but if Zope is currently stable and in maintenance mode there won't be so much need for cross team communications.

Updating the teams list

  • Jens Klein: there should be information on how to form a team, updated info on each team on plone.org/community, including the team leader for each team. Are there any teams to remove? This should be a regular part of these meetings.

New core team vs framework team vs roadmap team

  • There is already an unofficial roadmap “team”.
  • Stefan Antonelli and Maik explain the Plone Core Strategic Team idea, at https://docs.google.com/document/d/1hKkxicf-W1o0hotLocD_HZ2pGIH289v1wW4kyQ1tD8Q/edit#
  • Timo: there is overlap with the framework team.
  • Jens K: there’s a need for more regular discussion on what goes into classic Plone than what is happening in the roadmap team.
  • Erico: the framework team is where decisions are made about what goes into Plone.
  • Maik: maybe we need to make the roadmap team processes more transparent. People look to the framework team on what features go in, but not where Plone goes. Who decides direction for development of the product?
  • Timo: framework team accepts PLIPs that are just proposals now, to make it easier, and makes a decision on a technical basis.
  • Kim N: maybe we can regularize the roadmap team and add members to the framework team? Rather than create a new team that will add confusion about where to ask for direction.
  • Philip: the roadmap team would meet after discussion had happened at, say, a conference. The core team doesn’t need to be formalized, but could be a meeting that replaces a sprint discussion and reports on what new ideas should be added to the roadmap.
  • Jens: what is the process for getting things into the roadmap?
  • Timo: there is generally a lack of time to finish updating the roadmap with ideas, but adding more meetings is maybe not the solution. There’s a need for people who do the actual work, who write something down that can be discussed.
  • Jens: how do we make it easier for new contributors? Maybe there are people who would step up if they knew it was needed.
  • Philip: call this new team the roadmap team? Have a well advertised first meeting, encourage people to come, update a draft of the new roadmap, submit to the board, host discussion.
  • Maik: it's important for the community to understand how things work, who makes decisions.
  • Chrissy: action item: organize a follow up meeting to decide what to do about the core team vs framework team and put out a call for new people to join in. Asking people directly individually is more effective, and would be a good way to invite people to contribute in this way. Jens to help organize follow up on this topic.

Teams discussion

  • Chrissy: we would like each team to report out. Are there any teams that are no longer active or needed or should be merged.
  • UI/UX/Usability/Volto discussion. The current state is confusing: Rob Porter is official lead but the team has had trouble getting going in the past. Volto vs UX team (Albert Casado, Timo, Victor Fernandez de Alba). Volto people (Albert, Victor) talk regularly and make decisions but this only applies to Volto. No decision.
  • Roadmap team is really an ad hoc group.
  • Kim Paulissen: forum discussion is not clear on whether a decision has been made. Where are decisions recorded?
  • Chrissy: each group should update its page regularly
  • Maik: each team should include a forum category it uses.
  • Maik: there is a small team of Germans who meet regularly about the Classic UI, they should be more public about what they're doing.
  • Timo: discussion is great but opinions can be louder than others, but in the end it’s whoever has the energy and takes action. That’s what we rely on to make progress. The decision making process based on who is loudest doesn’t help things happen. It’s a do-ocracy.
  • Chrissy: agree that we should discuss and do as much as possible in the forum, in the open.

Plone Conference 2020

Sponsorship management

  • Chrissy: we would like a trusted volunteer to take over regular sponsorship management. Please contact Kim Nguyen, who will help do knowledge transfer.

Plone 6 release timeline

  • Philip: release schedule for Plone 6 has been pushed later. We need Barceloneta LTS and other things done in addition to Volto. How do you ship Volto with the unified installer?
  • Maik: there is a group sprinting in October to work on the unified installer
  • Timo: no thought yet on how to get Volto into the unified installer

Miscellaneous

  • Philip: hi to everyone from Max Jacob, who is sprinting on Volto. He’d love us to fix self-registration in Volto!
  • Erico: when is the 5.2.2 release official? Kim: he needs to publicize it with Rikupekka’s help.
  • Erico: the Zope and Guillotina teams should send items to or ask the marketing team for help publicizing announcements or new releases.

Various updates

Next Steering Circle meeting

  • Chrissy: we will schedule the next meetings on the 3rd Tuesday of every month at this time. We acknowledge this is a hard time to meet for Plonistas in Asia and Australia.
6 Likes

4 Likes

but UX contributors don't write code so a do-ocracy favours developer friendly features where Plone is fundamentally a non-developer tool.

No one said or implied that UX contributors were expected to write code. From what I've seen, there has been occasional discussion here (and maybe in sprints) about UX but rarely has a decision come out of the discussion. Slinging ideas out there or arguing without trying to reach a decision is not the same thing. A UX team needs to try to generate ideas, foster discussion, and reach decisions. Coding isn't necessary. And coding isn't necessary for so many of these teams... their work is not about coding.

Albert never contributed any code. He just makes rock-solid and awesome UX proposals, so we find developers (me included) who are more than willing to implement his work and thoughts.

The same is true for any other development. Plone REST API would be nothing without me finding people who are willing to implement stuff that I envisioned at some point. Volto wouldn't be what it is today without Rob's boldness and vision that others took over at some point.

This is the essence of open-source IMHO. In the end we have to win people with ideas and visions. No matter if we are talking about code, UX, marketing or any other contributions.

Do-ocracy means that people have to actually invest something (time, code, whatever) and that we make decisions based on the actual investment instead of who-is-loudest in discussions.

4 Likes

Don't misunderstand me. I'm not arguing for the loudest wins.

The problem here not people trying to be loudest. It's that the no one here personally has the problems of an end user so it all seems like personal opinions that no one has a way to verify. On top of this everyone here is an expert on how to use Plone so any change is painful so why change it? We understand how it works so there is no problem that needs fixing. So for every UX proposal you get a lot of people voting for no change. So it's easiest to dismiss it since there isn't a consensus.

I am just pointing out that it is extremely hard to make UX important in open source. Not for want of trying. That is because open source is inherently a scratch your own itch, do-acracy. So a developer with an itch can propose a feature and back it up with code and that works. The framework team is full of people who are developers and they get and understand developer problems so any developer itch is going to be recognised and encouraged. But to prove there is a problem with UX that is worth the the pain of change is hard and much harder when the people judging it don't experience it.

A well funded company who can employ a UX person like albert works as a way to UX change in when its paired with the money to get the code written. But even that is not easy to do via the PLIP process. It's much easier to create an alternative brand and technology like volto than deal with the getting agreement on a UX change via the PLIP process. Volto is proof the PLIP process doesn't work for UX changes and for individual contributors trying to make UX changes.
REST API is an excellent example of a developer centric change that open source is good at.

Another perfect example is the migration issue Kim raised recently. Thats an end user problem. The conclusion of the discussion? There isn't a problem or not one we have. There's lots of options to do importing and migration and if you really don't know what you are doing then hire someone who does. I'm as guilty of this as anyone. plone.importexport is a good idea for end users and I couldn't justify the company resources to finish it because it didn't help make us money or solve our integration issues since we know how to use transmogrifier.

I'm not saying that I have a solution here. I love plones democratic ideals. But I reject the idea that a do-acrcy solves all problems. End users have no voice in Plone. First time integrators have little to no voice in Plone.

The conclusion I came to years ago was that the only way improve UX in product like Plone would be to have a BDFL who is a UX person who had the mandate and was respected and that is backed up by a company single company who could write the code. Thats the only way they could push through painful for needed changes. We used to have that. Now we don't. Even Drupal with its BDFL and huge resources in Aquia seems to suffer the some of same issues being too developer led and focusing on coder problems as this 2014 article talks about https://mikeschinkel.com/2014/the-decline-of-drupal-or-how-to-fix-drupal-8/

3 Likes

When I started the migration discussion, I hoped to draw out information and start lively debate, and although there was no decision made in that particular forum thread, I think it has already led to better understanding of the situation and it will have helped get us to an eventual decision more quickly or it will have maybe spurred someone into thinking about how to improve the situation.

Plone Foundation Code of Conduct