Changes to eligibility framework and member process

docs/4-roles-expectations.md

@@ -14,33 +14,54 @@ It should be noted that the Guild as an entity does not directly manage or parti
 
 ## 4.2 Members
 
-For the pilot, members of the Protocol Guild will have up to three different functions: [slot holders](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#slot-holders), [curators](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#curators) and [signers](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#signers).
+For the Pilot, members of the Protocol Guild will have up to three different functions: [slot holders](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#slot-holders), [curators](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#curators) and [signers](https://protocol-guild.readthedocs.io/en/latest/4-roles-expectations.html#signers).
 
 ### 4.21 Slot Holders
 
-Slot holders are members of the Guild who have qualified for a placement (slot) in the split contract. Estimated to be around 150-200 individuals, however the actual number may be higher or lower. There is no cap or target for number of slots. Slots can be set to any Ethereum address, including the individuals own, a charity, or another split contract.
+Slot holders are members of the Guild who have qualified for a placement (slot) in the split contract. Estimated to be around 150-200 individuals, however the actual number may be higher or lower. There is no cap or target for number of slots. Slots can be set to any Ethereum address, including the individual's own, a charity, or another split contract.
 
 #### Qualifications
 
-Members should be committed to Ethereum and its ethos of decentralization. The contributions of qualifying individuals should be:
+Note 1: these guidelines will change over time, i.e. become more restrictive in some places and more permissive in others.
 
-- Fully open source, ie. available for forking, modification and redistribution
-- Continuous for at least 6 months ahead of inclusion
-- Released under permissive licenses
-- Part of the protocol, not built on top of it, e.g. a specific client implementation vs. an application
-- Beneficial to the broader Ethereum community 
-- Dedicated to a permissionless, open access Ethereum
+Note 2: contributing to the projects/repos referenced below is necessary but does not guarantee Guild eligibility. While this list tries to be explicit by linking to example repos, there are some research areas which can't be linked to a single repo.
 
-It is possible for eligible individuals to work on a team which has a token, has VC backing or gives equity. However, members should expect these guidelines to change over time, i.e. become more restrictive in some places and more permissive in others.
+Qualifying contributions _must_ be:
 
-Though Ethereum is a highly technical field, it is clear that the work of non-developers around the core protocol is also crucial and should be eligible. This may include people affiliated with the All Core Devs call, those coordinating ecosystem upgrades, and anyone helping to coevolve the protocol alongside the community.
+- Fully open source, i.e. both “source available” and free to fork, modify, redistribute
+- The full focus of the individual (anything less receives a partial weighting, see [6.3 weighting](https://protocol-guild.readthedocs.io/en/latest/6-guidelines-for-regular-operation.html#weighting))
+- Continuous for at least 6 months ahead of inclusion and ongoing
 
-There may also be contributors to Protocol Guild itself whose work is significant enough to consider for membership. This work may include: 
+Qualifying contributions _must_ target at least one of the following projects/areas:
 
-- general comms/public presentations to improve awareness or explain the mechanism
-- fundraising from the broader ecosystem (eg. funding programs, individuals, larger entities who depend on Ethereum)
-- research related to the evolution of the Guild itself: smart contract architecture, surveys to members, documentation
-- internal maintenance for the Guild membership: helping with curation processes, onboarding/offboarding members
+1. Ethereum L1 core protocol maintenance and development
+
+- Production client implementations: Currently this includes [Erigon](https://github.com/ledgerwatch/erigon), [Geth](https://github.com/ethereum/go-ethereum), [Hyperledger Besu](https://github.com/hyperledger/besu), [Lighthouse](https://github.com/sigp/lighthouse), [Lodestar](https://github.com/ChainSafe/lodestar), [Nethermind](https://github.com/NethermindEth/nethermind), [Nimbus](https://github.com/status-im/nimbus-eth2), [Prysm](https://github.com/prysmaticlabs/prysm), [Teku](https://github.com/ConsenSys/teku)
+- Client testing/security/infra which supports these implementations: [ethereum/tests](https://github.com/ethereum/tests) [ethereum/execution-spec-tests](https://github.com/ethereum/execution-spec-tests)
+- Coordination related to upgrades and maintenance: [ethereum/pm](https://github.com/ethereum/pm)
+
+2. Research and implementation experiments related to potential protocol changes/refinements
+- [Verkle tries](https://github.com/gballet/go-verkle) (Verge)
+- [Portal Network](https://github.com/ethereum/portal-network-specs) (Purge)
+- EVM improvements: [Ipsilon](https://github.com/ipsilon)
+- Consensus work
+- Cryptography
+- Mechanism design
+- Resource pricing
+
+3. Spec work resulting from the above (should be implementation agnostic, unopinionated)
+- [Execution specs (EELS)](https://github.com/ethereum/execution-specs)
+- [Consensus specs](https://github.com/ethereum/consensus-specs)
+
+There may also be exceptional cases where members are added for contributing to Protocol Guild itself:
+- General comms
+- Fundraising
+- Research related to the evolution of the Guild itself
+- Internal maintenance for the Guild membership
+
+Independent or unaffiliated contributors are considered by the same guidelines as any contributors "officially" part of teams/projects.
+
+See [6.4 Modifying Projects and Members](https://protocol-guild.readthedocs.io/en/latest/6-guidelines-for-regular-operation.html#proposing-and-discussing-new-members) for guidelines on adding/removing eligible projects and members.
 
 #### Expectations
 

docs/6-guidelines-for-regular-operation.md → docs/6-operating-guidelines.md

@@ -1,4 +1,4 @@
-# 6. Guidelines for Regular Operation
+# 6. Operating Guidelines
 
 What follows is an outline for how we plan to start, recommendations, and guidelines for regular operation scenarios.
 
@@ -24,39 +24,41 @@ Antifragility and non-gameability emerge from simple frameworks. This limits the
   - `timeWeighting` can be either 1.0 for full-time or .5 for part-time contributors
   - Existing contributors get "diluted" as newcomers come in
   - Continuing contributors get additional weight per month they are active. This means historic contributors don't maintain their split weighting if they leave protocol development
-  - Anyone who stops contributing is removed from the split via periodic curation reviews
+  - Anyone who stops contributing should remove themselves from the membership, and may be removed via periodic curation reviews
 
-## 6.4 Proposing and Discussing New Members
+## 6.4 Modifying Projects and Members
 
-If current members believe that the set should be expanded to include another contributor, they should propose them well enough in advance of a membership update. This would mean at least a week. The process would look something like this:
+Modifying eligible projects and active membership should be proposed separately in the case both are being considered. Both should be shared with the membership at least two weeks in advance of any onchain update.
 
-1. An existing member (akin to an EIP champion) should send this info in the `proposed-members` channel.
+### Adding/removing Projects
+
+Changing the list of [eligible projects](link) can be made through a PR to the docs repo. This PR should add the project in the appropriate section, along with the following info:
+
+- Name of project/research area
+- Summary of why this project/research area should be considered eligible 
+
+### Adding Members
+
+Changing the current membership can be done by an existing member making a PR in the membership repo (currently private to members only). 
+
+When adding a new member, the PR should add the individual to the member list, along with the accompanying info:
 
 - Name / Identifier
-- Team / Project
-- Discord handle
+- Project
+- Discord handle 
 - Link to relevant work, eg. GitHub, research
 - Summary of their work and eligibility
 
-2. Discussion should be open for at least a few days to give members time to review and contribute to the discussion. This can be either with reacts on the proposal 👍 / 👎, ideally along with some written thoughts on why you think the proposed member fits the eligibility or not. Deliberations should strive to end in rough consensus, resorting to formal voting procedures only in rare extreme situations.
+Discussion should be open for at least one week to give members time to review and discuss. This can be with reacts on the proposal 👍 / 👎 or written thoughts on why the proposed member fits the eligibility or not.
 
-3. Once a positive consensus has been reached, the person can be contacted with the typical onboarding flow. 
+Once one week has passed, if no objections, the PR can be merged.
 
-If you are an existing core contributor that is not included, please contact an existing member to have them propose your work for consideration. 
+### Removing Members/adjusting weights/changing project affiliation
 
-We are exploring tools and methods to make this process more transparent, potentially through a forum for discussion and to maintain a public record of decisions.
+Ideally this PR should come from the member themselves, in keeping with the spirit and mutual trust of self-curation. Where this isn't possible, the member should be notified or tagged on the PR so they are aware of the changes.
 
 ## 6.5 Onboarding new members
 
 Eligible and confirmed members should be given an onboarding form link to be added to the split contract at the next quarterly update. They should also be added to the Protocol Guild's Discord and given the proper `Guild Member` / Team roles.
 
 When introducing the concept to potential members or onboarding accepted ones, it should be noted that the submitted address should refer to an individual's personal wallet and *not* their employer's. If teams were the atomic unit, all team members would have to agree on whether to accept or decline membership, likely decreasing the number of participants.
-
-## 6.6 Guild Contact
-
-It may be the case that there should be a Guild Contact for each team. The backstop is each team/project, who only need to confirm when a contributor has been added or removed. One member of each team/project (e.g. Lighthouse) should agree to be the point of contact responsible for ensuring other members are aware of any significant developments like:
-
-- Explaining membership obligations to new team members
-- Collecting addresses and signatures for inclusion in the eligible set
-- Migration to a new smart contract
-- A change to the weighting scheme

docs/index.rst

@@ -6,8 +6,6 @@ Protocol Guild
 - by maintaining an onchain registry of its membership
 - which allows ecosystem sponsors to directly fund the membership, their work, the public good.
 
-Members are from EF DevOps, EF Geth, EF Ipsilon, EF JavaScript, EF Portal, EF Protocol Support, EF Research, EF Robust Incentives Group (RIG), EF Security, EF Testing, Erigon, Ethereum Cat Herders, Hyperledger Besu, Independent, Lighthouse, Lodestar, Nethermind, Prysmatic, Status, Teku, and TXRX.
-
 *"And, Ebling, there's another, greater purpose. Hari Seldon founded two Foundations three centuries ago; one at each end of the Galaxy. You must find that Second Foundation."* Foundation, Isaac Asimov
 
 Sponsor the Pilot