Let's formalize the PSP adoption process

[mijustin]

I'd like to formalize how the Podcast Standards Project adopts new features and standards (how we move from idea to adoption).

One thing we're all learning: creating a broad consensus on adopting a new feature, across multiple companies + platforms, is challenging!

We need a clear, transparent process that balances community input with practical implementation.

We also need something that allows us to backtrack if we feel like a specific feature doesn't merit broad adoption.

Proposed Process

Feature/Standard Suggested → Discussion → Research → Vote (Yay/Nay) → Beta → Vote (Yay/Nay) → Standard Phase 1: Optional → Standard Phase 2: Required

1. Feature/Standard Suggested

• Features bubble up during our meetings (at events), in Slack, from user research, and from the Podcasting 2.0 community
• If there's sufficient interest, we discuss it more formally

2. Discussion

• Feature is discussed during meetings + Slack
• Formal discussion should happen on GitHub as an Issue
• "Feature Champion" should be assigned
• Discussion of use cases, edge cases, and alternatives

3. Research

• "Feature Champion" goes out and does research
• Answers these questions
  • What kind of appetite is there from Creators/Listeners for this?
  • What kind of appetite is there from Apps?
  • What kind of appetite is there from Hosting Providers?
• What could this feature look like if we implemented it and standardized it?
  • Technical specification draft
  • Implementation requirements
  • Demo

A good example of this phase is what @albertobeta did here:
https://docs.google.com/document/d/1ByqYF0Rwmio9ugDkVg4_6wHXc8bjRBcMab5SLXrlzqg/edit?tab=t.0#heading=h.32lc1e4nrou8

4. Vote 1: Proceed to Beta?

• Entry: Research phase complete
• Voting Body: PSP Steering Committee [to be defined]
• Threshold: [Supermajority / Consensus - TBD]
• Question: "Should this proceed to beta testing?"
• On Failure:
  • Proposal can be revised and resubmitted
  • Or marked as "Postponed" with clear reasoning
  • Champion may appeal decision

5. Beta

• Entry: Vote 1 passes
• Requirements:
  • Implementation guide published
  • Test suite/validation tools available (if applicable)
  • Regular status updates from implementers
• Tracking:
  • Which platforms/apps have implemented
  • Issues discovered
  • User feedback and adoption metrics
• Refinement: Minor adjustments allowed; major changes require returning to Research
• Exit Criteria:
  • Successful implementations in production
  • No critical unresolved issues
  • Demonstrated real-world value

6. Vote 2: Adopt as Standard?

• Entry: Beta period complete
• Voting Body: PSP Steering Committee
• Threshold: [Supermajority / Consensus - TBD]
• Question: "Should this be adopted as an official PSP standard?"
• Review Materials:
  • Beta implementation report
  • Community feedback summary
  • Any changes made during beta
• On Failure:
  • Continue beta with specific improvement goals
  • Or sunset the feature with documented reasoning

7. Standard Phase 1: Optional

• Entry: Vote 2 passes
• Status: Officially recognized PSP standard
• Expectation:
  • Platforms/apps MAY implement this feature
  • Should be documented in official PSP specifications
  • Implementations should follow the standard specification
• Purpose: Prove broad adoption and stability

8. Standard Phase 2: Required

• Entry: Demonstrated broad adoption during Phase 1
• Status: Core standard
• Expectation:
  • PSP members a required to support this feature
• Note: True "required" status may only apply to specific categories (e.g., "video podcast apps MUST support HLS")

Special Paths

Withdrawal

• A proposal can be withdrawn at any stage by the champion

Fast Track

• For urgent security fixes or critical compatibility issues

Rejection/Postponement

• Failed votes don't mean permanent rejection
• Proposals can be revised and resubmitted
• Clear reasoning must be documented

Examples from Other Standards Bodies

• IETF: Internet-Draft → RFC with rough consensus
• W3C: Working Draft → Candidate Recommendation → Recommendation
• TC39 (JavaScript): Stage 0-4 with clear advancement criteria
• Python PEPs: Draft → Discussion → Acceptance → Final
• Rust RFCs: Pre-RFC → RFC → Implementation → Stabilization

===

What are your thoughts on this process?

[yaelirub]

This is great. Thanks for sharing, @mijustin! A couple of questions:

1. Is there a timeline for implementing feature X by date?
2. How is feedback gathered? Is there a mechanism for creators/listeners to provide input on how effective it is?

[picard102]

Would this work the same way for enhancements to current supported features? For instance if the person tag ever gets updated to allow multiple roles?

[kookster]

I wonder if we could call or think of optional as recommended?

I mean, the whole point of including a tag is that it's recommended, so maybe redundant

but it seems like adoption is the distance from optional to required, so maybe recommended would make it clearer these tags aren't going to be optional forever, they are recommended to be adopted?

(although I agree that they would be optional as far as certification?)

this is great work, thanks!

[kookster]

I appreciate the notion of a steering committee for decisions.
Prior to that, perhaps an expectation of membership in the PSP is to answer simple poll-like questions for measurement of "appetite"? e.g. could a function of the PSP be to poll member hosting and app providers prior to any vote, to gauge interest in the Research phase? In practice, could be as simple as a slack poll?

[snipd-kevin]

The overall structure seems sound to me. I just have the wish that there is a bit more explicit emphasis on the value created for either the listener or the creator.

Some additional context:
Any new big feature will require either the listener, the creator or both to be interested in it. Otherwise, it will never get off the ground.

If that is the case, then I believe we should have a hypothesis about what this value is and force ourselves to:

1. formulate it clearly
2. validate it

Of course, I realise that hosters and apps are the ones who need to implement the features, but the best way to convince those parties is if their customers want it. For podcast apps (like us) this is the listener, for podcast hosters it is the creator.