updated nep-0001 #350
updated nep-0001 #350
Conversation
|
Your Render PR Server URL is https://nomicon-pr-350.onrender.com. Follow its progress at https://dashboard.render.com/static/srv-c983f8vd17c1imia4tbg. |
neps/nep-0001.md
Outdated
| ### Initial phase (1 week at most) | ||
|
|
||
| 1.1. The process is initiated by an author submitting it in `Draft` status. | ||
|
|
||
| 1.2. The proposal is examined by the admins. If it deviates from the format the proposal's status is set to `Rejected` and allowed to be resubmitted in 1 month. | ||
|
|
||
| 1.3. Admins invite SMEs (some SMEs recognized by admins might join voluntarily) and representatives from the affected projects. | ||
|
|
||
| 1.4. (Optional) The stakeholders hire the auditors. | ||
|
|
||
| 1.5. Admins update the status to `Review` to indicate readiness for the next phase. | ||
|
|
||
| ### Discussion phase (2 months at most) | ||
|
|
||
| 2.1. SMEs and affected projects weigh-in. | ||
|
|
||
| 2.2. Auditors respond with their findings. | ||
|
|
||
| 2.3. Other community members join the discussion. | ||
|
|
||
| 2.4. Once the proposal is at the point where it is exhaustive, non-ambiguous, highly-detailed, and all findings are addressed and incorporated into the proposal, the admins make a decision on accepting or rejecting it. | ||
|
|
||
| 2.5. If proposal runs out of time it is rejected. | ||
|
|
||
| ### Implementation phase | ||
| 3.1. Admins invite representatives from the affected projects and the implementers to discuss the timeline of rolling out the feature. Once the timeline is agreed on, the remaining process is delegated to the implementers. |
There was a problem hiding this comment.
I think this would work well for standards, but for protocol changes, at least right now we cannot afford to go through this very expensive process. I suggest that for protocol changes, the proposer also submit an accompanying prototype implementation to validate their proposal.
There was a problem hiding this comment.
@bowenwang1996 We could probably tighten these up if need be. For the sake of discussion, what do you think the protocol timelines would look like. If they are close I can adjust, if not, we might have to diverge the processes.
There was a problem hiding this comment.
@jlogelin I propose that we initially have the following process:
- Draft proposal with an accompanying prototype implementation to prove validity.
- A review period not exceeding two months where a committee would review the proposal and give feedback to iterate the proposal together with the author.
- Final decision made publicly during a public protocol meeting on whether to accept the proposal.
| @@ -100,6 +99,49 @@ the appropriate venue mentioned above. This gives the author a chance to flesh o | |||
| NEP to make properly formatted, of high quality, and to address | |||
| initial concerns about the proposal. | |||
|
|
|||
| ## The Proposal Process | |||
| One of the primary goals of the NEP process is to prevent proposals being stuck in a limbo state of always being in progress, therefore NEP participants shall commit to always either accept or reject a `Draft` proposal. | |||
There was a problem hiding this comment.
I want to play devil's advocate here: I think "stuck in limbo" is a fairly common outcome for many of Rust's RFCs (eg, two of the three RFCs I authored can be described as stuck). This if course is suboptimal, but it seems that the final Result (the Rust language) is doing fine. Stuckness also is a useful signal -- it shows the lack of motivation, implementation capacity, or certainty.
So I'd say that the process's "primary goal" is to facilitate reliable and proactive protocol evolution, and fast accepting/rejecting is just "one of the goals"
| ## Roles, Ownership, and Accountability | ||
| The overall NEP process should balance democracy and inclusivity, with accountability. This means the proposal needs to have owners – people who carry the burden of proving “beyond reasonable doubt” that the proposed design does what it claims to do and that it does not negatively affect our technological values or impede future velocity. The owners of the proposal are the author and its potential proponents. It is their responsibility to prove that the proposal works, and it is not responsibility of others to prove that it does not work. The default decision for any protocol change should be a No. | ||
|
|
||
| There are defined administators who will decide when the proposal is accepted or rejected. In the long run, this will be a council elected by the stakeholders, which most likely will be only the validators and people that validators consider as an authority or experts, since validators have an ultimate control of deciding which protocol version to run on their machines. In the short term, process admins will be a preselected group of people. Admins will also be moderating the discussion once the proposal is submitted to make sure the discussion is civil and focused. |
There was a problem hiding this comment.
Admins will also be moderating the discussion once the proposal is submitted to make sure the discussion is civil and focused
If we have extra people power, it would be much better to have a dedicated moderation team. Admins themselves should be moderated, and that shouldn't involve conflict of interests.
To bootstrap the process, I think it's OK to lump the two responsibilities together.
But maybe we can say something like "there's admin team, who does this" and "there's mod team, who does that", and than, separately "to bootstrap the process, both teams would intersect".
frol
requested review from
frol and
ori-near
and removed request for
a team and
MaksymZavershynskyi
frol
added
documentation
|
@ori-near May I ask you to review this proposal? |
frol
added
S-draft/needs-moderator-review
added roles and ownership section; proposal process revamp to reflect