-
Notifications
You must be signed in to change notification settings - Fork 62
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECIP-1000: ECIP Process #58
Comments
@sorpaas I'm also thinking it might prove useful to adopt other improvement proposals and rebrand them as ECIPs with proper references to original authors and the original URLS. For example, if we adopt an EIP, we can just label it as an ECIP-E. If we adopt an ECLIP, we can just label it as an ECIP-L. Naturally, then ECIPs are original community written proposals and the lettering applies to external improvement proposals. |
So, now I am in here too. The general idea from @YazzyYaz is good. A one thing to this: The chosen acronym should be clear, to exclude the double interpretation. |
I will contribute some d3.js viz code based on it , wait me ^^ |
Thanks for starting the discussion @sorpaas . I'm not familiar with the assigning a number part. Do we mean that when a PR is ready we tell the author to change the filename of the ECIP and the auxiliary files to include the number and then merge?
The links for these examples are dead (so are some other things like the process image but this can be fixed later). What I wanted to mention here is that if openrpc becomes a thing perhaps we should encourage the node clients to add the the ECIPs implemented as some sort of metadata (if anyone is interested in what i'm talking about here is the ECLIP etclabscore/ECIPs#3). I'm guessing this would be another update to the process later |
Yes. If we follow the process strictly, the author will first name the spec In practice it's mostly alright if we just let the author of the ECIP to assign the number by him/herself -- EIP uses the number same as the Github PR number, and for ECIP we previously use the next available one. I will update this ECIP to reflect this. |
Thank you Wei for creating this issue. I don't understand why there is ECLIP? What is the necessity to create a new protocol improvement standard for ETC? |
I agree to move this ECIP to I also agree to add @sorpaas, @isaac, @realcodywburns , and @soc1c as editors. I recommend to add: |
@tokenhash I think we'd better look for developers to be on the editors list. I agree @phyro and @kimisan have contributed a lot, but they may not be able to help a lot in the case of technically reviewing ECIPs. My only objections for adding @BelfordZ and @shanejonas is that we may then have too many representatives from ETCLabs (we already have two -- @isaac and @soc1c). But that's just my opinion and it's up to everyone. |
Agreed, if they are not devs, but I thought they were. |
Both me and Kimi are devs, but to actually give a meaningful comment, you need to have the background of how Ethereum protocol exactly works. I don't really have the background needed to give a reasonable comment for many of the ECIPs. I'll still comment on the ECIPs that I do understand so that's fine from my side 👍 |
(If they're okay with editor responsibilities and self-identify as devs.) |
The ECIP editor simply needs to make sure the ECIP is properly formatted and curate the ECIP through the process with the author. Even if the Editor feels the context is technically unsound or likely to be rejected, they're commited is to curate the ECIP not be technical gateways. E.g.: Existing cold-staking and treasury ECIPs in the repo here. |
Taking the comment here from discord; RE: I'd like to be added as editor. |
FYI, I merged the draft initial list #94. If you want to add yourself or add others as editors, please just open a new PR against master branch! |
Can we close this issue now, @sorpaas? It was merged. |
Rendered
An Ethereum Classic Improvement Proposal (ECIP) is a design document providing information to the Ethereum Classic community, or describing a new feature for Ethereum Classic or its processes or environment. The ECIP should provide a concise technical specification of the feature and a rationale for the feature.
We intend ECIPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Ethereum Classic. The ECIP author is responsible for building consensus within the community and documenting dissenting opinions.
Because the ECIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
The text was updated successfully, but these errors were encountered: