Runtime Function Onboarding 2024

👋🏻 Intro: Welcome to The Runtime Function

Welcome to Parity, welcome to the Runtime Function, arguably one of the most important teams within Parity and the Polkadot Ecosystem.

What do we do? We build everything that is needed for the Runtimes of the Polkadot ecosystem to exist. Remember, the runtime is where the application logic of all of our blockchains live. The runtime function is at the moment divided into 3 teams:

1. (Substrate^[1] +) FRAME + XCM: Build and maintain the (mostly) un-opinionated frameworks/SDKs that allows us to build blockchains, runtimes and enable communication between them. All of the aforementioned are part of polkadot-sdk.
2. Polkadot System Runtimes: Then, we build applications with Substrate, FRAME and XCM. This includes: The runtime of the Polkadot and Kusama relay-chain, plus all system-chains. The community of Polkadot builds Parachains with all the same tools.
3. Bridges: Given its proximity to FRAME and XCM, the core developers working on trust-less bridges reside in the Runtime Function as well.

💊 The Reality of What We Do

Working in the above implies two very important self-evident truths about the type of work we do:

1. We fly low:* The work we do is meant to interact with value-bearing, mission critical systems that are meant to survive the test of time. This implies:
   • Emphasis on testing.
   • Demand and provide vigilant code review.
   • Nonetheless, mistakes happen, and it is okay. What is not okay is to repeat a mistake. We maintain a categorical zero-blame mentality, learn from mistakes, make sure it cannot happen again, write a public post mortem, and move on.

2. We fly close to end-users/developers*: Most of what we write affects our two major stakeholders: developers (parachains, UIs, and more), and blockchain users.
   • Always think about: user-facing code, vs. non-user facing code.
   • Is my feature well documented? can someone else use/understand it?
   • Is my feature a breaking change?

We will repeatedly come back to these two points throughout this document.

📈 Function Portfolio

Let’s take a moment and introduce you to a non-exhaustive list of great things that function is currently working on, in the words of the maintainers themselves:

📡 Communication

📞 Sync

• Weekly "Runtime Function Hangout" call.
  • Agenda curated collectively in calendar invite. If you'd like to encourage others to show up, put your item there.
  • Communicate important decisions in the group chat for those who are not present.
  • Optional in general. Join based on your workload, and the agenda.
• 1-1 with your team lead.

📧 Async

• Parity forum Polkadot forum.
  • Prefer accompanying Google Docs for discussions that will need lots of revision.
• GitHub
  • Build a system around notifications, you are expected to reply to your @mentions.
• Element
  • Everything under Runtime Function space. Explore sub-spaces and rooms accordingly

Why do we use element to begin with?

