Skip to content
This repository has been archived by the owner on Jul 14, 2023. It is now read-only.

Member Request #19

Closed
wants to merge 1 commit into from
Closed

Member Request #19

wants to merge 1 commit into from

Conversation

cmichi
Copy link

@cmichi cmichi commented Sep 27, 2022

Hi there,

I'm Michi, I'm one of the lead developers at Parity Technologies. I've been leading the ink! project for well over a year and have been working on ink!/Substrate/Polkadot related repositories for the last four years.

My primary contributions have been in the form of bringing ink! into a production state. In total I've been working on ink! for three years now.

As part of this I've been significantly involved in the project, shaping its development, architecture and ecosystem. Here are my contributions that I consider noteworthy:

  • Development and Direction of ink!: As the develoment lead of ink! I have contributed code to all major components of Subtrate's WebAssembly smart contracts stack. I have actively shaped the ink! project in the last years. Under my oversight ink! has been made production ready and is used in production by companies and teams today.
  • Documentation and Tutorials: I started the ink! documentation platform and wrote the biggest part of the content on there.
  • Developer Experience and Tools:
    • I've significantly contributed to and shaped cargo-contract ‒ the tool that ink! developers use for building, testing, deploying and interfacing with their contracts.
    • I've created a linter for ink! contracts. It's part of our stack, we use it as part of cargo-contract, as a clippy-like pendant to lint ink! smart contracts with pre-defined best practice rules.
  • Testing: I've brought testing of the ink! stack and our code quality to the next level:
    • I've created a project called ink-waterfall, it tests our entire WebAssembly smart contracts stack for all our example contracts nightly. This includes the polkadot-js user interface via headless browser testing. This testing framework has found numerous bugs all over our stack, including in polkadot-js apps and api. This project has proven invaluable to assess the compatibility of different components in our WebAssembly smart contracts stack.
    • I've developed regression testing for ink!, enabling us to assess the quantitative impact of a pull request on contract sizes and gas fees.
    • I've started the substrate-contracts-node project, a Substrate node geared for smart contract development, scripting and CI usage. It is a major component of the ink! story nowadays.
  • Grants: I've collaborated with the W3F on multiple grants. Noteworthy ones are:
    • For Supercolony, a company that has about nine people working on ink! related things. They have made major contributions to ink! under W3F grants (e.g. this one).
    • For a team that is moving the binaryen tool wasm-opt (a Wasm file size optimizer) to be usable as a Rust dependency (Grant PR). This development will benefit the broader Rust+Wasm ecosstem.
  • I've overseen development of the Polkadot Standard Proposal PSP-22, an ERC-20 like equivalent for WebAssembly smart contracts.
  • Mentoring: As the development lead of ink!, I have onboarded and lead others in contributing to improvements of ink! and the broader WebAssembly smart contracts ecosystem.
  • Presentations and Evangelism: I've given multiple presentations on ink! over the years and been on a number of discussion panels. In terms of academic contexts I've given lectures at the Polkadot Blockchain Academy.
  • Community Building & Support: I'm actively involved in discussions with teams using ink! or pallet-contracts on further developing the technology and ecosystem. I'm an active contributor on our public Wasm smart contracts channels and on the Substrate StackExchange.

Pull Requests

These are some pull requests that I consider significant contributions. Those are all big architectural developments that made for major parts of ink!.

Significant projects which I started and have been the main developer of:

Noteworthy others:

Earliest non-trivial PRs:

Significant technical articles and videos:

I would like to apply for Rank 4.

@rphmeier
Copy link
Collaborator

rphmeier commented Sep 27, 2022

I support @cmichi for IV Dan , although III Dan may be more appropriate

@rrtti
Copy link
Contributor

rrtti commented Sep 28, 2022

Ranks higher than I Dan come with a minimum time period since I Dan as well as additional specific requirements per rank. To attain the level of I Dan please review section 6.2 of the Manifesto and see the requirements there:

The Candidate should have made three clear demonstrations of protocol expertise. Possible examples of this may be: identifying and fixing a non-trivial protocol issue; being available and playing a crucial operational role for a network fix; proposing a reasonable and non-trivial protocol innovation; or doing a valuable, innovative and insightful refactoring or alteration.

Also

Primarily designed and implemented a minor or auxiliary component. Should be able to list all key goals/principles/tenets of project philosophy and how these relate to technology

