Skip to content
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

Closed
sorpaas opened this issue Feb 27, 2019 · 16 comments
Closed

ECIP-1000: ECIP Process #58

sorpaas opened this issue Feb 27, 2019 · 16 comments
Labels
type: meta ECIPs of type "Meta" - bundling proposals for upgrades.

Comments

@sorpaas
Copy link
Contributor

sorpaas commented Feb 27, 2019

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.

@YazzyYaz
Copy link
Contributor

@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.

@TheEnthusiasticAs
Copy link
Member

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.

@kimisan
Copy link
Member

kimisan commented Feb 27, 2019

I will contribute some d3.js viz code based on it , wait me ^^

@phyro
Copy link
Member

phyro commented Feb 27, 2019

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?

Software authors are encouraged to publish summaries of what ECIPs their software supports to aid in verification of status changes

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

@sorpaas
Copy link
Contributor Author

sorpaas commented Feb 28, 2019

@phyro

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?

Yes. If we follow the process strictly, the author will first name the spec ECIP-description-of-functionality.md. The editors will then assign a number to the ECIP, and change the filename.

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.

@realroyzou
Copy link
Member

realroyzou commented Mar 2, 2019

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?

@ghost
Copy link

ghost commented Jun 27, 2019

I agree to move this ECIP to Final Call.

I also agree to add @sorpaas, @isaac, @realcodywburns , and @soc1c as editors.

I recommend to add:

@phyro @kimisan @YazzyYaz @BelfordZ @shanejonas

@sorpaas
Copy link
Contributor Author

sorpaas commented Jun 27, 2019

@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.

@ghost
Copy link

ghost commented Jun 27, 2019

Agreed, if they are not devs, but I thought they were.

@ghost
Copy link

ghost commented Jun 27, 2019

Agreed, with balancing the devs from ETC Labs to other teams.

Maybe @elaineo and @mikeyb want to join.

@phyro
Copy link
Member

phyro commented Jun 27, 2019

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 👍

@sorpaas
Copy link
Contributor Author

sorpaas commented Jun 27, 2019

(If they're okay with editor responsibilities and self-identify as devs.)

@stevanlohja
Copy link
Contributor

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.

@YazzyYaz
Copy link
Contributor

Taking the comment here from discord; RE: I'd like to be added as editor.

@sorpaas
Copy link
Contributor Author

sorpaas commented Jun 28, 2019

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!

@realcodywburns realcodywburns added the type: meta ECIPs of type "Meta" - bundling proposals for upgrades. label Oct 23, 2019
@bobsummerwill
Copy link
Member

Can we close this issue now, @sorpaas? It was merged.

@sorpaas sorpaas closed this as completed Dec 1, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: meta ECIPs of type "Meta" - bundling proposals for upgrades.
Projects
None yet
Development

No branches or pull requests

9 participants