Scaling the CAPI Apps Framework Team

# Scaling the CAPI Apps Framework Team Apps framework is an effort to create parachain-first JavaScript/TS framework for building unstoppable apps on substrate based chains. The project consists of 3 parts. * [CAPI](https://github.com/paritytech/capi) (Chain API) is a TypeScript toolkit for interactions with Substrate-based chains. CAPI consists of FRAME-oriented utilities and a high-level functional [effect system](https://github.com/paritytech/capi/blob/main/_docs/Effects.md) which facilitate multistep, multichain interactions without compromising on performance or safety. See the project [notion](https://www.notion.so/paritytechnologies/Substrate-Apps-Framework-9d5ee4c838bb4617ae7ac0035085784b) for further details. * A [Components library](https://github.com/paritytech/ui-components-discussion) is collection of web3 friendly, React based components made using a consistent [Polkadot design language](https://www.notion.so/paritytechnologies/3UI-Polkadot-Design-System-9dc1f514b3ad4f14af10522b97b57961) aimed to help easily create apps with a consistent "Polkadot look and feel". * Apps are examples built with CAPI and using the components library. Currently in the pipeline: * Demo mini-apps (functionality: token transfers, block explorer and connect to wallet) * An unstoppable, web3 URL minifier: [Link](https://github.com/paritytech/link) * Contracts UI v2 - planned start in August * Staking app v2 - tbd * Governance v2 - tbd * Substrate connect - tbd As of now, we have: * Harry Solovay: Engineering Lead - CAPI * Karl Kallavus: Developer - Components library * Goran Radovanovic: UX architect - Apps * Andreea Eftene: Developer - Apps As the team scales up we should be thinking more in the terms of creating an Apps Department than a single team. There is significant overlap between the Onboard The World team and the CAPI effort and we expect a lot of cross team work in the future. We also expect the team(s) to collaborate with developer relations efforts across Parity and the ecosystem. ## Team Structure Apps Department: * Lead (high level planning, managing cross-functional projects with a product mindset) * Project Manager (1 or 2, cross-functional) * Helping out with tracking development on multiple fronts * CAPI (2-3 developers full-time) * Design and implementation of the core CAPI code * Optimisation, bug fixes and new feature development * Support Apps and Components work, both in- and outside of Parity * Documentation of inner workings of CAPI * Support evangelization and developer relation efforts (public speaking, tutorials, workshops, blogs) * Components library (2-3 developers full-time) * A component library package that can easily be added to a project * Filling the library with Substrate native components * Making sure there is a pipeline for ecosystem contributions * Documentation and example code show-casing each component * Close collaboration with UX team and design system development * Apps development (3-4 developers full-time) * Design, implement and deploy unstoppable apps based on CAPI and components library * Create healty and quick feedback loop between implementation and core features * Collect usability data on deployed apps to form future decisions about development and UX * Mintain and monitor production code * UX & UI support (1-2, cross-functional) * Working on our design system for making sure there is a consistent experience among Polkadot apps and products * Working on the best UX for upcoming apps CAPI, Components lib and Apps should each have a lead, whereas Project managers and UX researchers working cross teams. ## Considerations The biggest unknown for this team is the unclear product strategy for Parity in general. Should Parity stop at the core CAPI and component libraries and see the Apps work as "whitelabel" apps, picked up and developed into fully fledged products by the ecosystem? Or pick a hybrid approach, providing both an awesome developer story and also a set of particularly important apps to ensure they exist and are well maintained? Which apps? The same question is relevant for other teams, notably the Onboard the World effort, but also NFTs, Contracts UI and Substrate Connect. Regardless of the outcome of that wider conversation, we feel it's critical to ensure that we have a clear demarcation line between: 1. Projects we are fully committed to long term 2. Projects in-flight that are not yet production ready 3. Projects that should serve as example code, Proof of Concept, white-label products As the team scales up, and products like CAPI and the components library mature, there is room for spinning off this department from core engineering and into its own thing. Benefits: * Decreased pressure on the core team to deal with end-user products. * Direct funding and reporting lines to the web3 foundation for unstoppable apps development. * Close collaboration with BD in potential consulting opportunities in the ecosystem without engineering management overhead. * Close collaboration with devrel and marketing around evangelising CAPI to js devs (biggest group of devs on the planet), again without Parity engineering managment overhead. ## Plan in Practice 1. Hire PM (like Joyce) for people and project coordination and taking work off of the leads. 2. Hire 2-3 high-quality devs between CAPI and Apps development to help speed up the progress (current status: 1 starting soon, 1 in the offer stage). 3. Onboard and train people and see where they fall in the team wrt their strengths/preferences. 4. Identify areas that are lacking and start more targeted hiring (this stage could be open to more junior people)