remove solidity contributors #80
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are now at the end of the 12 month Pilot. As such, we should close the loop on some previous discussions related to member eligibility and Solidity:
The first Github link has the most substantive discussion. In summary, our membership should be consistent with how our own documentation describes eligibility: strictly related to the core protocol and its ongoing stewardship. While smart contract languages are important for the long term success of Ethereum / the EVM, they are not part of the core protocol. Solidity is the only smart contract language with PG members; not Vyper, Fe, Huff, etc. Further, this also doesn’t consider other crucial adjacent developer tooling, like dev environments and libraries.
Maintaining this discrepancy past the end of the Pilot will reduce the credibility of the Guild’s claims regarding accurate curation according to our own self-defined internal processes.
This PR removes three existing Solidity contributors: @ekpyron @hrkrshnn @cameel. I have reached out in advance and communicated this to them. This has nothing to do with these individuals or their work, and I personally appreciate their participation in the PG experiment over the last ~12 months.
To be clear - this isn't a unilateral decision being handed down, I'm posting this proposal as an individual member. If there are holes in my reasoning, please give me pushback!
As an aside - In my personal capacity, I fully support dev tooling contributors exploring a PG analogue for their domain, and happy to provide guidance if needed.