Skip to content

Meta Meta Specification for Forking Meta ECIPs (Use Pull Requests version) #223

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.

Sign up for GitHub

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

Closed
meowsbits wants to merge 6 commits into from
Closed

Meta Meta Specification for Forking Meta ECIPs (Use Pull Requests version) #223

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
4ef35f9
Introduce alternative approach; use PRs
meowsbits Nov 30, 2019
cf85164
Fix typo
meowsbits Nov 30, 2019
1845515
Use assigned ECIP number 1077
meowsbits Nov 30, 2019
e8c68d8
Rename ECIP file to reflect assigned number (1077)
meowsbits Nov 30, 2019
ec70aa2
Revert "Rename ECIP file to reflect assigned number (1077)"
meowsbits Nov 30, 2019
a81b724
Revert "Use assigned ECIP number 1077"
meowsbits Nov 30, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
34 changes: 22 additions & 12 deletions _specs/ecip-_.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,23 @@ resolution: TBD

### Abstract

Forking Meta ECIPs (defined as Meta ECIPs specifying any Standards-Core track ECIP and an activation block number) should be complete and unique.
Forking Meta ECIPs (defined as Meta ECIPs _intended_ to specify any Standards-Core track ECIP and an activation block number) should contain only placeholder information
Copy link
Copy Markdown
Contributor

@sorpaas sorpaas Nov 30, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can actually give "Forking Meta ECIPs" a new category. A lot of people have pointed out that hard fork ECIPs does not nicely fit in "meta" category.

Copy link
Copy Markdown
Member Author

@meowsbits meowsbits Nov 30, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting idea. Have taken a first swing at this with #224.

for ECIP-sets and block activation numbers. Placeholders for ECIP-sets and block numbers should be filled via distinct change sets before moving from `Draft` to `Last Call` status.

Changesets (eg Pull Requests) editing placeholder ECIP-set and block number information should do so with neither in isolation; PRs modifying only ECIP-set, or only block number,
are disallowed.

### Motivation

Incomplete proposals are inoperable; they are not ready for review, discussion, nor implementation.
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.

Github does, however, provide an accessible user interface for Pull Requests (propsed change sets) against a single document.

Forking Meta ECIPs represent a single idea: The next hardfork. This is a pragramtic and common sense approach to managing blockchain protocol maintenance and upgrades. Thus, it makes
sense to use accessible and conceptually-unifying procedures for this challenge.

Incomplete proposals (changesets) are inoperable; they are not ready for review, discussion, nor implementation.

Unique proposals save time and redundant complexity.

Expand All @@ -36,33 +48,31 @@ Related to and derivative of:

### Specification

A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be complete and unique.
A Forking Meta ECIP is defined as a Meta ECIP specifying any (`n >= 1`) Standards-Core track ECIP or ECIP-set. A Forking Meta ECIP should be conceptally complete and unique (_next hardfork_ suffices for uniqueness, since there can only be one).

_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 Forking Meta ECIPs should be COMPLETE and UNIQUE; essentially disallowing `Draft` status Forking Meta ECIPs and and/or meaningful revisions (set ECIPs, block number).

This implies that a valid Forking Meta ECIP must contain a full and complete set of to-be included ECIPs, and a definitive block number.
This proposal specifies that all Forking Meta 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 Forking Meta ECIP document. The changesets are required to be UNIQUE and COMPLETE.

### Rationale

The sole purpose of a Forking Meta ECIP is to join a block number with a set of `n >= 1` ECIPs containing protocol-facing changes. The document says "_These_ features will activate at _this_ moment."

0. __Fill-in-the-blank ECIPs are not in good form.__ Forking Meta ECIPs are themselves ECIPs, and their job is to define, with certainty and clarity, technical specifications. Forking Meta ECIPs that essentially leave either field `Block number` and/or field `ECIP set` blank are functionally useless (inoperable); they say only: "(I/we) propose to have some fork at some time." An analogue of blankness to non-Forking-Meta ECIPs would essentially say "TODO: put my next awesome feature specification here."
0. "Shell" format Forking Meta ECIPs represent a clear, albeit abstract, idea: The blockchain's next hard fork.

1. __Demanding fully-formed Forking Meta ECIP proposals forces authors, editors, and reviewers to evaluate and document ECIP-set behavior and enables concrete discussion of feature sets as complete wholes.__ A Forking Meta ECIP 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.
1. __Demanding fully-formed Forking Meta 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 Forking Meta 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.

2. __Forking Meta ECIPs 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.
2. __Forking Meta 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 ECIPs 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" Forking Meta ECIP alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes.
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" Forking Meta ECIP Changeset alternatives become explicit and standardized, yielding conceptual and communicable clarity in review processes and decision-making processes.

### Implementation

A Forking Meta ECIP may not be in `Draft` status. It may not undergo any meaningful changes once receiving `Last Call` status (its next status beyond `WIP`).
A Forking Meta ECIP may only achieve `Last Call` status once a Changeset has been accepted and all other alternative marked as `Deferred`, `Withdrawn`, or `Rejected`.

Procedurally, compared to the historical and traditional practice of opening an essentially empty Forking Meta ECIP and working to fill in blanks, this proposed procedure makes only marginal and changes, demanding only that what was taken as implication, subtext, or conteext before now be made explicit. Rather than reviewing actual-or-theoretical proposed change sets to an ECIP (which sadly, have historically usually been theoretical), this forces proposed Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration.
This proposed procedure makes only marginal and changes, 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 Forking Meta ECIP alternative outcomes to assume a fully qualified and standardized formats before becoming eligible for consideration.

### Copyright/Licensing

Expand Down