Please provide specific details on the three clear demonstrations of Polkadot protocol expertise, and the Polkadot core component you primarily designed and implemented: I am not sure if Ink! development is part of the core development of Polkadot: we should strictly focus on polkadot/substate/cumulus repo.

Furthermore, Manifesto sections 6.3, 6.4, 6.5 and 6.6 all state that a time period of 12 months should generally be expected to have elapsed since attaining the prior rank, leading to a reasonable minimum period of 1 year since fulfilling I Dan requirements for attaining II Dan, 2 years since fulfilling I Dan requirements for attaining III Dan and so on.

@bkchr
Copy link
Collaborator

bkchr commented Sep 28, 2022

I would support rank I Dan

@cmichi
Copy link
Author

cmichi commented Sep 28, 2022

I am not sure if Ink! development is part of the core development of Polkadot: we should strictly focus on polkadot/substate/cumulus repo.

This is the core question: are you defining the membership based on those three repositories. The manifesto explicitly mentions:

For now, we explicitly include expertise surrounding parachain consensus, cross-chain message passing (xcmp, hrmp, dmp & ump), consensus algorithms concerning the Relay-chain (babe & grandpa) and any cryptographic data-structures, languages and apis specific to Polkadot.

@rrtti
Copy link
Contributor

rrtti commented Sep 28, 2022

Yes, I believe the definition states core development (the three repos):

section 2.4:

2.4. Audience and Non-Goals. The Polkadot Fellowship is intended to be only the first of its kind. It focusses on the sustenance and enrichment of technical expertise relevant to the Polkadot network primarily concerning the core protocol and its implementation. While members may engage in ae number of activities beyond immediate technical work (designing, programming, debugging), the goal of the organisation is nonetheless that of building technical knowledge for the protocol.

Pure research, general education, public outreach, developer recruitment, management and mentorship may be inci- dental activites of some members but it must be understood that these should not constitute the primary contributions for a member to receive recognition. Should the concept (probably after some iteration) become proven effective, we might reasonably expect more instances of expertise-based orgnaisation “fellowships” for other disciplines not covered by the present Fellowship.

For now, we explicitly include expertise surrounding parachain consensus, cross-chain message passing (xcmp, hrmp, dmp & ump), consensus algorithms concerning the Relay-chain (babe & grandpa) and any cryptographic data-structures, languages and apis specific to Polkadot.

Secondly, we include the Polkadot node implementation including peer networking protocols, topology strategies, synchronisation strategies and the internals of complete node implementations.

Thirdly, we include the Polkadot business-logic (aka the “runtime”), including frame internals, runtime and host apis, pallets utilised by Polkadot and its system chains. Finally, we also cover expertise concerning xcm, grandpa-based bridges and standard RPCs.
technical expertise relevant to the Polkadot network primarily concerning the core protocol and its implementation technical knowledge for the protocol it must be understood that [pure research, general education, public outreach, developer recruitment, management and mentorship] should not constitute the primary contributions for a member to receive recognition.

We include the Polkadot node implementation including peer networking protocols, topology strategies, synchronisation strategies and the internals of complete node implementations.

We include the Polkadot business-logic (aka the “runtime”), including frame internals, runtime and host apis, pallets utilised by Polkadot and its system chains. Finally, we also cover expertise concerning xcm, grandpa-based bridges and standard RPCs.

@cmichi
Copy link
Author

cmichi commented Sep 28, 2022

You've quoted the broader context of what I have quoted. Can you please elaborate on why you think this paragraph doesn't apply to ink!?

For now, we explicitly include expertise surrounding […] languages and apis specific to Polkadot.

@gavofyork
Copy link
Contributor

gavofyork commented Sep 28, 2022

Please see the latest revision of the Fellowship Manifesto for clarification on this point.

In short, Ink! (and the Contracts pallet) are not technologies or code required for, and primarily used by, the ongoing maintenance and evolution of the Polkadot (Main) Network. If there is ever a system parachain which includes the Contracts pallet and the protocol relies on contracts deployed into this chain which are written in Ink!, then this would change. Currently there are no such plans (that I know of, anyway).

Recognition of contributions of---and expertise in---code and technology (tooling, pallets, extensions) valuable for the wider Polkadot ecosystem is important. It is not the Fellowship's aim to do this, but I would expect (as is mentioned in the Fellowship Manifesto) that there will be at least one additional Fellowship-like organisation which deals specifically with this.

@cmichi cmichi closed this Sep 28, 2022
@cmichi cmichi deleted the cmichi/seed branch September 28, 2022 14:44
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants