Ring Formation EIP

Ring Formation EIP = _The intent of this document is to turn it into an EIP_ eip: <to be assigned> title: <EIP title> author: Boris Mann, Jason Civalleri, James Hancock, et al discussions-to: https://ethereum-magicians.org/t/process-for-ring-formation/747 status: Draft type: Meta created: 2018-07-16  This is the suggested template for new EIPs. Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`. The title should be 44 characters or less. ## Simple Summary  Defining a process for creating "Rings", the Ethereum equivalent of working groups. ## Abstract  Rings are the process in which we gather groups of individuals interested in collaborating together to document, interoperate, and advance standards around a particular focus. This gathers interested parties and experts in one place to move the creation of high-quality EIPs and implementation of running code. Rings will exist in two types: - Fields : Created to gather expertise and interested parties around a specific unifying Topic and designed to be non-expiring. (E.g. Wallets) - Working Groups : Created to address a specific problem or to produce one or more specific deliverables (a guideline, standards specification, etc.) and is ephemeral by design. (I.e. will desolve upon completion of its goals and achievement of its objectives.) It is expected that membership intermingle among Fields and that from Fields Working groups be formed and reformed as needed. These Rings can also be called upon to scale the Core Devs process, as it is understood that the necessary experts and interested parties have been gathered together and done work before approaching the Last Call process. Additionally, over time, high quality Rings can be called upon for comment or expertise, rather than all Core Devs needing to be experts in all topical areas. ## Motivation  Coming out of the Ethereum Magicians Council of Berlin, there is a desire to form Rings to aid in group forming and collaboration. Formalizing the process of forming / defining Rings is believed to ensure high quality groups with defined goals, as well as aiding in defining what resources are involved, where deliberations take place, and so on. ## Specification  > TO DO: define template of Rings -- organizers, abstract / scope, discussion venue(s), cadence of meetings, list of EIPs being worked on, and so on.* The formation of a Ring requires a charter which may be renegotiated periodically to reflect the current status, organization or goals of the Ring. Specifically, each charter consists of the following sections: #### Ring Name A Ring's name should be reasonably descriptive or identifiable. Additionally, the group shall define an acronym (maximum 8 printable ASCII characters) to reference the group in the Ring directories, forums, and general documents. #### Type - [ ] Field - [ ] Working Group #### Lead/s Leads are self selected and primary responible for admistration of the Ring on the Ethereum Magician's Forum. One or more are to be identified at the formation of a Ring and membership is expected to change overtime. No Ring should exist without a lead for a significant time. In the event that no volunteers step forward to become a Lead a Ring will be dematerialized. #### Magician's Forum URL Central location where most of the work of a Ring will be conducted. https://ethereum-magicians.org/c/working-groups/<name> #### Membership Configuration Rules Ring Leads are required to specifiy the configuration of groups within the Magician's Forum. The specified configuration, and any updates to it, are required to be public. There are no requirements for a specific configuration. The possible options are as follows. ![Discourse Groups Configuration](https://user-images.githubusercontent.com/509756/43865924-de2b0080-9b18-11e8-9cd1-4b0c6c92aecd.png) #### Ring Description The focus and intent of the group shall be set forth briefly. By reading this section alone, an individual should be able to decide whether this group is relevant to their own work. The first paragraph must give a brief summary of the problem area, basis, goal(s) and approach(es) planned for the working group. This paragraph can be used as an overview of the working group's effort. #### Relevant EIPs A list of current (if any) EIPs that are relevant to this Ring. EIPs may belong to one or more Rings and it is expected this list to be maintained and updated regularly. ## Rationale  The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> ## Backwards Compatibility  All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright. ## Test Cases  Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable. ## Implementation  The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. ## Copyright Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).