PLIPs documentation

Development Framework Team
,
1

I'm revising Implementing PLIPS — Plone Documentation v5.2 for Plone 6 and this decade in https://github.com/plone/documentation/pull/1671/conflicts.

Does the Framework Team still exist?

There's been no activity in here since Jul 2021.

There's no Discord channel for the FWT.

The PLIP GitHub project board has not been updated since Feb 1, 2022 (29 open PLIPs on the board). Yet there are 9 open PLIPs not on the board.

Volto has been generating PLIPs (26 open isses, 2 open PRs) like there's no tomorrow, and none of them are on the PLIP project board.

39 open PLIPs are in other repositories.

There's a total of 105 open PLIPs (101 issues and 4 pull requests) in various repos.

Based on this, it appears that there is no formal process or Framework Team review, and a PLIP is managed by whatever people are interested in that specific repository.

I found a PLIP template which appears to get copy-pastad into other repositories ad hoc. It has an outdated link that redirects, then 404s.

Can anyone please inform me so I can update the docs with current information? Thank you!

2

The Framework Team has not been active in the time since I returned to contributing to Plone development in June 2022. But I can't find a written record of when that decision happened or whether some replacement was planned. Maybe one of @esteele @ebrehault @alert has some insight?

The last Framework Team minutes I could find are from March 2022: FWT meeting minutes 2022-03-10

Minutes from the Volto Team meeting in February 2023 mention that the Volto Team planned to take over reviewing and deciding on PLIPs related to Volto: 2023-02-14 Volto Team Meeting Notes

This leaves things a bit up in the air for PLIPs that relate to other pieces of Plone, such as the Classic UI, the underlying framework, or functionality that touches both Classic UI and Volto. In the absence of a functioning Framework Team, I would hope for some guidance from the Steering Circle.

For me personally, regardless of what specific process we use, I think the important principles are:

  1. Someone proposing a new feature or major change to Plone ought to have a chance to get feedback on how it will be received by the community before they spend a lot of time implementing it.
  2. Major features or changes should not be accepted and merged until they've been reviewed to confirm that they are generally of high quality, minimally disruptive to existing users of Plone, and relevant to enough users of Plone to justify the ongoing maintenance burden.
  3. It's useful to the community to have a way to see what potential changes have been proposed and their current status -- but it's also hard for the developers to commit to concrete timelines or plans, since it's all volunteer labor.
1 Like
3

The framework team kind of stopped working because of lack of participation. We where often 2 or 3 people showing up in meetings, which is to little to decide anything. We tried to change the workflow to, on Github only and more async and wanted to only meet when there is a conflict, but that didn't result in getting more work done. At the end @alert quit the framework team for the reasons above.

Then also the focus area of THE framework team changed in the way, that Volto and the Rest-API where doing it's own thing anyway. So the framework team would only decide on Classic UI and backend topics.

To reflect all this movements, we kind of decided to have the Classic UI team operating the same way as the Volto team.

For the backend we would still need either a backend (framework) team or a discussions between teams when ever needed (overlab) or this could be handled by the Steering Circle.

For the Classic UI PLIP's we need to get more in a official mode, meaning living more the PLIP workflow. But we meet regularly and will work on that.

1 Like
4

I'll take all this to mean that the FWT has ceased to exist.

The Steering Circle could not take the place of the FWT. It functions primarily as a monthly stand up, not something that could review PLIPs in depth.

The Volto Team now reviews its own PLIPs, following the established process. PLIPs in CMFProducts.Plone do the same. It sounds like @MrTango will steer the Classic UI Team toward the PLIP process, but where would its PLIPs be published?

Classic UI spans several repositories, including patterns, mockup, and other repositories for Plone's backend.

I assume the default location would be in the CMFProducts.Plone repository.

I'll update the pull request according to what I think is correct. Feel free to review the open PR at integrate coredev.buildout (was PR #1670) by stevepiercy · Pull Request #1671 · plone/documentation · GitHub and provide feedback and corrections.

5

There was also a discussion about the structure of Classic UI packages and the new distribution package. One idea was to use the plone.classicui package for the distribution and move the templates to plone.app.layout instead of plone.classicui. Since there are already some templates already in plone.app.layout, we don't have to move them. But we would move the logic of some views to CMFPlone because it is used by the core and belongs there.
Regardind where to put the PLIP's for classicui, I'm fine with putting them into the plone.classicui repository.
thoughts: @mauritsvanrees @petschki @jensens ?

1 Like
6

