dob
commented
4 years ago State Change Conditions
I presume that PR's must be submitted in order to move something from Draft -> Last Call -> Proposed. I think the trigger for an editor accepting the move from Last Call to Proposed status could be that the last call time period has elapsed. But what is the trigger that an editor will use to decide whether to merge the PR from Draft -> Last Call?
I suggest it be that the champion submits the PR or signs off on it, in combination with editorial discretion that the issue is well formed.
Last call period length
The Last Call period should typically be 14 days to give stakeholders ample time to voice objections and to request changes prior the LIP being the subject of a poll
I might suggest a slightly shorter last call period. 10 days? If the current suggestion is that a poll period is 10 days, for the same reason of expecting a week of offline time as acceptable with a few more days to review and participate, then I don't think the last call period needs to be longer. We'd be looking at a ~3 week turnaround from last call to execution.
Batching LIPs into a single update
Does this process account for how one would batch a series of parameter and standards track LIPs into a single executed on chain update? Would you get all of these LIPs individually approved into Accepted state, and then vote on a standards track LIP which batches them together into Accepted state in order to be merged?
Or would you file the parameter change and standards track mini-LIPs as informational, and then use a single standards track LIP to vote on them all at once?
yondonfu
Abstract
This proposal contains updates to the LIP process described in LIP-1 that incorporate the use of a polling application to determine whether a LIP is accepted or rejected.
Motivation
The motivation for these updates is to establish the LIP process as a pre-processing step for proposals prior to the creation of a poll about the proposal. While a poll can be created for a proposal that does not go through the LIP process the hope is that the LIP process can establish a quality standard for proposals such that proposals that do not go through the LIP process will have a lower probability of being accepted relative to proposals that do go through the LIP process.
Specification
Updated LIP Types
The following new LIP types are introduced:
Updated LIP Statuses
The following new LIP statuses are introduced:
The following existing LIP statuses are removed:
Updated LIP Work Flow
Path to Adoption
The following diagram describes the path to adoption for a LIP:
The Last Call Period
The Last Call period should typically be 14 days to give stakeholders ample time to voice objections and to request changes prior the LIP being the subject of a poll. During this time, the LIP should be publicized in various communication channels such as Discord, the forum, blog posts, etc. The rationale behind targeting 14 days for the Last Call period is that it allows someone to go offline for a week (i.e. for vacation) and still have time after returning to review the LIP before the end of the Last Call period.
Poll Usage
When a LIP is assigned the Accepted status, the expectation is that it will be immediately adopted and any required on-chain updates mentioned in the LIP should be executed by the core team. While the use of a poll is only required to move a LIP from the Proposed status to the Accepted or Rejected status, a poll can also be used to gauge sentiment around a LIP earlier in the process. Any poll created for a LIP that is not assigned the Proposed status can be considered a sentiment poll. These types of polls may be useful for assessing the chance of an LIP eventually being adopted before investing a large amount of resources for implementation and testing. The decision of whether to create a sentiment poll earlier in the process is up to the LIP champion(s).
The champion(s) of a LIP is typically expected to create a poll if the LIP is assigned the Proposed status, but the poll can also be created by someone else.
Updated LIP Template
The following optional fields in the header preamble described in the LIP-X template are introduced:
Specification Motivation
The motivation behind the structure of the updates described in this proposal is to establish greater clarity and transparency around the adoption path for a LIP.
Feedback
The thread for this issue can be used for conversation and feedback prior to the opening of a PR to include these updates as a draft meta LIP in the repo.