Privacy-preserving, semi-redundant due to connectivity with other homeservers (so even if ours goes down, people on other homeservers can still interact with the channels they're in). Interoperable (with other chat protocols, due to bridges), customizable/programmable and control over our data.

Erin

😱 Where/How-much to Write?

A common question around async communication in chats is how "loud" you should be. For example, whether you should talk in big chats, as opposed to DM.

We are a fairly small company. Prefer sharing things in broad element groups where most people can see them, rather than small chats with a handful of people. As an example, we have vibrant chats such as:

1. Engineering General
2. FRAME Public
3. XCM Public
4. polkadot-sdk-docs

That are used for various discussion topics, requesting reviews and Q&As, and using them is highly recommended.

.. But what if I am too loud, what if I annoy someone, or ask a dumb question?

Short answer: It is not your problem.

In an async environment, it is much easier to be under-heard and under-share, than the opposite. Therefore, it is safer to optimize for over-sharing, and only adjust if necessary.

If you're over-sharing and are actively annoying anyone, it is their responsibly to give you that feedback, and you should adapt if the feedback is reasonable. But if you are silently under-sharing, it is much harder to identify it as an issue and recover from it. I suggest always preferring to share something where the most broad audience can see it, unless you conclude otherwise for some specific reason.

🤪 Dumb Questions

Parity has an interesting attitude towards this. We have a room specifically called "Parity Dumb Questions", to remind you that there is no such thing as a dumb question^[2].

Let's be honest: Web3 is a complicated space, for both engineers and non-engineers. Only a few are knowledgeable enough to have a high level understanding of everything. Most of us are new in this space. Moreover, this space (and Parity) move really fast. What you know today might need an update in 6 months.

So, in short: There are a million things to (re)learn, and asking those who know better than you is the wisest thing you can do. As the saying goes: "The only dumb question is the one you don't ask".

But, there are a few notes that you should keep in mind about questions:

🧑‍💻 Contributing

🛣️ Road to Merging a PR

For your contribution, consider reading everything in our docs/contributing folder. What you do here is more or less what we expect external contributors to do:

1. Proper PR description, as per PULL_REQUEST_TEMPLATE.
2. Adhering to everything in CONTRIBUTING.md.

🔙 After Merging

Well, your PR is finally merged. Are we done? More often than not, no.

Yet again, a lot of this goes back to the dual realities (💊 The Reality of What We Do) of our team: Flying low and flying close to end users. This implies that, before kissing and saying goodbye to a merged PR, you need to reflect on the following:

1. Test-network Runtime Upgrade: Fairly soon after your PR is merged, it will be enacted on our test-networks, most notably Westend. This is your best opportunity to do your final round of (live) testing. Ask yourself: Is everything alright in Westend? How can I test my feature further?
2. RC/SC Runtime Upgrade: Days, weeks or months after your PR is merged, it might finally land in the RC or one of the SCs^[3]. This is another milestone for testing: Did everything go smoothly? The release process of RC runtimes, and their enactment, is fully public and managed by the Polkadot fellowship, so you can easily tag along.
3. Developer Community Impact.
   1. Did any UIs break because of your feature? Could we have communicated better with them?
   2. Are any new documentation pages needed? (easier to forget:) Are any of the existing ones outdated now? Maybe one of the most visited StackExchange questions needs being updated?
   3. Was your PR description good for downstream teams to be able to adopt the feature?
4. Monitoring and Data
   • Devops Wiki A lot of great resources about our infra, and how to do monitoring of parity run nodes, validators, logs, and more!
   • DotLake (public)
   • Metabase (private)

🧐 Know Your API

As a final example to cement 💊 The Reality of What We Do, let's consider the difference between two features, in order to highlight how important it is for you to be able to answer one question:

Is my code end-user-facing or not?

Consider:

1. An optimization made to the networking of the parachains protocol. This will improve the performance of parachain networking by 10%, without any action needed by anyone, as soon as the crate is released and updated. In such cases, be my guest, and ignore the majority of this rant. Your work is not directly affecting end-users. You can still demonstrate competence by adhering to everything said here, but a lot of it is not relevant.
2. Contrary, consider the following:
   • Working on a new major revision of any of the FRAME modules used by Polkadot end-users, such as staking, proxy or multisig.
   • Working on any feature that is expected to be integrated into wallets, exchanges, or other 3rd party software.
   • Changed an API in FRAME or Substrate that might make existing code that compiles no longer compile.
     • Even more pesky, existing correct code might still compile, but be incorrect if some upgrade path is not followed.

Our PRDoc system's audience section is a good framework to help you think about the final audience of your code.

Moreover, the new release process, with its emphasis on semantic versioning, will force you to think about this to a high extent, but it does not encapsulate the full magnitude of the above. For example, in your PR, you might be causing a major bump to many crates, but only one of the crates is something that actually matters to the main audience, noted in the PRDoc.

🧹 Be The Housemeister

We are a true open-source project, and our entire issue-tracking system is what we publicly have in GitHub. While our issue list has grown very large, and it is unlikely that our team can clean it up, we can keep issues that are relevant to our team tidy, well described and properly labeled. Practically:

1. Keep the issues that you have created tidy.
2. Keep an eye on the issues opened by external contributors (they are auto-labeled as unconfirmed) and see if you can triage them. We sometimes get important bug reports from external users and the only way to do so
3. Similarly, you can have some degree of supervision upon areas of our StackExchange.
4. Keeping a good list of mentor

Needless to say, most of this is not relevant to you at day-0, but it will become as you grow to be an expert in some domains.

🤓 Keeping Up

In reality, you are joining the Polkadot ecosystem, not just Parity. And there is a lot happening in Polkadot! Some links for you to explore based on your interest in various topics:

• Governance: Polkassembly, SubSquare, AAG.
• The Kusamarian
• Community Element Chats:
  • Watercooler, Direction, and Validator Lounge if you want more exposure
  • And Kusama Watercooler, Direction.
• Newsletters: DotLeap.
• Bill Laboon's Daily Digest.
• Polkadot Fellowship
  • Public Element Room 1, Room 2.
  • Github org, including manifesto.
• Rust: This week in Rust, Rust in Blockchain.
• I personally like to follow these for general crypto stuff:
  • Decrypt.
  • Podcast: Defiant, Bankless and Unchained.
  • CoinBureau’s weekly crypto update videos every Monday (yes, but it is good to know what the mainstream thinks..)
  • Bloomberg Crypto reports, Matt Levine Money Stuff.
• Official Polkadot Ecosystem Room in Element — a fairly active chat with many parachain teams.

📍 Company

A few high level notes about the company, and not just the RF.

🎭 Culture

You will learn about the Parity culture in your onboarding, but here’s some old-but-still-relevant material from former culture decks.

First, here’s a little screenshot of an all-hands talk about vision of Parity in 2019 which I still stand by. You can find the full talk here (most of it is not super relevant anymore).

A culture talk from Gav in the 2022 Tenerife retreat. This snippet of this talk is among my favorites:

You can find the culture deck from 2022 here. If I wanted to name one slide from it that you should think about the most, it would be:

The majority of the efforts of your team lead, and this document is to help you toward achieving the status mentioned in the above sentence.

🔬 Parity XP

• Parity XP contains links to everything else that is part of the internal org-wide onboarding.

💎 Appendix: Principles For Excellence

Personal opinion of @kianenigma follows.

These are ideas that I believe will help you be excellent, and help others be the same. This is an opinionated re-iteration of some competencies that are noted in our CultureAmp.

Stability Over Chaos

A theme in Polkadot in 2024 has been Stability. We used to say: "We write code faster than we can write about it". Parity has always been a company known for engineering excellence, at the cost of lots of breaking changes. This all used to be cool, but not anymore. The best number of lines of new code to deliver a new feature is 0. The simpler, less-breaking a solution, the more elegant it is.

Information (de)Centralization and Longevity

As noted in 🤪 Dumb Questions, we acknowledge that there is a lot to be learned for all of us in this space. The underlying issue is that there is a lot of information centralization. Veterans in the space know a lot of things, yet the path for new joiners to learn the same is unclear and bumpy, and the constant evolvement of the space does not help.

The rule is: Once you have learned something, think about how you can make sure it is accessible to more people, and for a long time.

The best example of this is something that I personally do: Policing people to move good conversations and Q&As from a small Element room to more permanent places. Every time I see a good technical question asked in our Element:

1. If this question is already asked in StackExchange, or in any of our docs, then I don't need to rewrite the answer. I will paste a link and move on.
2. If not asked, and I know the answer, I don't answer the question in chat, but instead ask the person to ask it in StackExchange, and only then answer.

This is merely one example, but the mentality it demonstrates is applicable to many situations. "If you had to spend 1h answering a question, how can you make sure the next time someone has the same question, it takes them 1m?"?

Domain Ownership

Take radical and proactive ownership of what you have built, and be proud of it. We highly encourage engineers to grow a vision for what they are working on, and influence its future. This gives you a high degree of freedom to not only have a say on how some feature is implemented, but also which features are worthwhile.

But, freedom comes with responsibility:

• As the owner of a domain, both internally and externally, you need to make yourself known as the owner, so that others can find you.
• Follow your domain carefully, participate in conversations around it, answer questions.
• You need to interact with experts and higher level leaders both in Parity and the community to share your ideas and come to a conclusion about the future

Proper off-boarding and handover is also an important aspect of ownership. We move companies, teams, or sometimes, put a stop to an initiatives for various reasons. But what happens to the part of the project that is already out there? Should we bring it down? should we archive a repo? Prevent letting initiatives going stale.

Announce Early

In tandem to the above, try and announce^[4] what you are working on early, and embrace feedback. When you start an initiative, announce the vision, then link to a public Element room if one exists where one can join for a more in depth discussion about the project.

Don't Be Blocked On Decisions

Sometimes it is hard to come up with an answer to an decision. Unless if it is a very irreversible one, you can do the following: Share what you think is the best approach, and if after x weeks no objections comes, you execute.

Measuring Impact

The impact of what we do, specifically for end-user facing work (as defined in 🧐 Know Your API), is NOT how many PRs we manage can merge into polkadot-sdk, but rather how much our code is being user by end-users or developers.

Liveness Above All

Parity is a collective contributing to Polkadot. Most of us are part of other collectives that contribute to Polkadot in other ways, such as ChaosDAO or the Polkadot fellowship.

Making Polkadot successful is, one way or another, our main mission. Therefore, important bugs and existential issues that might arise should never be discarded as "it is not the task I am working on, so not my problem". If something important comes up that is possibly an existential threat to Polkadot, it is everyone's first priority.

Resilience Above All

We proudly consider ourselves as one of the (few) companies that is "doing blockchain right". In that, we are not in this for a short term profit, for capturing a hype or anything other than making the true Web3 vision come to fruition.

And what is that Web3 vision: That we need to build the tools necessary to be able to build resilient systems that can survive the test of time. Blockchains are one important type of such systems.

We are also proud to be on the forefront of scalability of Blockchains, without sacrificing Resilience, something that we think other blockchain systems have deliberately opted to sacrifice.

With all that said, what is practically means for us, is that when we are developing runtimes and blockchains, making sure the system is sound, secure and sybil resistance is non-negotiable.

Learning Resources

• Polkadot Blockchain Academy
  • Recordings
  • slides
• Polkadot's Build Horizon: Contains some up-to-date learning resources

Wrapping Up

Okay, this was long! thank you for reading! for any feedback, reach out to @kianenigma.