This or a we go for labels in CMFPlone to keep things together, like drafted here

7

since the Volto team is doing it in the Volto repository, it makes more sense to also keep it separate.

1 Like
8

All PLIPs should have the label 03 type: feature (plip). If it doesn't, it ain't a PLIP.

The question is where to put a Classic UI issue labeled as a PLIP? It sounds like y'all are leaning toward plone.classicui. I'll go with that.

BTW, I just put in two PRs, one each for Volto and Products.CMFPlone, to automatically assign a PLIP issue with the PLIP label. If you have the template elsewhere, please update it.

2 Likes
9

My 2c:

I would move only and all the templates in classicui. If Volto is not using a browser view, then move that browser view to classicui too.

What is "core"? If something is not used by Volto or the next UI using restapi (and no plan to use it), can it be "core"?

If (headless and restapi-with-SSR is the_future):
    Plone_parts_used_by_Volto = core
10

This is done in the open PR. Link to preview:

Please review and provide comments in the pull request @MrTango @yurj @davisagli @jensens

If you feel ambitious, I would appreciate reviews on any other files in the migrated coredev.buildout docs.

11

Hi:

On behalf of the Foundation Board, we discussed the topic of the status of the Framework Team in one of our first meetings.

We contacted the members of the Team, but we didn't get a clear message of the status of the Team from them.

That's why we raised the topic during the Steering Circle meeting on November 2023, and discussed it later during our Board meetings on November, December and January.

We thought that establishing a Team and inviting people there for the sake of having meetings made little sense.

We informally agreed in the Steering Circle and later on the Board, that if any team had issues with others, or had some ideas for PLIPs that could potentially have impact on others, they can use the Steering Circle as a first contact point for coordination and then come to the Board if any further action or coordination was required.

Anyway, we agree that we need to rethink our previous review process (PLIP, Framework Team review, ...) of the new functionalities that we want to have in core Plone, so as a Board we think that this can be a very good topic for an Open Space or half a day discussion in the Conference.

But we also think that this needs some preparation (listing previous experiences, agenda, organizing a debate, ideas, ...) in order for that discussion to be effective.

We think that an online sprint in late September / October can help on this.

That's why we want to discuss a bit this topic during the next Steering Circle meeting (11th of July), and then make a call to everyone that want to improve our review process or has ideas to refresh our PLIP review process to help us on that sprint and later on in a discussion during the Conference.

12

@stevepiercy thank you for taking care of this crucial part of Plone development documentation! Sorry for being late on this discussion...

I am fine with delegating PLIPs to the Volto and Classic UI teams. However, some PLIPs affect both Volto and Classic UI and Plone as a whole. The crucial question is: How would we handle such PLIPs?

Here are a few ideas that have been discussed in the past:

  • we keep the FWT as it is and resurrect it, the FWT only tackles PLIPs that have consequences for both Volto and Classic UI (or the "Core" that both use)
  • we pass the responsibility for this small number of PLIPs to another group of people (e.g. the Release Managers)
  • the Volto team and the Classic UI team meet for "global" PLIPs or PLIPs that affect the other system and make a decision as the "FWT"
  • we hand over the entire responsibility of "global" PLIPs to the Volto team because this team meets regularly and is active

We would have to discuss this as a community and within the teams as @erral suggested. Preparing this decision within the teams and then agreeing on a process during the conference sounds like a sensible thing to do.

However, until we have a final decision, I'd strongly suggest keeping the current PLIP process and the "FWT" in our docs, even if this is just "a concept" for now. If needed the release managers could take care of this responsibility for the time being until we find a better solution.

The idea would be to basically say that PLIPs that affect only Volto or Classic UI should go to the individual repos and tickets shall be marked as PLIPs:

"Global" PLIPs or whenever people are unsure should go to:

We could still move PLIPs from one project to another. We could keep track of all PLIPs via the board:

I would suggest that PLIPs can only be submitted to those three repos. Otherwise it becomes hard to track.

I would be willing to step up to clean up the current list of PLIPs. Maybe the other FWT members would be willing to help here (@MrTango, @rodfersou). Anyone else who is interested is welcome too!

@sneridagh, @mauritsvanrees and I are about to finish the new roadmap document anyways, so it makes sense to me to go through the list of PLIPs.

I will have a look at the PR and I will try to find time to help there!

13

FYI: I went through all PLIPs in the PLIP board:

and moved a few PLIPs that showed no activity since years. As far as I can see we currently have no PLIPs submitted, "in process", or "under review" right now.

