Member Request

[jacogr]

Overview

I'm Jaco Greeff, one of the core developers at Parity Technologies. My first code contribution to the Polkadot ecosystem can be traced back to mid-Nov 2017 (at this point we only had a spec of the vision and work was done in parallel to the initial core Polkadot node).

Primarily my focus has been on the overall ecosystem that is the polkadot-js libraries, APIs, tooling and user interfaces. These include:

• Libraries
• User interactions
• Tooling
• (Lesser known) JS client
• User documentation

Contributions

Contribution made are quite varied, as evident in the short summary above. However these can be grouped and discussed at a high-level. While these mostly touch on the interface level, as maintainer of polkadot-js these were all born out of a real user need, mostly focussed on the developer community.

For any links to the polkadot-js efforts, links to the repos are provided instead of specific PRs - since 2017 the bulk of the coding work here (95%+) has been performed by me with shepherding of external contributions, so rather than linking to specific PRs, the whole can be viewed.

Libraries

Libraries are the core focus of my day-to-day efforts. Although some are more visible than others, there are very few parts of the ecosystem that does not rely on some of them:

• JS API - This is most likely the largest body of work that is ongoing on a day-by-day basis. IT has grown from an "implementation against a spec" to a toolset that is widely used as-is as part of various tools and interfaces to a basis for some additional value-adding libraries in the ecosystem.
• WASM interfaces - These are bindings to critical crypto (sr25519/ed25519/ecdsa) and hashing (blake2/xxhash/etc.) libraries, some of these which are not available as pure JS implementations. Despite the name, both WASM and ASM.js interfaces are provided, depending on platform used
• Common libraries - These are an API-agnostic JS toolset that provides general utilities and well as Polkadot-system-specific interfaces.
• UI libraries - These provide light-weight very UI-focussed components such as Identicons, all trying to be toolset-agnostic to cover React, Vue, React-native.

User interfaces

Pure end-user interfaces has never been the primary goal for my daily efforts, however as part of ecosystem support and tooling around developer needs, there has been a number of notable efforts that has arisen and provides a backbone for daily use across the ecosystem. These include:

• apps UI - This is a toolset that has a primary power-user focus. While most end-user products have (and should have) a primary "even granny can use it" focus, this set is aimed at supporting a wide breath of all kitchensink functionality, allowing power users, developers and those willing to live with (some) quirks to be able to do anything on their chains, be it a relay, stand-alone or parachain.
• extension - Driven by the need to have better security for in-browser secrets, this has become the de-facto interface for browser key management. Like most tooling in the ecosystem, this is meant to be replaceable, with emphasis placed on allowing other developers use the same underlying interfaces to build upon.
• phishing - This is an effort driven by end-user protection from tools such as the extension. While originally fully "my baby", it has since grown where the development efforts for the libraries fall on my shoulders, but the vast majority of reports and specific phishing related URLs are handled by a community-led team.

Tooling

In addition to end-user (be it a developer or power-user), the need also exists for specific tooling that are to be used either in day-to-day checks or quick operations. Some of the tooling around ecosystem needs that I have been responsible for includes:

• metadata compare - Tooling to compare metadata across 2 runtimes, highlighting the differences in calls, storage, etc. This is mainly used to alert of changes between runtimes and allow for the updating on areas such as the transaction version in the runtime.
• api cli - A cli toolset that allows you to interact with a running RPC node via scripts.

JS client

The JS client was the first non-Rust client to be able to sync a Polkadot chain. This goes way back to the time of the Alexander testnet. Although stagnant at this point, it does include full networking, syncing, trie, runtime implementations -

• JS client - It certainly is the most interesting of all the efforts presented here and one of the largest reasons I have gotten involved with Polkadot. I certainly hope to dust this off and return with a renewed focus in this area in the medium-term future when less coding-myself effort can be expended on the other items.

User documentation & support

Documentation & support can be broadly categorized into 3 sections: static documentation, support via official channels and support via issues (this is not listed here, each of the repos mentioned in this document fall under my review).

• polkadot-js documentation & documentation repo - This forms the base of documentation efforts. While not chain specific, they do document a one-stop getting started with most of the tooling provided.
• jacogr @ Substrate StackOverflow - This is a relatively new (as of 2022) effort and has been great providing a searchable knowledge repository. While not one of the first contributors here, the input provided has been substantial.

Other

For core node contributions, these have taken the form of PRs, certainly not as substantial in this form as my other work, or those of other developers that are applying for initial rank and seeding:

• Substrate
• Polkadot

Summary

In most of these I've been the first "external reviewer" with "first interaction" for functionality added to the runtime, FRAME, RPCs and metadata. Although the maintainer of a tooling focussed ecosystem, with all the design and major parts of the development undertaken there, the drive has also been the core node. This means a tight loop to other developers in the ecosystem and continuous feedback into the design/development loop. Overall, as evident above, this means less core-client coding but more design input into the evolution of the ecosystem.

With the above in mind, I would put myself at rank V with just shy of 5 years continuous, core-to-the-ecosystem contributions across different areas of Polkadot.

[jacogr]

Update from IV to V based on feedback from applicants, my initial mis-reading of IV meaning "> 4 years" and relative nature of the applications.

Updated ranking, please re-check.