Update to All Status and the EIP process flow for EIP-1 #2996

MadeofTin · 2020-09-23T17:22:11Z

The proposed Status to changes to EIP-1 inline with clarifiying the EIP repo as soley a standardization body.

Decisions made during the 17th EIPIP meeting. https://github.com/ethereum-cat-herders/EIPIP/issues/33

As decided in EIPIP meeting 17. https://github.com/ethereum-cat-herders/EIPIP/issues/33

MicahZoltu

Left a bunch of feedback, but I think this change is an iterative improvement over what is there now and heartily approve it for immediate merge without waiting on any of my feedback to be addressed.

MicahZoltu · 2020-09-24T02:34:24Z

EIPS/eip-1.md

-```
+**Draft** - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
+
+**Review** - An EIP Author marks an EIP as ready for and requesting Peer Review.


I thought we talked about having a minimum Review period? Generally, for each of these statuses I would like to see a very clear set of requirements for moving on to the next stage, or moving backward (when applicable).

Yes, we should flesh this out in a separate PR. I do like the idea. Most of my internal apprehension comes from thoughts relating to hardfork stuff, so I take that as a sign we actually should do it. 😆

MicahZoltu · 2020-09-24T02:35:44Z

EIPS/eip-1.md

+
+**Last Call** - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later.
+
+If this period results in necessary material changes it will revert the EIP to `REVIEW`.


Historically we have never actually moved a Last Call back to Draft. The problem is that editors are pretty loath to make judgement calls and so when there is feedback during Last Call people tend to just update the PR and leave the Last Call timer running.

I wonder if we can get more clarity on what "necessary material changes" means?

Changing material to normative may help resolve this. I think it is more clear what a normative change is.

We have extended the timer before. At least through the ACD calls. Even if the EIP wasn't updated.

I personally would like to see one move back, but it may be we need a more algorithically specified system as well as have people ready to enforce it first.

Made the change to normative

MicahZoltu · 2020-09-24T02:36:16Z

EIPS/eip-1.md

+
+If this period results in necessary material changes it will revert the EIP to `REVIEW`.
+
+**Final** - This EIP represents the final accepted standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-material clarifications.


I prefer non-normative over non-material.

sounds good

MicahZoltu · 2020-09-24T02:38:15Z

EIPS/eip-1.md

+
+**Final** - This EIP represents the final accepted standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-material clarifications.
+
+**Stagnant** - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is algorithmically moved to `STANGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to`DRAFT`.


I would prefer 2 months for stagnant. Stagnant is non-terminal, and I feel like 2 months is plenty of time for someone to just touch a Draft.

Suggested change

**Stagnant** - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is algorithmically moved to `STANGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to`DRAFT`.

**Stagnant** - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is moved to `STANGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to`DRAFT`.

The wording here is a bit weird, and since we are clearly specifying the condition in the same line I don't think the "algorithmiclly" bit is necessary.

I wanted to leave room for a bot or an Editor to make the move as long as the rules are followed. I can change it back to automatically? Or do you mean to leave it out?

For the reduction to 2 months. I am fine with this. I am not sure if the change is big enough to need a larger discussion about it.

Presumably if/when we add more conditions for moving to stagnant they'll get listed here, or if the list grows too long this will point at that list. I think just removing the word from the sentence will improve readability and won't cause us any loss of flexibility in the future.

MicahZoltu · 2020-09-24T02:41:41Z

EIPS/eip-1.md

-  * :arrow_right: Draft -- Authors or new champions wishing to pursue this EIP can ask for changing it to Draft status.
-* **Rejected** -- An EIP that is fundamentally broken or a Core EIP that was rejected by the Core Devs and will not be implemented. An EIP cannot move on from this state.
-* **Superseded** -- An EIP which was previously Final but is no longer considered state-of-the-art. Another EIP will be in Final status and reference the Superseded EIP. An EIP cannot move on from this state.
+**Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1. Any changes to these EIPs will move between `REVIEW` and `LIVING` states.


I just realized the two way arrow with Living. I feel like living should not be able to go back to review. For example, we would never move EIP-1 back to review. Once something is in Living I think that should be a final state, just a state that doesn't prevent normative changes.

Something nice about the Living to Review is that it gives a way for Edits to EIP-1 to be subscribed to by an RSS feed. This assumes that all Statuses get an RSS feed at some point (which is one of the proposals)

An RSS Feed that publishes merged changes to Living EIPs I think would also satisfy this. My goal is some way for people to watch these EIPs in particular for any changes and have a chance to give feedback on them.

In the same spirit as LAST CALL, but without being as constrictive.

Hmm, my concern with that is that if EIP-1 is moved to Review, it means there is currently no LIVING version of EIP-1 available during that time. To the naive reader this may mean that there are no finalized rules for EIPs at the moment! 😱

IMO, the two-way arrow is to indicate that it is being reviewed all the time, and changes should be expected.

However, Living being an exceptional status can be explained - "it is a final status and is actively reviewed. Hence, no change is expected in the status but content."

It is similar to the present situation. This PR is suggesting changes to content, but the status is 'Active'.
(Status is being renamed not changed.)

