Decision Process

Plumego evolves through deliberate, constrained decisions.

This document explains how decisions are made,
who makes them,
and what criteria determine whether a proposal is accepted or rejected.

Understanding this process is essential
before proposing changes to Plumego.

Core Principle

Plumego follows a single guiding rule for decisions:

Design coherence is more important than feature accumulation.

Every decision is evaluated based on its impact
on long-term clarity, explicitness, and trust.

Who Makes Decisions

Plumego uses a benevolent dictator model.

This means:

• There is a clear final decision-maker
• Input and discussion are welcome
• Consensus is not required
• Coherence overrides popularity

This model exists to prevent:

• Design drift
• Conflicting abstractions
• Incremental erosion of principles

Types of Decisions

Not all decisions are equal.
Plumego distinguishes between several categories.

1. Documentation Decisions

Examples:

• Clarifying semantics
• Rewording explanations
• Adding examples
• Improving structure

These decisions are:

• Low risk
• Encouraged
• Reviewed for clarity and accuracy

Documentation changes are often merged quickly.

2. Bug Fix Decisions

Examples:

• Fixing incorrect behavior
• Aligning implementation with documentation
• Removing undefined behavior

Criteria:

• Must preserve documented semantics
• Must not introduce new behavior implicitly

Bug fixes are accepted when they restore trust.

3. Internal Refactor Decisions

Examples:

• Simplifying internal code
• Improving readability
• Reducing duplication
• Performance cleanups

Criteria:

• No observable behavior change
• No public API impact
• Clear justification

Refactors that add abstraction without clear benefit
are often rejected.

4. Public API Decisions

Examples:

• New exported types or functions
• Changes to existing signatures
• New configuration surfaces

These decisions are high-risk.

They require:

• Strong motivation
• Clear problem statement
• Alignment with design principles
• Long-term maintenance justification

Most proposals fail at this stage.

5. Architectural Decisions

Examples:

• Changing execution semantics
• Altering middleware behavior
• Introducing new core concepts
• Modifying lifecycle guarantees

These are exceptionally rare.

They require:

• Explicit design documents
• Consideration of alternatives
• Migration impact analysis
• Long-term ecosystem effects

Architectural changes are treated as last resorts.

The Evaluation Checklist

Every proposal is evaluated against the same checklist.

Key questions include:

1. Does this introduce hidden behavior?
2. Does this reduce explicit control flow?
3. Does this weaken package boundaries?
4. Does this expand the core unnecessarily?
5. Does this reduce replaceability?
6. Does this complicate error handling?
7. Can this live outside the core instead?
8. What is the long-term maintenance cost?
9. What happens if this decision is wrong?

If a proposal fails any critical question,
it is likely rejected.

The Role of Non-Goals

Plumego’s non-goals are binding constraints, not suggestions.

If a proposal violates a documented non-goal:

• No workaround is considered
• No exception is made
• No “special case” is allowed

Non-goals exist to make decisions easier and faster.

Why Many Proposals Are Rejected

Rejection is common and expected.

Typical rejection reasons include:

• “This adds convenience but hides behavior”
• “This belongs in user code, not the framework”
• “This increases surface area without reducing risk”
• “This duplicates patterns better handled externally”

Rejection is about fit, not quality.

Decision Transparency

When a proposal is rejected:

• The reason is stated explicitly
• The principle involved is referenced
• Alternatives are often suggested

Plumego prefers clear rejection over vague delay.

No Silent Decisions

Plumego avoids:

• Silent behavior changes
• Undocumented semantics
• Accidental feature creep

If behavior changes,
it must be:

• Intentional
• Documented
• Justified

Undocumented decisions are treated as bugs.

Reversibility as a Requirement

A key decision criterion is:

“How hard is this to undo?”

If a decision would be difficult or impossible to reverse,
it is held to a much higher bar.

Irreversible decisions are made sparingly.

The Role of Time

Plumego intentionally moves slowly.

Time is used to:

• Let ideas mature
• Observe real-world usage
• Validate assumptions
• Avoid reactive changes

Urgency is not considered a valid argument.

How to Improve a Proposal’s Chances

If you want a proposal to be taken seriously:

• Clearly define the problem
• Show real-world pain, not hypothetical convenience
• Explain why existing patterns are insufficient
• Demonstrate alignment with principles
• Propose the smallest possible change
• Include a removal story

Most successful proposals are boring and narrow.

Disagreement and Respect

Disagreement is expected.

However:

• Decisions are not debated endlessly
• Once made, decisions are respected
• Reopening requires new information

Plumego values focus over perpetual discussion.

Summary

Plumego’s decision process exists to:

• Preserve coherence
• Protect explicitness
• Limit surface area
• Maintain long-term trust

Decisions are slow, deliberate, and principled — by design.

If you want to contribute,
you are not just proposing code.

You are proposing a promise to future users.

Related Contributing Pages

• Design Principles — constraints on decisions
• Non-Goals — absolute boundaries
• Code Structure — where changes are allowed
• Workflow — how proposals move forward

Plumego does not optimize for agreement.
It optimizes for correctness over time.