@stevepiercy how is this board set up? I only see one "Volto" PLIP in there. Does this mean we have to manually add PLIPs there?

Volto currently has 26 open PLIPs:

CMFPlone has 37 open PLIPs:

I am not too familiar with GitHub boards. Is is possible that we automatically list all tickets marked as PLIPs in a board?

14

This sounds perfectly reasonable. For the immediate term, I will update the PR of the docs accordingly. But I need a little help.

I couldn't find any contact information on Steering Circle. What is the official contact information for the Steering Circle?

Does the Steering Circle have a GitHub handle or team? If not, should we create one?

Should there be a category in the Community Forum for the Steering Circle?

The Steering Circle already has a private Discord channel.

All that sounds good to me. I'll update documentation as we make decisions.

1 Like
15

I disagree with the first sentence in the first paragraph. The FWT does not exist or function, and telling developers to contact /dev/null is doubleplus ungood. Victor already handles Volto PLIPs, and it sounds like Classic UI is going to do the same, but I don't know about Products.CMFPlone unless one of its release managers steps up and agrees to take on that responsibility (as if they don't have enough to do already!). @erral says go with the Steering Circle as a first point of contact. I'm going with that in the docs PR for now, until we have a chance to discuss and decide over time, and I'll update it again.

I mostly agree with the second paragraph, and I documented such in the PR. That is, except sometimes Volto and Classic UI PLIPs touch backend bits and pieces. Instead of "only" affecting a frontend, I would go with "primarily" affecting it. Is that reasonable?

Yup, that's in the PR.

I discovered it in a Community Forum post while researching the status of the FWT. Here it is:

I added the PLIPs board to the docs PR, as it seems to be the centralized location for PLIPs which replaced a Google Sheet.

I think so going forward. I updated the PLIP issue templates in Volto and Products.CMFPlone to automatically add the label 03 type: feature (plip). Example: Automatically set the label to `03 type: feature (plip)` for PLIPs by stevepiercy · Pull Request #3982 · plone/Products.CMFPlone · GitHub. And checking this GitHub help article, it is possible:

projects: "plone/47"

I'll submit another PR for that. Thanks for the idea!

I don't know about retroactively, though. You can search for all open PLIPs not in Volto and CMFProducts.Plone. Then you can go to each of the 37 PLIPs, and add them to the project board. Or if one repo has a lot of PLIPs, you can go to that repo and search for the label 03 type: feature (plip) and add them in bulk. Or someone could write a script that interacts with the GitHub API to do the same.

16

I never suggested that devs should contact /dev/null. I suggested that we find a temporary solution and a group of people that take care of those PLIPs until we discussed and found a good long-term solution.

I stepped up and said I'd be willing to help find such a solution, I added some ideas and I started to work on cleaning up the list of PLIPs. I also reached out to my release manager colleagues to find a temporary solution. I also will bring this up in the next Volto team meeting to hear their opinion.

I served on the FWT for 10 years and I honestly don't see how the steering circle could adequately handle anything related to PLIPs. When a PLIP is submitted the person who submitted the PLIP must get a reaction and a technical review. This takes time and often lots of experience and knowledge. Especially to decide if something affects Volto, Classic UI, or Plone as a whole.

17

regarding the target for core PLIP's I'm with @tisto, i would keep it targeted to @plone/framework-team and i think you merged that suggestion already.
We can then focus on finding responsible core developers who can take care of it. How we call them, does not matter. And as said, this will not be many changes. As with things like plone.distributions, it's becoming easier then ever to deploy a good set of addon's and a ready to go thing. No need to put all addon's into core. The core is getting smaller in time.

Regarding the last idea to put this into the Volto team. I don't think that's a good idea. We should have developers from all interest groups in that team.
Be it Volto, Classic UI or Quaive. We will need that for the time when we move things around to split Classic UI from core packages, so that consumers of a headless Plone don't have to carry around that baggage. For example in plone.app.layout, we will have to identify core things and move them to a better place.

2 Likes
18

@tisto @mrtango in the open PR, I committed @mrtango's suggestion to use the GitHub handle @plone/framework-team as the default. Knowing that there are at least two people monitoring it, it'll work for now. Thanks for bearing with me as I navigate through this.

I think this pull request is now ready. I'll merge it after the Volto Team meeting this Tuesday, if there are no objections.

1 Like
19

We now have contributing to Plone 6 core documentation Contribute to Plone 6 core – Contributing to Plone — Plone Documentation v6.0

2 Likes