[1.P3] P3 Purpose and Guidelines

---
p3 (mod): 1
network:alltitle: P3 Purpose and Guidelines
status: P3
mod status (mod): Accepted
author: DK (@dk3)
mod: DK (@dk3)
sponsor: DK (@dk3)
created: 2023-01-12T00:00:00.000Z
proposal (mod): https://gov.premia.finance/#/proposal/0xcc8ed29d41cfaf919baed0c84b15b0832972f0c9fd1d8f6cb5d543839991df91
type: Reference
group (mod): NA
---

What is a P3?

P3 stands for Premian Publication Process, it has been adapted from the EIP (Ethereum Improvement Proposal). The purpose of this process is to ensure changes to Premia are transparent and well governed. A P3 is a design document providing information to the Premian community about a proposed change to the system. The author is responsible for building consensus within the community and documenting dissenting opinions.

P3 Roles

• Author: Any community member wishing to draft a proposal
• Mod: Moderators have impartial judgement in making sure proposals are edited and comply with reference standards.
• Sponsor: Core Contributor who sponsors the proposal for voting and ratification (needed at P3ND Status)

P3 Status Codes

DRAFT

• WIP3: Inception state of a Pre-P3 during the ideation stage, considered a draft.
• HYP3: Pre-P3 that is under discussion for serious consideration and is open for commentary and revision.
• P3ND: Pre-P3 commentary period has closed and Author has modified to include community feedback. Moderators have ensured it complies with standards and the Author has procured a sponsor.

PUBLISHED

• P3: P3 has been merged and classified, next steps dependent on classification.

P3 Type Codes

Concept, Task, & Reference

• Concept: What and Why, Topic Explanation, Goal
• Concepts are the qualitative goals (that may be backed up with quantative data), can be objectives to strive for.
• Task: How to get done, follow to achieve goal
• Tasks are technical implementations and steps to achieve an outcome, can be a parameter change or contract update.
• Reference: Need to know to complete task
• References are the frameworks on how/if a Task or Concept can be proposed.

Notes: Some P3s may be a concept to signal the community to build towards a technical framework and ratify via a reference.An example of this could be the community wishes to change the tokenomics at a foundational level, this can be proposed as a concept until further development is complete, once the development has been completed the formal process can be outlined via a Reference P3, then when the actual on chain transactions are to be submitted to be completed as a P3 Task.

Since these are all related this can be all associated as a group for easy navigation.Group settings will be decided by the P3 Moderator, and is not included by the Author in the proposal.

P3 Rationale

We intend P3s to be the primary mechanisms for proposing new features, collecting community input on an issue, and for documenting the design decisions for changes to the Premia Ecosystem. Because they are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal. (Github)

It is highly recommended that a single P3 contain a single key proposal or technical change.

A P3 must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement.The enhancement must represent a net improvement.

P3 Work Flow

Parties involved in the process are the author, the moderator, the sponsor and the Premia community.

Before you begin, discuss your idea, this will save you time. Ask the Premia community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. A good place to begin is the discussion board of the

Forum or the Community Resources

. It also helps to make sure the idea is applicable to the entire community and not just the author. Just because an idea sounds good to the author does not mean it will have the intended effect or the community will agree.

Your role as the champion is to write the P3 using the style and format described below, lead the discussions in the appropriate forums, and build community consensus around the idea. Following is the process that a successful P3 will move along:

←

→

Each status change is requested by the P3 author and reviewed by the P3 moderators. Use a pull request to update the status. Please include a link to where people should continue discussing your P3. The P3 moderators will process these requests as per the conditions below.

Mod Status

• Rejected - P3 that has failed to progress due to infeasibility, ineligibility, or lack of consensus.
• Deferred - P3 that has been tabled by the author or eligible entity to revisit at later time.
• Accepted - P3 that is generally beneficial for the ecosystem and uncontested. In the queue for progression.
• Approved - P3 that was drawn to vote and has passed with majority and quorum.
• Executed - P3 that has been implemented and no action is considered pending.
• Active - P3 that outlines current process, best practice, or status quo.
• Obsolete - P3 that has been replaced or revised and is now considered deprecated.

What makes a successful P3

Each P3 should have the following components:

• MetaContent - RFC 822 style headers containing metadata about the P3, including the P3 number, a short descriptive title (limited to a maximum of 44 characters), and the other details (use this as a template).
• Summary - Provide a simple and layman-accessible explanation of the P3.
• Abstract - a short (~200 word) description of the idea/technical issue being addressed.
• Motivation - The motivation is critical for P3 that want to change Premia. It should clearly explain why the existing specification is inadequate to address the problem that the P3 solves. P3 submissions without sufficient motivation may be rejected outright. It is appropriate to include reinforcing data here.
• Specification - The technical specification should describe the syntax and semantics of any new feature.
• Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.
• Test Cases - Test cases may be added during the implementation phase but are required before implementation.
• Copyright Waiver - All P3 must be in the public domain. See the bottom of this P3 for an example copyright waiver.

P3 Formats and Templates

P3 should be ultimately written in [markdown] format.Initially however they can be posted on the Forum in local format.

Resources

DiscordDiscourseSnapshotCommunity Links

Influences:

Synthetix Governance Process

Copyright

Copyright and related rights waived via CC0.