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

_specs/ecip-1000.md

@@ -131,7 +131,7 @@ Each ECIP must begin with an RFC 822 style header preamble. The headers must app
 - **Comments-Summary:** (summary tone)
 - **Comments-URI:** (links to wiki page for comments)
 - **Status:** (Draft | Last Call | Accepted | Final | Deferred | Replaced | Rejected | Withdrawn)
-- **Type:** (Standards Track | Informational | Process)
+- **Type:** (Standards Track | Informational | Meta | Fork)
 - **Created:** (date created on, in ISO 8601 (yyyy-mm-dd) format)
 - **License:** (abbreviation for approved license(s))
 - **License-Code:** (abbreviation for code under different approved license(s))
@@ -150,7 +150,7 @@ If there are multiple authors, each should be on a separate line following RFC 2
 
 While an ECIP is in private discussions (usually during the initial Draft phase), a`Discussions-To` header will indicate the mailing list or URL where the ECIP is being discussed. No `Discussions-To` header is necessary if the ECIP is being discussed privately with the author.
 
-The `Type` header specifies the type of ECIP: Standards Track, Informational, or Process.
+The `Type` header specifies the type of ECIP: Standards Track, Informational, Meta, Fork.
 
 The `Created` header records the date that the ECIP was assigned a number.
 
@@ -172,6 +172,7 @@ There are three types of ECIP:
   - **Interface** - improvements around client [API/RPC] specifications and standards, and also certain language-level standards like method names  and contract ABIs.
   - **ECBP (Ethereum Classic Best Practice)** - application-level standards and conventions, including contract standards such as token standards, name registries, URI schemes, library/package formats, and wallet formats.
 - A **Meta ECIP** describes a **process** surrounding Ethereum Classic or proposes a change to (or an event in) a process. Process ECIPs are like Standard Track ECIPs, but apply to areas other than the Ethereum Classic protocol itself. They may propose an implementation, but not to Ethereum Classic's codebase; they often require community consensus; unlike Informational ECIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process (e.g. this ECIP-1000 process document), and changes to the tools or environment used in Ethereum Classic development. *Any meta-ECIP is also considered a Process ECIP.*
+- A **Fork ECIP** describes a feature set and a block activation number for those features to become active on one or more blockchains. For specification and process standards, see [ECIP 1077](./_specs/ecip-1077.md).
 - An **Informational ECIP** describes an Ethereum Classic design issue, or provides general guidelines or information to the Ethereum Classic community, but does not propose a new feature. Informational ECIPs do not necessarily represent Ethereum Classic community consensus or a recommendation, so users and implementors are free to ignore Informational ECIPs or follow their advice.
 
 It is highly recommended that a single ECIP contain a single key proposal or new idea. The more focused the ECIP, the more successful it tends to be. A change to one client doesn't require an ECIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.

_specs/ecip-1077.md

@@ -0,0 +1,102 @@
+---
+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: WIP
+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. _Fork_ ECIPs should follow this process:
+- A "shell" Fork ECIP is opened, fitting the [template provided](TODO). 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 criticiziing, etc...
+- One change set is merged to modify the Fork ECIP, yielding a COMPLETE and UNIQUE hard fork specification document.
+
+### Definition
+
+Fork ECIPs are defined as ECIPs specifying PROTOCOL ACTIVATION of any one or more Standards-Core track ECIP(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 ECIP or ECIP-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.
+
+### 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 ECIPs 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: The blockchain's next hard fork.
+
+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.