EIPS/eip-1.md

lightclient · 2020-09-25T00:56:35Z

EIPS/eip-1.md

+
+>*EIP Authors are notified of any algorithmic change to the status of their EIP*
+
+**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.


Did we decide to have stagnant EIPs move to "withdrawn" after a long period (i.e. 2 years)?

I believe it was generally agreed to be "probably a good idea", but would be introduced in a separate changeset after this one is merged.

EIPS/eip-1.md

edsonayllon · 2020-10-29T03:13:13Z

Any update on this? Looks good to me to merge. More revisions can probably be done with a new PR.

edsonayllon · 2020-10-29T03:14:33Z

@MadeofTin Can the suggestions be committed?

gcolvin

I won't try to make individual changes, but I do not see any need for the Review and Living statuses. The original intent of the editors was that Draft and Final pretty much sufficed, with Last Call and some form of withdrawal coming later. Review isn't needed because Drafts, even Final ones, are always subject to review. We already have the Last Call review period for Drafts that the author thinks are close to final. And a Living draft is just a draft that stays a Draft.

MicahZoltu · 2020-10-31T05:22:14Z

@gcolvin The purpose of the additional statuses is to give signalling information to readers (and tools) as to what stage of the iteration process a particular EIP is in. When an EIP is in draft stage, it is a pretty big waste of time for most people to review it as it is likely undergoing rapid iteration. By adding a Review stage, it alerts people that this EIP is now in a place where the author is done iterating on it and is actively soliciting feedback from the community. This differs from Last Call because up to this point, the EIP likely hasn't actually been read by anyone so it would be naive to think that it is "ready to go to final".

The idea with Last Call is to alert potential readers that "we have integrated all community feedback, this is your last chance to speak up with critical problems before this EIP calcifies as Final!

In each of these cases, tools can be written (and some already exist) to alert specific subscribers of state changes, which is why there is value in having these encoded in the frontmatter. We also can present them in different sections on the EIPs page.

gcolvin · 2020-10-31T15:37:44Z

The purpose of the additional statuses is to give signalling information to readers (and tools) as to what stage of the iteration process a particular EIP is in. When an EIP is in draft stage, it is a pretty big waste of time for most people to review it as it is likely undergoing rapid iteration.

@MicahZoltu I just disagree here. EIP discussion potentially begins before draft status and continues after Final status. (After Final status the review is only for errata, of course.)

For those wanting to help with drafting, early is the best time to review. For those needing to see substantial changes in substance an early review can save wasted editing time. (The IETF manages a much larger, more important network with only a Draft status, and has for years now.)

For more signaling I still suggest we just add a free form field for the purpose.

MicahZoltu · 2020-10-31T15:48:32Z

@gcolvin What do you see as the benefit to having fewer stages or moving the information about current progression into a separate field from Status?

we just add a free form field for the purpose.

My problem with a free form field is that automated tooling (e.g., notification on certain stages) becomes next to impossible to usefully build. With well defined stages, it becomes much easier to build automated tooling around these stages.

The IETF manages a much larger, more important network with only a Draft status, and has for years now.

There are similarly standardization organizations that have multistage processes like W3C as an example.

gcolvin · 2020-10-31T17:13:26Z

There are similarly standardization organizations that have multistage processes like W3C as an example.
@MicahZoltu
W3C is a membership organization, with mostly corporate members. The IETF is not a membership organization, and people participate as individuals. We modeled the current EIP process in large part on the IETFs. I don't see that there is anything broken about it that these extra statuses fix.

MicahZoltu · 2020-11-01T02:58:06Z

I don't see that there is anything broken about it that these extra statuses fix.

@gcolvin The additional statuses allow people and tools to hook into different phases of the process. Even if this is a minor gain, it seems like that should win out over zero losses. This leads me to believe that either you think that the ability for people and tools to hook into different phases of the process provides zero benefit, or that there is some downside to this addition that you see that the rest of us do not. I am guessing it is the latter, but it is not clear to me what the downside you perceive is.

Perhaps you just prefer no-change over change unless the benefits of the change are significant? In this case, the downside perhaps could be stated as, "change is hard and likely to introduce confusion and complication and this change doesn't meet the bar for being worth those costs"?

edsonayllon · 2020-11-02T07:35:58Z

The original reasoning Axic brought up for the Review status was, many people waited until Last Call to provide external review, which is too late in most cases. The difference between Review and Draft is, in Draft, the author is still fleshing out the EIP on his own. Then, once the author is satisfied with his work, he then requests external review with the Review status.

How this would work with Core EIPs, we could have EIPs that are in Review eligible to seek the Considered for Inclusion phase in hardfork coordination. It would signal a degree of maturity by what the author intends. And Review strictly signals when peer review is not just appropriate, but in active request.

edsonayllon · 2020-11-02T07:36:53Z

As for Living, it's just a naming change from Active to something that is more often used for that category of documents, Living Documents. Active already exists, and removing it would mean putting EIP-1 in permanent Draft status.

gcolvin · 2020-11-04T13:56:03Z

"change is hard and likely to introduce confusion and complication and this change doesn't meet the bar for being worth those costs"?
@MicahZoltu Exactly. Add in - Is counter to the founding philosophy of the EIP process. Simplicity matters.

