Skip to main content

Decision Making

PTI governance decisions SHOULD be made by rough consensus — wide agreement among participants, with unresolved objections examined on their technical merit rather than participant count alone. When consensus cannot be reached, documented voting rules apply.

Process rules use RFC 2119 keywords.

Decision categories

CategoryExamplesDefault mechanism
RoutineErrata, editorial fixes, meeting schedulingMaintainer discretion
TechnicalRFC promotion to Candidate/AcceptedRough consensus
ArchitecturalCross-cutting design, breaking changesRough consensus + ARB sign-off
SecurityCrypto suites, disclosure timelinesSRG recommendation + WG ratification
GovernanceChanges to this document setSupermajority vote
ConformanceProfile requirement changesConformance Board + WG ratification

Rough consensus procedure

Adapted from open-standards practice without copying any single organization's rules:

  1. Call for comments — Proposal published with minimum review period
  2. Summarize positions — Maintainer documents support, neutral, and objecting parties
  3. Resolve objections — Authors SHOULD address each substantive objection in writing
  4. Assess remaining dissent — If objections are narrow, specific, and technically grounded, MAY block; vague or procedural objections SHOULD NOT alone block
  5. Declare outcome — Maintainer states consensus reached, deferred, or failed

What counts as substantive

Substantive (may block)Non-substantive (should not alone block)
Demonstrated interoperability failurePreference for different naming
Security flaw identified by SRGUnimplemented "nice to have"
Privacy regression vs RFC-009Schedule pressure
Breaking change without policy complianceDislike of author's employer

Formal voting

Votes MUST be used when:

  • Governance document amendments require supermajority
  • Rough consensus fails after two revision cycles
  • Stewardship Council appeals (Phase 1–2 only)

Eligibility

During Phase 1–2, voting participants SHOULD include:

  • Maintainers
  • Contributors with merged RFC or test contributions in the last 12 months
  • One delegate per accredited independent implementer organization (optional seat)

From Phase 3, eligibility rules SHOULD expand per Ecosystem Roadmap.

Thresholds

DecisionThresholdQuorum
RFC Accept / Stable≥75% approve, ≤2 blocking objections unaddressed50% of eligible voters
Governance rule change≥66% approve50% of eligible voters
Emergency security patchSRG chair + 2 MaintainersN/A
Deprecation of Stable RFC≥75% approve + 90-day notice50%

Votes SHOULD run open ballot for transparency. Secret ballots MAY be used for personnel matters only.

Board recommendations

BoardBlocking?
ARBSHOULD block Stable promotion for architectural RFCs without written clearance or documented override
SRGMUST block Accepted/Stable for security RFCs without review
Conformance BoardMUST block profile changes that invalidate certificates without grandfather plan

Override of a board block MUST be recorded with public rationale and SHOULD require supermajority WG vote.

Appeals

  1. Appellant MUST file written appeal within 14 days of decision
  2. Different Maintainer SHOULD triage; conflicted Maintainers MUST recuse
  3. Appeal MAY reopen discussion or escalate to Stewardship Council (Phase 1–2)
  4. Final specification interpretation for Stable RFCs MAY be referred to ARB for binding errata interpretation

Decision records

Substantive decisions MUST publish:

FieldContent
IDDecision-YYYY-NNN
DateISO 8601
SubjectRFC ID or policy section
OutcomeApproved / rejected / deferred
Vote talliesIf applicable
Dissent summaryPreserved for future reference
LinksPRs, issues, minutes

Conflicts of interest

Participants MUST recuse from votes where:

  • Personal financial interest exceeds disclosed threshold
  • Employer stands to gain exclusive advantage from non-neutral outcome
  • Participant authored >50% of contested text without co-author

Recusal MUST NOT reduce independent reviewer minimums.