EIP-1: abandoned vs withdrawn

[axic]

In May we had a long discussion on the Abandoned/Withdrawn issue (ethcatherders/EIPIP#15), and prior to that it came up several times on Gitter. On the call I suggested to make use of the resolution field.

My opinion was that we are better with less states than fine graining them indefinitely. Abandoned and Withdrawn are so close, and it is possible to introduce fine-graining to either of these statuses to make them clear. I sense there was/is a subjective aspect (by some) to preferring withdrawn over abandoned, as a term.

I suggest the following:

1. Rename Abandoned to Withdrawn
2. Introduce a reason field with the following options: "withdrawn by author", "automatically withdrawn", "replaced/superseded by something else"

The reason is from an outsider point of view all it matters the standard is not pursued further, but for someone really interested in the relevant topic, figuring out the reason can be / is important.

If we do introduce a "replaced/superseded" marking, then likely we should reconsider the role of the the replaces and superseded-by fields too.

If we go ahead with any of these, I'd also propose to retroactively update and clarify all the EIPs currently marked as "Abandoned", and would also suggest to merge everything today as "Abandoned", unless we hit a resolution very quickly.

[MicahZoltu]

Abandoned/withdrawn only applies to pre-final EIPs right (e.g., Draft)? If so then I'm OK with with this proposal, with the caveat that only the original author can set replaced/superseded by as part of the process for moving something to withdrawn. I really dislike the idea of someone coming in and declaring that their thing is a replacement of someone else's thing without buy-in from the original author as that can very rapidly lead to political problems that editors now have to deal with.

[axic]

The other long outstanding idea is to have a bot which automatically "withdraws" EIPs which are stalled.

Let's say we have such a bot, which marks long untouched EIPs as such. Now the question is what is the best way to let people know this has happened? I have two ideas:

1. The bot actually creates a PR changing the EIP to status: Withdrawn and reason: automatically withdrawn or reason: automatically withdrawn due to inactivity The authors are tagged with their github usernames (like with the automerger). An editor has to merge this PR.

2. The bot creates a commit. In this case we want an intermediate status which is shown in an RSS feed and in a prominent place like for Last Calls. This I think could be either status: Pending Withdrawal or having a specific reason: Pending Withdrawal. In either case after some period this intermediate status has to be moved by the bot to the final Withdrawn status to stop it being presented in the RSS / prominent spot on the site.

@MicahZoltu @lightclient @Souptacular @MadeofTin any preference? Any other ideas?

[MicahZoltu]

I strongly favor the pull request, though I would want the bot to also merge after say n days (e.g., 3 days) if there are no comments on the PR. This way, editors only have to get involved if the user actually shows up to discuss, but for all of the no-contest withdraws it would be entirely automatic.

[lightclient]

I also strongly favor the PR. I don't have a strong opinion on renaming abandoned to withdrawn though. It seems off to call something "withdrawn" when the author had no say in the matter. Maybe "stale" or "obsolete" instead?

[axic]

I don't have a strong opinion on renaming abandoned to withdrawn though. It seems off to call something "withdrawn" when the author had no say in the matter. Maybe "stale" or "obsolete" instead?

This is a contentious discussion, some people have very strong opinion on why Withdrawn is the better status. I personally do not have a strong opinion whether Abandoned or Withdrawn is the right one, but I have a strong opinion that we should have a single one. Mostly because I think there more than 2 reasons to move into that status, which means we need to have extra fields even if we have both Abandoned and Withdrawn. Hence I suggest we choose one and use a reason field.

Took a look around the RFC and W3C process. RFC uses Withdrawn and W3C uses Rescinded. Perhaps rescinded is a good term based on the dictionary?

[axic]

Btw here's some prior discussion on abandoned/inactive/withdrawn: https://github.com/ethereum-cat-herders/EIPIP/blob/master/All%20EIPIP%20Meetings/Meeting%20008.md#5-separation-of-eip-process-and-hard-fork-coordination

[axic]

I strongly favor the pull request, though I would want the bot to also merge after say n days (e.g., 3 days) if there are no comments on the PR. This way, editors only have to get involved if the user actually shows up to discuss, but for all of the no-contest withdraws it would be entirely automatic.

I also strongly favor the PR.

I personally also favour that option, but perhaps it is too much to ask for the bot to automatically merge it. At least not in the first version 😉

[MicahZoltu]

Note from EIPIP call: We will be moving forward with the statuses as previously proposed for now and we can switch to this proposal at a later date from that if we decide that is preferable.

[axic]

Note from EIPIP call: We will be moving forward with the statuses as previously proposed for now and we can switch to this proposal at a later date from that if we decide that is preferable.

What statuses were proposed?

[poojaranjan]

Note from EIPIP call: We will be moving forward with the statuses as previously proposed for now and we can switch to this proposal at a later date from that if we decide that is preferable.

What statuses were proposed?

Statuses from the EIPIP meeting -
https://hackmd.io/TKGYSvz9Rt6v5VaNpGaWHw#EIP-Status-Definition-v2

[MadeofTin]

What statuses were proposed?

Here it is in image version so you don't need to click through to see pooja's link.

In image version

[MadeofTin]

Abandoned and Withdrawn
@axic

The two status considered is Stagnant and Withdrawn

Withdrawn is closer to what you mean by Abandoned and a "reasoning" field absolutely makes sense to add.

Stagnant is referring to when the development of an EIP stagnates and so an EIP automatically is eligible for this state. EIP-editors and perhaps a Bot can move an EIP to this status as long as it qualifies.

If someone wishes to withdraw or abandon an EIP an author can move it to the withdrawn state. This is not a status change that an editor nor a bot can make. Only the authors themselves can do this. Allowing Editors to move something to Withdrawn or Abandoned is a political decision. We should keep political decisions away from editors as much as possible.

Stagnant is useful here because it is very clear about what the status means and why an EIP has moved here.

[MadeofTin]

We did in fact merge Withdrawn and Abandoned as you suggested. Stagnant was added later to account for the reasoning above.

[MicahZoltu]

My preference on this topic is for someone to create a PR against EIP-1 that represents the workflow specified in the call and represented by the above flow chart. After that PR is merged, then someone (@axic?) can create a PR against EIP-1 that merges Stagnant and Withdrawn and introduces a reason field so we can avoid the politics that @MadeofTin mentioned in the above post.

I don't want to delay getting the broader changes integrated ASAP (hence my desire to merge as per the call and flowchart), though I also do generally agree with @axic that a single Withdrawn status with a reason field is better than having multiple statuses that mean "this EIP is no longer being actively pursued".

After both sets of changes are in (assuming agreement), editors/bots would only be able to move to to status: Withdrawn; reason: Stagnant or something, while authors would be able to move to status: Withdrawn, reason: no longer pursued by author or something.

[axic]

If the reason field is enacted anytime soon, I suggest the following values for the reason field:

• no activity
• by author

I think the main point of the stagnant idea is that people will somehow monitor eips.ethereum.org and will get notified that their draft moved to stagnant. There is no RSS feed for this, so they have to keep checking the site time to time. If there is an RSS feed I'm not fully sold people will subscribe to stagnant notification in case their EIP is moved there.

What was suggested here is that a PR is created marking something as status=Withdrawn reason="no activity or status=Stagnant. The automerger will notify the authors on this PR. Because authors will be notified, it makes very little difference whether it is stagnant or withdrawn, because the main point is that the author is notified and is given a chance to react.

(To clarify, it was mentioned that even for withdrawn the reason field must be displayed on eips.ethereum.org.)

We have also discussed to require at least a single author to have a github username, because otherwise the automerger bot is blocked. I think this a key question we need to address besides anything else. Right now there is a huge burden on the editors to track down authors who don't want to respond. Since the EIP workflow is centred around Github, requiring a github username and response in a reasonable timeframe is something we should have.

[poojaranjan]

As per the earlier discussions, there is a significant difference between abandoned and withdrawn

• Abandoned:  EIP is abandoned by the author but can be picked up by a champion to be pursued. The status can be changed to "Review" and will be back in the EIP process.

• Withdrawn: An EIP left by the author and can not be pursued by any champion. Status can never be changed and the Pull Request has to be closed (sooner the better).

An alternate proposal  -  add a new status "Deprecated" with a reason field. This will be in place of the earlier status "Rejected" which actually moved to the new Network upgrade process.

Any time an EIP is 'abandoned', it remains in the process. Anytime an EIP is 'withdrawn', it's status changed to "Deprecated" with a mention of the reason. This is important because there can be various reasons for an EIP to be marked as "Deprecated" and can be done by EIP editor/bot as long as they are adding a valid reason for it.

(Any proposal which is not going through the process has to be dropped to close the PR at some point. "Deprecated" Status
will make it easier to close the PR even by a Bot)

IMO this goes along with the current process without bringing much change. 

Status changes introduced will be 

1. Review - a new but justified status 
2. Deprecated (with a reason field) - instead of 'rejected' status, with the reason field to clearly state the reason -
   a) author's choice,
   b) no activity,
   c) failed to move to the next status.  
