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

_specs/ecip-1077.md

@@ -0,0 +1,144 @@
+---
+ecip: 1077
+title: The Meta Fork ECIP: Establishing _Fork_ type ECIPs and their specifications and processes
+author: Mr. Meows D. Bits
+discussions-to: TBD
+status: Withdrawn
+type: Meta
+created: 2019-11-29
+---
+
+### Abstract
+
+Establishing _Fork_ type ECIPs, and their standards and processes.
+
+#### 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 named `ecip-X-FORK.md`](../ecip-X-FORK.md) (available in the repository root directory). 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). 
+
+### Definition
+
+Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track IP(s) at a specified activation block number.
+
+#### Standards
+
+Fork ECIPs should contain only placeholder information for ECIP-sets and block activation numbers while in `WIP` or `Draft` status. 
+
+Modification to any of `Last Call`, `Accepted`, or `Final` statuses should be accompanied by the introduction (merge) of a single change set containing COMPLETE and UNIQUE definitions of the placeholder values.
+
+Change sets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither value in isolation; change sets modifying only ECIP-set values, or only block number values, are disallowed.
+
+### Motivation
+
+Fork ECIPs represent a single idea: The next hardfork the blockchain is expected to undergo. This is a pragmatic and common approach to managing blockchain protocol maintenance and upgrades. 
+Thus, it makes sense to use accessible and conceptually-unifying procedures for this challenge.
+
+- __Accessibility__: Github provides an accessible user interface for viewing a Pull Request (proposed change set) against a single document.
+
+- __Legible and Communicable Reasoning__: Requiring UNIQUE and COMPLETE change sets against against a Fork type ECIP demand presentation and consideration of proposed specifications as a whole.
+
+- __Sufficient specification__: It is the job of Fork ECIPs to eventually provide precise and operable implementation specifications. Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation. Any Fork ECIP lacking a COMPLETE feature set or block number is considered incomplete.
+
+- __Efficiency__: Unique proposals save time and energy.
+
+#### Historical motivations
+
+Related to and derivative of:
+
+- https://github.com/ethereumclassic/ECIPs/issues/217
+- https://github.com/ethereumclassic/ECIPs/issues/215
+- https://github.com/ethereumclassic/ECIPs/issues/175
+- https://github.com/ethereumclassic/ECIPs/issues/131
+- https://github.com/ethereumclassic/ECIPs/issues/177
+- https://github.com/ethereumclassic/ECIPs/issues/135
+- https://github.com/ethereumclassic/ECIPs/pull/218
+- https://github.com/ethereumclassic/ECIPs/pull/212
+- https://github.com/ethereumclassic/ECIPs/pull/207
+- https://github.com/ethereumclassic/ECIPs/pull/214
+- https://github.com/ethereumclassic/ECIPs/pull/199
+- https://github.com/ethereumclassic/ECIPs/pull/196
+
+### Specification
+
+A Fork ECIP is defined as an ECIP specifying any (`n >= 1`) Standards-Core track IP or IP-set and a block activation number for this set. A Fork ECIP should be conceptually complete and unique (note that _Next hardfork_ suffices for the existing preference for ECIP uniqueness, since it is intended that there only be one at a time -- hopefully!).
+
+_Complete_ is defined as being fully and totally definitive; not lacking anything.
+
+_Unique_ means not the same as another thing; in this case, not precisely duplicating any existing ECIP.
+
+This proposal specifies that all Fork ECIPs in `Draft` state or earlier should contain NO information about ECIP-sets or block activation numbers (all `TBD`). Proposed specifications to fill these placeholders should be made in the form of distinct and separate propsed change sets (eg Github Pull Requests) to the Fork ECIP document. The changesets are required to be UNIQUE and COMPLETE.
+
+There might be an `ecip-X-FORK.md` file that would look something like this:
+
+```
+---
+lang: en
+ecip: <ECIP number>
+title: <ECIP title>
+author: <list of authors' real names and optionally, email addrs>
+discussions-to: <email address>
+status: <WIP | Draft>
+type: Fork
+created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+replaces: <ECIP number>
+superseded-by: <ECIP number>
+resolution: <url>
+---
+
+### Abstract
+
+Specifying a next hardfork for the following networks:
+
+- <Network Name or Identifier>
+- <Network Name or Identifier>
+
+### Motivation
+
+### Specification
+
+- __Block Activation Number(s)__: 
+  + <Network Name or Identifier>: `TBD`
+  + <Network Name or Identifier>: `TBD`
+
+- __Feature specification(s)__:
+  + TBD
+
+### Rationale
+
+### Implementation
+
+### Copyright/Licensing
+```
+
+### Rationale
+
+The sole purpose of a Fork ECIP is to join a block number (activation block) with a set of `n >= 1` Standards-Core type IPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment."
+
+0. "Shell" format Fork ECIPs represent a clear, albeit abstract, idea: One or many blockchains' next hard fork (eg. chains Ethereum Classic, Morden, Kotti).
+
+1. __Demanding fully-formed Fork ECIP Changeset proposal forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Fork ECIP Changeset may represent a plurality of features, and so in order to be an _operable_ specification it should not represent an ambiguous set. Sets of ECIPs can have interoperative dependencies and outcomes; this causes a conceptual permutation and combination challenge when attempting to design a set of ECIPs for simultaneous inclusion. The intention of this specification is make these logical steps as explicit and document and accessible as possible, in order that good decisions can be made with a process of open and constructive collaboration, enabled by named and concrete options.
+
+2. __Fork ECIP Changesets without block numbers lack operability.__ Activation numbers _are specifications_ and should not be treated as a second class or at-convenience citizens. Implementation timelines are importantly related variables to their adjacent ECIP-sets (large set ostensibly require long timelines, hotfix sets require short ones.) We cannot reason about them in isolation.
+
+3. __Concrete things are easier to build language and reasoning around.__ Nuances of interoperations are documented and included in concrete proposals, leaving less theoretical abstract reasoning to manage, which is relevant in the context of group _and_ individual decision making. "Competing" Fork ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes.
+
+#### Alternatives considered
+
+Use distinct UNIQUE and COMPLETE ECIPs to describe fork specification options.
+
+However, allowing fully-formed alternative and "competing" ECIPs is logistically and practically difficult to use. 
+Currently, our most prominently used collaboration tool, Github, does not provide an accessible UI for comparing arbitrary documents or review separate arbitrary documents as a conceptual set.
+
+### Implementation
+
+A Fork ECIP should achieve `Last Call` as a change set has been successfully merged. Conversely, a Fork ECIP with non-empty specifications may not see `Draft` or `WIP` status; it may only otherwise be `Final`, `Withdrawn`, or `Rejected`.
+
+This proposed procedure makes only marginal conceptual changes to existing practices, demanding only that what was taken as implication, subtext, or context before now be made explicit. Rather than reviewing actual-or-theoretical proposed changesets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Fork ECIP specification outcomes to assume fully qualified and standardized formats before becoming eligible for consideration. 
+
+### Copyright/Licensing
+
+MIT.