gcolvin · 2020-11-04T14:04:07Z

The original reasoning @axic brought up for the Review status was, many people waited until Last Call to provide external review, which is too late in most cases.... once the author is satisfied with his work, he then requests external review with the Review status.
@edsonayllon Thanks. I don't really see that making the process more complex will help matters. And I have no problem with EIP-1 simply remaining a Draft.

MicahZoltu · 2020-11-04T16:29:37Z

EIPIP meeting discussion, tentative agreement to merge this and continue discussion. There is a desire that if we have Review as a status, it should be a major milestone with much fanfair rather than a subtle thing that passed quietly into the night.

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> Co-authored-by: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com>

MicahZoltu · 2020-11-05T10:07:15Z

Merging this since we received agreement in the EIPIP call from all interested parties. The plan is to have Review be a major milestone and should be accompanied by appropriate fanfare and announcements.

@lightclient Can you update the bot to allow EIPs with these new statuses to pass CI?

lightclient · 2020-11-05T15:56:14Z

@MicahZoltu yes, I will do that today.

I'm updating EIP statuses according to #2996. The mappings are as follows: ``` Draft => Draft Last Call => Last Call Accepted => Final Final => Final Superseded => Final Abandoned => Withdrawn Rejected => Withdrawn Active => Living ```

The proposed Status to changes to EIP-1 inline with clarifiying the EIP repo as soley a standardization body. Decisions made during the 17th EIPIP meeting. ethereum-cat-herders/EIPIP#33

I'm updating EIP statuses according to ethereum#2996. The mappings are as follows: ``` Draft => Draft Last Call => Last Call Accepted => Final Final => Final Superseded => Final Abandoned => Withdrawn Rejected => Withdrawn Active => Living ```

MadeofTin added 6 commits September 23, 2020 11:09

Update to New EIP Status

76564b6

As decided in EIPIP meeting 17. https://github.com/ethereum-cat-herders/EIPIP/issues/33

Add files via upload

a8dc13a

Delete EIP Statusus and Process.png

5834ef9

Add files via upload

b9e5845

Uploaded the Image to the appropriate assets section

aea56bd

Updated Formatting

288b9af

MicahZoltu approved these changes Sep 24, 2020

View reviewed changes

MadeofTin added 2 commits September 23, 2020 23:49

Updated Last Call to revert on Normative changes

f4907a4

Update eip-1.md

a57447a

lightclient approved these changes Sep 25, 2020

View reviewed changes

poojaranjan reviewed Sep 30, 2020

View reviewed changes

EIPS/eip-1.md Outdated Show resolved Hide resolved

poojaranjan mentioned this pull request Oct 6, 2020

EIPIP Meeting 18 Agenda ethcatherders/EIPIP#34

Closed

poojaranjan reviewed Oct 7, 2020

View reviewed changes

EIPS/eip-1.md Outdated Show resolved Hide resolved

gcolvin suggested changes Oct 29, 2020

View reviewed changes

Apply suggestions from code review

75ff842

Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com> Co-authored-by: Pooja Ranjan <29681685+poojaranjan@users.noreply.github.com>

MicahZoltu merged commit 639aba8 into ethereum:master Nov 5, 2020

This was referenced Nov 6, 2020

New statuses ethereum/eipv#25

Merged

Update EIP statuses #3096

Merged


		Last Call - This is the final review window for an EIP before moving to `FINAL`. An EIP editor will assign `Last Call` status and set a review end date (review-period-end), typically 14 days later.

		If this period results in necessary material changes it will revert the EIP to `REVIEW`.


		If this period results in necessary material changes it will revert the EIP to `REVIEW`.

		Final - This EIP represents the final accepted standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-material clarifications.


		Final - This EIP represents the final accepted standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-material clarifications.

		Stagnant - Any EIP in `DRAFT` or `REVIEW` if inactive for a period of 6 months or greater is algorithmically moved to `STANGNANT`. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to`DRAFT`.


		>EIP Authors are notified of any algorithmic change to the status of their EIP

		Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.

Update to All Status and the EIP process flow for EIP-1 #2996

Update to All Status and the EIP process flow for EIP-1 #2996

Uh oh!

Conversation

MadeofTin commented Sep 23, 2020

Uh oh!

MicahZoltu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

edsonayllon commented Oct 29, 2020

Uh oh!

edsonayllon commented Oct 29, 2020

Uh oh!

gcolvin left a comment

Choose a reason for hiding this comment

Uh oh!

MicahZoltu commented Oct 31, 2020

Uh oh!

gcolvin commented Oct 31, 2020

Uh oh!

MicahZoltu commented Oct 31, 2020

Uh oh!

gcolvin commented Oct 31, 2020

Uh oh!

MicahZoltu commented Nov 1, 2020

Uh oh!

edsonayllon commented Nov 2, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

edsonayllon commented Nov 2, 2020

Uh oh!

gcolvin commented Nov 4, 2020

Uh oh!

gcolvin commented Nov 4, 2020

Uh oh!

edsonayllon commented Nov 2, 2020 •

edited

Loading