3. Active -> Living

(ignore, if it is too late for an alternate proposal)

[MicahZoltu]

I'm a fan of an iterative process to improving things, so it is never too late to submit ideas @poojaranjan. 😄

In general, I'm not a fan of changing the author on any EIP, even ones that are abandoned. I would rather see someone just create a new EIP where they are the author that is an exact copy of the original than have editors play a role where we re-assign authorship.

The one way I may be willing to go along with this is if we actively removed the authors on Abandoned EIPs as part of the abandonment process. That way it would be clear that we aren't giving away something that belongs to someone else, but rather when your EIP becomes abandoned you lose any authority over it.

---

I also don't see the of having an EIP that is withdrawn be permanently withdrawn if we allow abandoned to re-enter the lifecycle. Someone may have an idea, pursue it for a bit, then give up on it only to come back and want to pursue it a year later. By having Deprecated be a terminal status, I worry that we'll just be encouraging people to abandon their EIPs rather than Deprecate their EIPs since the latter is not permanent.

[poojaranjan]

Thank you for your comments @MicahZoltu , really appreciate it!

In general, I'm not a fan of changing the author on any EIP, even ones that are abandoned.

This is the current definition of "Abandoned" as per EIP-1, not my suggestion :)

And I feel comfortable with this because, in my mind, an EIP could be left abandoned for various reasons:

