EIPs
EIPs copied to clipboard
Update EIP-1: Add adoptable field
Reopening the discussion from #5463.
I merged without waiting for sufficient consensus, so I've reverted that PR, and opened this one.
🛑 eip-review-bot failed for an unknown reason. Please see logs for more details, and report this issue at the eip-review-bot repository.
@eth-bot rerun
I don't think this provides much value. It should simply be left up to editor discretion if a stagnant EIP can be reassigned. And I generally don't think that should happen unless the original author agrees.
I generally don't think that should happen unless the original author agrees.
This flag is basically the author in advance stating "Yes, I am okay with someone else taking over this proposal." EIP Editors still have to approve to move it out of stagnant.
Also - this flag is optional. Anyone can choose to not have their EIP adoptable.
I am, as usual, torn on this proposal.
I dislike reassigning proposals to new authors, but I equally dislike abandoning a well-known EIP number just because the authors can't be reached.
I would feel more comfortable if the authors opt-in to the adoption process over just reassigning without their permission.
I would feel more comfortable if the authors opt-in to the adoption process over just reassigning without their permission.
Should the adoptable field be by default set to false then?
@SamWilsn @lightclient is this better?
I would feel more comfortable if the authors opt-in to the adoption process over just reassigning without their permission.
Should the adoptable field be by default set to false then?
IMO, if the adoptable field is missing, the EIP should not be reassigned without permission but the EIP template should have adoptable: true.
IMO, if the adoptable field is missing, the EIP should not be reassigned without permission but the EIP template should have adoptable: true.
I agree with this. This was in fact my original idea. I'm not sure how it ended up being an "if it's missing then it defaults to true" situation, but it's fixed now.
I prefer to let EIPs be "rehomed" solely at the discretion of the editors.
I prefer to let EIPs be "rehomed" solely at the discretion of the editors.
This enables this :)
Previously, it requires both editor and author approval. If EIPs opt-in to adoption, then authors are no longer required. But editors are obviously still required.
It doesn't require authors approval. The editors can already unilaterally reassign an EIP. We haven't done this before (AFAIK) and we try to get author consent, but we do have the ability to reassign.
@lightclient I know that is for the good intention of community.
but I respectfully disagree with the assertion that editors as a group (individually or together) shall have the power to unilaterally reassign EIP. I think editors reserve the power to decline an EIP to be published, but reassign right seems beyond its governing power.
I agree with @xinbenlv here. Adoptability should either be opt-in or opt-out, but some control should be given to authors.
It doesn't require authors proval. The editors can already unilaterally reassign an EIP. We haven't done this before (AFAIK) and we try to get author consent, but we do have the ability to reassign.
It does require the authors' approval. It's just done in advance of the EIP becoming stagnant.
Also, I'm not sure what's up with the stagnant bot. Why wasn't it reminding us?
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Would still like this.
As I've said multiple times in this thread and on EIPIP, I don't think this is a good idea. I would rather leave it up to editor discretion.
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Dismissing stale bot.
I don't understand why you're dismissing the stale bot. I don't think this should be merged. Are we just going to have it sit here open forever?
I don't understand why you're dismissing the stale bot. I don't think this should be merged. Are we just going to have it sit here open forever?
I want to remind everybody that this still exists, and that I am still actively interested in pursuing it.
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Bump!
There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.
Bumpity boop!
Since enough people objected, I've set the adoptable entry in the template to be default-false, so that new EIPs are opt-in instead of opt-out.
This is a reminder: existing EIPs are, have been, and will always be opt-in.
The commit 6be8d02c507115f52f00775084a369981acdb145 (as a parent of 303a47f24744ee7243fa7d81714a5a887437ee25) contains errors. Please inspect the Run Summary for details.