ECIP-1077: Meta Specification Establishing Fork ECIPs (Using Pull Request development pattern)

[meowsbits]

TL;DR

Make ECIPs with Type Fork a thing, where Fork ECIPs should follow this process:

• A "shell" Fork ECIP is opened, fitting the template provided. This ECIP does not initially include Activation Block Number or Features specifications.
• While in WIP or Draft status, one or more change sets are proposed against this document (eg. via Github Pull Requests) modifying BOTH Activation Block Number and Features specifications.
• ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive critique, etc...
• One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document, and status is moved to Last Call. By virtue of the process specification provided, a Fork ECIP achieving Last Call may not see Draft nor WIP status again (because doing so would require a merging a change set holding INCOMPLETE specification variables).

---

Related to and building from #223 , #222 , #221, #219 .

---

Discussion preamble from the author

This specification requires that Fork Features and Activation numbers are handled inextricably, and that once merged a Fork specification ECIP becomes finalized.

There are some important cases and implications to consider for this:

• If, say, a Fork ECIP specification is finalized (having been fully specified with Activation Block Number and Feature Set via a merged change set)... BUT subsequently a bug is found during testing causing a loss of confidence in sucessfully achieving the fork at the specified block number, then the Fork ECIP would want to be Deferred or Withdrawn or Rejected, and then eventually replaced with a new UNIQUE ECIP containing a revised Activation Block Number and possibly also Feature Set parameters.

• Change sets (here, Pull Requests) are expected to take on a more considerable role for Fork specification development; proposed Feature Set + Activation schedule should be documented explicitly and then discussed relatively. Sensible use of Github's linking tools (Issue/PR references) should be used liberally, and it would probably be good establish a practical naming scheme for proposed Fork ECIP modifications (eg. FORK-ECIP-9999 Spec: <My features> @ <My block>)

[sorpaas]

Probably also states that those PRs should not be merged until the community consensus is reached?

[meowsbits]

I would prefer not to mention or even begin to tangle with that idea. I'm interested here only in tangible, describable mechanics.

(Including that idea might provoke questions like "What is that?" ...Which I would prefer to leave as a dubious an ambitious project for another very very brave soul to tackle in a different place at a different time.)

[sorpaas]

@meowsbits Yeah I understand. But what should editors do when multiple changesets are present? I just think no matter what we choose, the process specification must state this clearly.

[meowsbits]

Let me think about this. I will sleep on it and get back to you tomorrow.

[meowsbits]

I'm leaning toward keeping this document as "mechanic" as possible; to describe only "the physics" of ECIP process events. ... 😸 I want to help program and code the event-based system; but not to provide the type definitions or factory for providing those events... yet )).

Pull requests are getting merged already, somehow. ECIPs are changing status already, somehow. Human "consensus"/decision-making (either as a potential specification or as practical tradition) has important impacts for this repository's specifications including, but certainly not limited to, this one.

If you feel strongly a need to specify and document how "human consensus" does or should happen in a given case, then I would suggest we do so in a separate concern.

I am -- as always -- open to further discussion, especially if you would (please 💟 ) propose a change set we can use a concrete reference point.

[meowsbits]

@sorpaas See #224 (comment) for a draft meant to show a change that might fit your intention here.

[meowsbits]

If, say, a Fork ECIP specification is finalized (having been fully specified with Activation Block Number and Feature Set via a merged change set)... BUT subsequently a bug is found during testing causing a loss of confidence in sucessfully achieving the fork at the specified block number, then the Fork ECIP would want to be Deferred or Withdrawn or Rejected, and then eventually replaced with a new UNIQUE ECIP containing a revised Activation Block Number and possibly also Feature Set parameters.

This implies that as discussion and review and popularization of proposed specification change sets show narrowing in apparent probable outcomes (in the minds of developers and protocol-managing project owners) that material implementations should be underway and enduring analysis and testing so that adequate and informed block numbers and any specification parameter details can be shaped and inform the developing proposals.

In my mind this is a healthy approach: It encourages active and specification-participating research and design, prototype implementations, team coordination, and stakeholder outreach as a necessary part of the process of developing acceptable Fork ECIPs. This might work to facilitate and foster collaboration between teams and professional contexts and advocates and critics alike, while also hopefully continuing to build and prove rubrics for analysis and evaluation of proposals.

Rough consensus (wikipedia) is used in ECIP Meta specifications. From the Wikipedia article:

The phrase is often extended into the saying "rough consensus and running code"

In my mind, this proposal encourages a nudge in this direction, which I think has positive and constructive potential for framing our Fork ECIP processes.

[meowsbits]

Just posting a potential revision that I think might fit @sorpaas' intentions w/r/t to discussion at #224 (comment).

Suggested change

- ... Stuff happens; there are comments, emails, meetings, bribes, blogs, bragging, trolling, haranguing, arguing, debating, pondering, editing, compromising, constructive criticiziing, etc...

- _Rough consensus_ (keyword: see [definition](https://github.com/ethereumclassic/ECIPs/blob/c87f1828bd3d13ae5505f229207b65079a2de915/_specs/ecip-1000.md#L205) and [uses](https://github.com/ethereumclassic/ECIPs/search?q=rough+consensus&unscoped_q=rough+consensus)) is achieved and a single change set is explicitly approved by [ALL acting ECIP Editors](https://github.com/ethereumclassic/ECIPs/blob/c87f1828bd3d13ae5505f229207b65079a2de915/_specs/ecip-1000.md#ecip-editors).

[bobsummerwill]

I don't strongly oppose this, @meowsbits.
Wonder if we need to be this explicit?

I like @shanejonas's suggestion here too, and think it might be enough:
#221

I am just a little wary of OVER constraint in reaction to a series of silly events which, were they to happen again, could just be headed off socially.

[meowsbits]

@bobsummerwill I understand your concern.

Here's why I think being explicit is important:

• One of the opposing argument sets that came up in this latest flurry is "This is the way we've always done it" vs. "This is what the procedure should technically be". This attempts to clarify, not constrain, a hopefully healthy and accessible pattern for collaboration.
• All creative and especially collaborative constructive projects need constraints in order to structure and direct growth. This intends to serve that purpose, offering a concrete structural framework within which any specification proposals can fit.
  • With this, it makes the process more accessible to newcomers/forgetful people/anyone, who won't have to be "taught the wisdom of yore" in ethereal Discord chats, and can instead find participation guidelines documented concretely.
• could just be headed off socially. I agree that this is an optimistic and ideal scenario. But this ideal depends on good and available leadership and mutual collaborative attitudes, which can not be taken for granted in an intentionally decentralized an decentralizing community. Relying on the availability of certain social dynamics and/or certain personalities in this space is a not a robust a system. Do you imagine it would be your job to guarantee elimination of "silly" social behavior? To squelch every potential conflict before it grows horns?
• a series of silly events . This may be. But aside from "silly" bickering we are now looking at a maybe-seriously-silly Fork specification (either 1061 or 1072) which potentially gives rise to an important security flaw, which arguably is, at least in part, caused by a failure to consider the proposed set of included ECIPs as a whole.

If we can accept this proposed collaboration pattern, what would the cost be of adopting it, versus continuing with tacit traditions?

[bobsummerwill]

Great arguments, @meowsbits.
Makes sense to me to clarify in this way.
Let's do it.
Thanks for the extra thought process.

[meowsbits]

I'm not interested in pursuing this proposed change anymore, and have moved the status to Withdrawn. @ethereumclassic/ecip-editors please review for the merge for the sake of documentation.

[realcodywburns]

Ack

[q9f]

Merging for the sake of documentation.