• Not reviewed for very long and the author finally loses interest or has moved on with other projects. This status is not proposed by the author but is assigned in his absence by an editor or a bot. (we've seen examples of 'sad' PR)
• The idea is liked by part of the community, hence proposed. But the author does not have time to pursue it has no problem being pursued by a champion (who later be added as an author, with the author's consent). The original author and EIP number remain the same and that helps the community to relate easily. (eg. EIP-1057)

I would rather see someone just create a new EIP where they are the author that is an exact copy of the original than have editors play a role where we re-assign authorship.

As I understood, this is the definition of 'Withdrawn' status that is proposed. Which seems like, EIP can not be resurrected but can be brought back to the system with a new number (as good as a new proposal).

I also don't see the of having an EIP that is withdrawn be permanently withdrawn if we allow abandoned to re-enter the lifecycle. Someone may have an idea, pursue it for a bit, then give up on it only to come back and want to pursue it a year later. By having Deprecated be a terminal status, I worry that we'll just be encouraging people to abandon their EIPs rather than Deprecate their EIPs since the latter is not permanent.

I think, 'Withdrawn' is a status that is proposed by the author itself and not because of inactivity but because of at least one 'reason' that is convincing enough (at least for the author) to take that decision. It could be anything

• technically not feasible
• some better proposal came up while his/her proposal is still in draft

These seem valid reasons to me. An author may decide to 'Withdraw' the proposal and I think the best place for such a proposal is to be terminated (if possible adding a reason field for people to know). eg. EIP-2583

(Edit: added link to screenshots for a quick reference.)

[MicahZoltu]

@poojaranjan In the latest EIPIP meeting (which was after your last comment here I believe) a lot of decisions were made and agreements were come to. I wanted to check to see if your latest proposal/statements in this thread are still something you are seeking to pursue or not before I take time to thoroughly review/discuss them.

[poojaranjan]

I suppose this has been sorted and the issue can be closed now.
cc: @axic @MicahZoltu @lightclient