PLIP: Extended PLIP Process for Plone #2
Description
Preamble
Motivational summary - why you should read this
Plone has reached a level of maturity where visible process is not a burden but a
form of care. A clear PLIP path helps contributors invest energy with more
confidence, helps teams decide with more legitimacy, and helps the wider
community see that important decisions are made in daylight.
The extensions proposed here are intentionally modest. They do not ask Plone to
become bureaucratic. They ask Plone to be clearer: clearer about time, clearer
about responsibility, clearer about how disagreement ends, and clearer about how
future contributors can understand the choices made today.
That kind of clarity strengthens sustainability. It also makes participation more
welcoming, because people are more likely to contribute when the path is visible
and fair. For a long-lived open source project, this is not only process work. It
is community maintenance in the best sense.
Context
This PLIP proposes a modest extension of the Plone Improvement Proposal process.
Its goal is not to replace the current PLIP model, but to make it more applicable
for a broader range of proposals and to make decisions easier to understand.
The existing PLIP process already gives Plone a strong base: a written proposal,
public review, designated teams, implementation, and final approval. This PLIP
keeps that structure. It adds a small set of visible rules for timeframes,
responsibility, discussion, voting fallback, and decision records.
The proposal is written for Plone as a meritocratic open source community. It is
therefore guided by four principles:
- keep the process lightweight
- make responsibility visible
- protect room for discussion without endless drift
- make final decisions understandable after the fact
This extension also recognises that some important Plone decisions are not only
code changes. Content, messaging, documentation, governance, design, and web
presence can also shape the project strongly. Where these topics need a formal
community path, the PLIP process can provide it if the rules are clear.
Summary
Status path:
- draft
- discussion
- proposed
- accepted or rejected
- archived
Default timeframes:
- draft: 1 week
- discussion: 4 weeks
- proposed: 1 week
These are default expectations, not rigid deadlines. A responsible team may
extend them, but should state the reason publicly.
Decision model:
- the proposer of the PLIP seeks consensus first
- the responsible team decides when the discussion window has passed and the points of disagreement are
clear - if consensus is unclear after the discussion window, the responsible team
posts a short decision summary with the open questions and may choose to extend the discussion or involve other teams for consultation - if disagreement remains material, the responsible team may reject.
- the final decision and its reasoning must be recorded in the PLIP
Minimum decision record:
- responsible team
- decision date
- outcome
- short rationale
- follow-up actions, if any
Abstract
Plone benefits from a formal proposal process for changes that affect the wider
project. The current PLIP process already supports major technical proposals, but
it leaves some practical questions open: how long review phases should last, who
decides when several groups are affected, when voting is appropriate, how to
record dissent, and how the process should work for proposals outside core code.
This PLIP introduces a lightweight extension to the current process. It defines
default timeframes, makes the responsible decision-making team explicit, and adds
clear fallback rules for unresolved disagreement. It also broadens the process so
that Plone can use one familiar framework for development, process,
documentation, content, design, and governance proposals when the impact is wide
enough to justify it.
The extension is intentionally modest. It does not add a new governance body. It
does not require votes for proposals. It does not reduce the authority of
existing teams in their own domains. Instead, it clarifies when a team decides,
when it should consult others, when a proposal should be paused, and how the
community can understand the path from proposal to outcome.
The expected result is a process that remains friendly to contributors while
making decisions more transparent, more timely, and easier to trust.
Motivation
Plone has strong community traditions, but informal clarity does not always
scale. When proposals touch broad questions such as project direction, public
messaging, user experience, or governance, uncertainty about the process can
create unnecessary friction.
Several problems follow from that uncertainty:
- discussions can continue without a clear sense of when a decision is expected
- discussions can derail and drift away from the core question
- contributors may not know which team has the mandate to decide
- different participants may assume different standards for consensus
- disagreements can become personal because the decision path is unclear
- later readers may see the outcome, but not the reasoning that led to it
This matters for both contributor trust and project sustainability. A community
is more resilient when people know where ideas can be proposed, how feedback is
handled, who carries responsibility, and how disagreement can end without damage
to relationships.
The motivation for this PLIP is therefore simple: preserve the openness of the
current process while making it easier for contributors and teams to navigate.
The extension should reduce confusion, not increase ceremony.
Assumptions
- Plone works best when important changes are discussed in public and decided in
a visible way. - Consensus should remain the preferred way to reach decisions, because it
supports cooperation and shared ownership. - Consensus alone is not always enough; the process needs a clear fallback for
cases where disagreement remains after good-faith discussion. - Different proposal types need slightly different review perspectives, but
they can still share one common process framework. - Existing teams should keep domain responsibility wherever possible.
- A lightweight process is more likely to be used consistently than a complex
one. - Timeframes help communities focus attention, but they must remain adjustable
when justified. - Written decision records strengthen trust, reduce repeated debates, and make
future governance easier. - Non-code contributors should be able to understand and use the process.
- Plone should avoid both extremes: informal ambiguity on one side and heavy
bureaucracy on the other.
Proposal & Implementation
1. Extend the scope of PLIPs
This extended form of a PLIP can be chosen freely by the proposer of the PLIP. It is not compulsory for all proposals.
It is intended for proposals that:
- have a significant impact on the project as a whole
- may attract a lot of interest and discussion
- may require cross-team consultation
- may be time sensitive
Examples:
- a proposal to change the plone.org homepage content and design
- a proposal to change the project’s code of conduct
- a proposal to change the project’s governance structure
- a proposal to change the project’s release process
- a proposal to change the project’s public messaging strategy
2. Add a default status model with timeframes
The following status path should be used:
- draft
- discussion
- proposed
- accepted or rejected
- archived
The following default durations should be published in each PLIP summary:
- draft: 1 week
- discussion: 4 weeks
- proposed: 1 week
Meaning of the phases:
- draft: the proposal is visible and may still be shaped substantially
- discussion: feedback is actively sought and major objections should be raised
- proposed: the responsible team believes the proposal is ready for a decision and will no longer be amended.
- accepted or rejected: the decision has been made and recorded
- archived: the proposal is closed and retained for reference
These durations are defaults. The responsible team may shorten or extend them
when the reason is stated in the PLIP. For example, urgent technical matters may
need a shorter path, while broad governance proposals may need longer discussion.
Commentary on timeframes
Default timeframes are useful because they create a shared expectation without
forcing artificial speed. They make it easier for contributors to know when to
comment, for teams to plan review effort, and for proposers to avoid the feeling
that a proposal has disappeared into silence.
The main benefit is not speed, but reliability. A visible rhythm lowers stress
and reduces repeated follow-up questions.
The drawback is that some readers may interpret defaults as deadlines. That can
be avoided if the documentation says clearly that extensions are normal when the
topic is broad or the responsible team needs more consultation.
3. Name the responsible team at the start
Every PLIP should name a responsible team or decision-making group at the time of
submission. If the proposal affects several domains, one team should be named as
the lead and other teams should be listed as required consultees.
The chosen team should accept to take their side of the responsibility for the proposal. (Teams do not have to participate in any PLIP raised).
If responsibility is unclear, the default escalation path should be:
- first, the most relevant designated team
- second, the Steering Circle or equivalent coordinating body
- third, the Foundation Board only when the matter concerns Foundation mandate,
legal stewardship, trademarks, or financial responsibility
This keeps decisions close to the relevant expertise while still providing a
clear path for cross-cutting questions.
Commentary on naming the responsible team
This is one of the most useful extensions. Many process conflicts are not really
about the proposal itself, but about uncertainty over who has the mandate to
decide. Naming the responsible team early reduces that ambiguity.
The benefit is clarity. The possible drawback is that a team may be seen as too
powerful if its role is not balanced by consultation duties and escalation rules.
That is why the lead-team plus consultees model is helpful.
4. Require a public discussion link and announcement path
Each PLIP should include:
- the main place for discussion (either on the issue or in a forum)
- the announcement channel used
- the responsible team
- the intended decision date window
- the current status it is in
The discussion should happen in a public forum wherever possible. If private
consultation is needed for legal, personnel, or security reasons, the public
record should still note that consultation happened and what part of the topic it
covered.
5. Define a consensus-first, team-decision-second decision rule
The responsible team should aim to decide by consensus. Team-decision should only be
used when:
- the discussion window has passed
- the points of disagreement are clear
- the responsible team concludes that further discussion is unlikely to produce
convergence in a reasonable time
Before a team-decision happens, the responsible team should post a short summary covering:
- the proposal under decision
- the main arguments in favour
- the main objections
- any alternative options still under consideration
- the exact question to be decided
This summary reduces confusion and helps the team-decision address the real disagreement.
Commentary on voting and decision making
The proposal treats voting as a last resort. This is important. Open source
communities are usually healthiest when consensus is preferred and votes are rare.
Votes settle questions, but they rarely create enthusiasm. A good process uses
them only when discussion has done its work and the remaining disagreement is
clear.
The benefit of a voting fallback is that the project is not trapped by endless
debate. The drawback is that, if used too early, voting can harden positions and
turn a design or governance question into a camp-based contest.
For that reason, the summary-before-vote rule matters. It slows the jump to a
vote just enough to ensure that the real choice is understood.
6. No further decision-making regulation at this point
This PLIP deliberately stops here and does not regulate more, even though there are examples and
possibilities in the world that could be useful for Plone. For example, it does not define a voting method, a conflict resolution process, or a proposal shepherd role. The reason is that the extensions proposed so far are already a significant change to the current process by focussing on transparency and it is important to see how they work in practice before adding more complexity.
7. Require reasoned objections (Constructive Transparency)
A binding negative decision should include:
- the main reason for objection
- whether the objection is blocking in principle or conditional
- if possible, an alternative option or a condition for acceptance
This encourages constructive participation and makes it easier to improve a
proposal rather than merely stop it.
8. Add inactivity and withdrawal rules
A PLIP may be moved to archived if:
- the proposer does not respond for 30 days during an active phase, or
- the responsible team states that the proposal no longer has an active path
A proposer may withdraw a PLIP at any time. If a proposal is withdrawn or
archived, a short explanation should be added so future contributors understand
what happened.
Note: The current process already mentions this implicitly, but making it explicit helps reduce confusion about what happens to proposals that do not progress. (see Process Overview)
Commentary on inactivity and withdrawal rules
Inactive proposals consume attention and create confusion. A clear withdrawal and archival rule
keeps the proposal space healthy and honest.
The benefit is that contributors can see which proposals are active and which are
historical. The drawback is that some valuable ideas may be archived simply
because the proposer lacked time. This is acceptable if archived PLIPs remain
easy to revive by a new proposer.
9. Add a short post-decision record
When a PLIP is accepted or rejected, the final update should include:
- decision date
- decision makers
- decision method
- result
- short rationale
- dissent summary, if relevant
- next step
This is not extra bureaucracy. It is a compact historical record that helps
future contributors understand why the project chose a given path.
Risks
- The process may be perceived as more formal than before, especially by casual
contributors. - Default timeframes may be misunderstood as mandatory even when a topic needs
more time. - Non-code PLIPs may increase the number of proposals if the threshold for using
them is not explained clearly. - If responsibility is assigned poorly, the process may create confusion instead
of reducing it.
These risks are real, but manageable. The extension should therefore be adopted
with clear guidance that:
- consensus remains the preferred path
- timeframes are defaults, not rigid limits
- not every issue needs a PLIP
- the purpose is clarity, not procedural weight
- choosing this extended PLIP path is optional and should be chosen in agreement with the team
Participants
- Proposer: Alexander Pilz
- Seconder:
- Suggested review participants:
- representatives of the Volto Team where relevant
- representatives of the Marketing Team for content and messaging scope
- members of the Steering Circle or equivalent coordinating body
- Foundation Board representatives where Foundation mandate is affected
- Intended audience:
- core contributors
- team members
- documentation contributors
- designers
- marketing contributors
- community members interested in governance
Sources
Plone sources
- Plone Improvement Proposals: https://6.docs.plone.org/contributing/core/plips.html
- PLIP review: https://6.docs.plone.org/contributing/core/plip-review.html
Other Open source governance and proposal processes
- Python PEP 1: https://peps.python.org/pep-0001/
- Django DEP 1: https://github.com/django/deps/blob/main/final/0001-dep-process.rst
- Rust RFC process: https://rust-lang.github.io/rfcs/
- Rust Governance: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md
- Kubernetes Enhancement Proposals: https://www.kubernetes.dev/resources/keps/
- Apache voting process: https://www.apache.org/foundation/voting.html
Governance and community literature
- Karl Fogel, Producing Open Source Software:
https://producingoss.com/en/producingoss.html#social-infrastructure - PEP 8002 – Open Source Governance Survey
https://peps.python.org/pep-8002/