# 2i2c's Goals for Upstream Communities

## Scope of this document

This is a fairly narrowly scoped document, applying only to 'strategic' upstream contributions as defined in https://hackmd.io/rteifFE0SV6Hk20KRfMR0w. It does not try to set strategy for the upstream open source project itself, nor affect how we interact with upstream for 'tactical' contributions (as defined in https://hackmd.io/rteifFE0SV6Hk20KRfMR0w).

## Credit

Thanks to MinRK for helping review a draft of this!

## Why have an institutional goal?

Healthy open source communities rely on both individual and institutional contributions.

The fundamentally important thing for invdividual contributors is the freedom to contribute as much (or as little) as they desire, wherever their desire stems from, for whatever reason.

However, institutions need to have a more structured approach, with intentional and explicit goals for what they want to achieve, and *why* they want to achieve that. Without it, the best possible outcome is the scattered efforts of a few individuals (with all the pitfalls of [Tyranny of Structurelessness](https://www.jofreeman.com/joreen/tyranny.htm) that entails). And the worst possible outcome is a takeover of the community for the benefit of any single organization (see also: Redis Labs). By intentionally setting out what the goals for an organization's upstream engagement is, we can hold them accountable if actions that are either contrary to or out of scope of that goal are being taken by members of that organization.

For tactical contributions, the explicit goal of engagement is fairly simple - we want a feature, or a bugfix, to serve some subset of users. This document attempts to lay out 2i2c's goals for strategic contributions.

## 2i2c's Long Term Goal for upstream engagement

With this in mind, I propose that nurturing the following *outcomes* are what should be broad goals of 2i2c:

We want the Jupyter[^0] community to be a *multi-stakeholder*[^1], *diverse*[^2] community with very high [*bus factor*](https://en.wikipedia.org/wiki/Bus_factor), because we believe this is a critical pre-requisite for advancing [our value proposition](https://docs.google.com/presentation/d/1kjxPAS7ZptK1OLPiAWmi7WjS5EaDHQtg3E_Gig8ldzE/edit#slide=id.g2c356a1beec_0_20).

[^0]: With a current focus on the JupyterHub subcommunity, but generally applicable to any open source community we have a strategic interest in. (TODO: Understand if myst / jb should be here)
[^1]: With different kinds and sizes of organizations (companies, non-profits, universities, etc) and individuals being stakeholders. We want to avoid a single organization monopolizing power within any community.
[^2]: Across the power spectrum - from users to bug reporters to casual contributors to maintainers to people on governance duty

We want to build actions that make progress towards this goal into our team processes, so everyone can (and does) equitably participate in upstream communities with the support they need.

## 2i2c's Medium Term Goal

This is a long ranging goal, and I (Yuvi) propose that the following be more focused, medium term goals that help move us forward towards the long term goal:

1. Increase the amount of casual but returning contributors to the JupyterHub community
2. Increase the amount of total maintainers in the JupyterHub community

These two are chosen because I believe we can meaningfully move the needle on our overall goal by focusing on these, and do so by equitably changing our internal processes so 2i2c employees can meaningfully contribute within their work hours towards these goals.

## Activities

I propose the following 4 activities, along with associated KPIs, to try safely for the next 6-9 months.

**Implementation note**: We will not start doing **all** these immediately! We will consult with the rest of the team, and start these 1 at a time so we can build these processes sustainably and equitably.

### Review Pull Requests from non-maintainers

Imagine two different scenarios:

1. You casually contribute a PR to some OSS project. Someone responds the next day, you have a pleasant back and forth, and it gets merged (or rejected) within a few days.
2. You casually contribute a PR to some OSS project. Nobody responds for a year. Eventually someone leaves a comment. You have forgotten everything, and don't even respond. Much later, your PR gets closed as stale.

Which experience will encourage you to come back and contribute again?

It's clearly (1). So we should try to use our institutional capacity to bring the community closer to (1).

I propose we do this by including **Review of N PRs by non-maintainers of JupyterHub** as a work item every sprint. We will build skills (via pairing, training, etc) inside the organization to be able to do this, as not everyone will feel comfortable reviewing pull requests for all projects nor have rights to actually merge or close PRs. We may also do additional work that helps drive this activity forward, such as new contributor drives, better documentation and policy advocacy. We will strive to make sure this includes pull requests of all types, not just code contributions.

#### KPIs

Two KPIs shall be measured for this activity:

1. Number of PRs merged (or closed) through our sprint planning activity.
2. Number of *returning* contributors whose PRs were reviewed by us.

### Issue Triage office hours

Issue Triage is hard for newcomers to do, as often it requires deep knowledge of various components to understand how to direct an issue or refine it. As part of our sprints, we will run regular (cadence TBD, but no less frequently than monthly) "Issue Triage" office hours focused on triaging new issues that come up. At least to start with, this will be focused on other members of the 2i2c Team, and focus on upskilling them, rather than something open to the whole upstream community.

#### KPIs

1. Number of issues triaged by 2i2c team members

### Sponsoring and Mentoring new Maintainers

OSS communities have to grow their pool of maintainers, or they will die.

[](https://xkcd.com/2347/)

But minting new maintainers takes times, and effort. Not just on behalf of the person who is trying to be the maintainer, but on existing maintainers who have to spend time mentoring and sponsoring this person. The focus on sponsorship is very imporant, for excellent reasons laid out by [Lara Hogan](https://larahogan.me/blog/what-sponsorship-looks-like/). This also takes usually a long time to manifest - closer to a year than a month.

We shall build structures to identify potential maintainers, and build long term pathways for them to do work in the community to gain maintainership status. Given JupterHub doesn't have an explicit 'how to become a maintainer' pathway, we shall instead focus on:

1. Identifying potential candidates for maintainership
2. Identifying potential community work they can do to help get involved (contributing bug fixes, code reviewing, issue triage, helping answer questions, contributing code / documentation, release management, etc)
3. Build pathways for candidates to do (2) as appropriate.
4. Continue to iteratively do these until candidates have done 'enough' work in the upstream community to gain maintainership status.

This work is essentially nebulous, but very worthwhile. We will need to co-ordinate this particular effort more closely with community leaders, and recognize this takes a long time to actualize.

In the Jupyter community, maintainership status is tied to individuals, not to organizations they work for. This means that nobody should get maintainership status *simply* because they work for any specific organization (such as 2i2c). We should look for a diverse set of candidates, ideally funded by different organizations, who are also *interested* in becoming maintainers.

Note: We already have at least one such person identified (Tarashish from Development Seed), and nominal acceptance from MinRK (JupyterHub community lead) for this process.

#### KPI

This measurement moves slowly, but is very clearly impactful:

1. Number of people who have become maintainers due to our concerted efforts.

### Increase bus factor and diversity of people making releases

Making releases is often a thankless task, but is important to the health of any community. It involves co-ordinating testing, writing changelogs, understanding if any special upgrade instructions need to be provided, etc. Institutions can help here, by dedicating time for people in the team to perform this task on a regular cadence. To advance the 'multi-stakeholder' and 'high bus factor' aspects of our goal, we will also make every attempt to have many different people do releases, both via mentorship and sponsorship. This will get integrated into our regular workstreams.

#### KPIs

1. Number of releases performed by 2i2c engineers
2. Number of releases performed by others with sponsorship / mentorship from 2i2c engineers

## What projects do we focus on?

Our long term goal applies to *any* upstream community that:

1. We strategically depend on to serve our communities,
2. We have a *need* to help sustain, given overall dynamics in the upstream community
3. We have the *ability* to help sustain

For example, Kubernetes satisfies (1) but not (2) or (3), while JupyterLab meets (1) and (2) but not (3) (presently). Currently this policy as written only applies to the JupyterHub community, but that is subject to change as our organization changes.

## Team Responsibility

Implementation of this policy is a responsibility of the Product & Services team within 2i2c. These activities will need to be integrated into the day to day working practices of the Product & Services team, so it doesn't become an external shadow process that only some team members do.

TODO: Designate an individual role inside P&S as responsible for these KPIs.