# Structuring our 'Good Citizen' Work

https://github.com/2i2c-org/meta/issues/1289#issuecomment-2220950633

> what will maximize our chances of achieving 2i2c's goals as an organization?

Let's take a page from our value proposition:

> A global network of community hubs for interactive learning and discovery

*Community* here does **not** refer to open source upstream software provider communities (like JupyterHub or Kubernetes), but to downstream user communities (like CryoCloud or Openscapes). Our open source work should thus be "delivering value to user communities"[^1].

This document helps answer two things:

1. As an employee of 2i2c, which open source work can be considered to be on '2i2c time' and which is on my own time?
2. What principles do we use to guide the structures we build that help team members engage with upstream open source communities?

We will define two *kinds* of open source contributions, and define structures for how we decide as an organization what falls into either of those buckets.

## Guiding Principle

From our value proposition:

> We need infrastructure services that are driven by community needs and values, that follow the same open source science practices we wish to see in others, and that believe in the power of shared community resources and knowledge.

## Tactical open source work

Satisfying community needs often involves directly working on the software they use. Driven by our [right to replicate](https://2i2c.org/right-to-replicate/) principles, this usually means working on a piece of software that is not proprietary to 2i2c nor solely owned by us permanently - but contributing to an upstream software community.

Some illustrative examples here are:

1. [Allow login to be gated on OAuth2 granted scopes](https://github.com/jupyterhub/oauthenticator/pull/719) was a feature we added to support one of our communities' auth flow (EarthScope)
2. [Change how .pyc files are kept in images](https://github.com/pangeo-data/pangeo-docker-images/pull/426) was work we did as a result of a support ticket investigating spawn timeout issues in the LEAP hub
3. (add example that matches an internal engineering allocation)

The fact that these are open source contributions are *incidental* - we were primarily doing them to directly support our communities.

Our processes for deciding what is important to us organizationally should thus determine what work gets done as part of this bucket. For engineering, this process eventually feeds into the Engineering Project Board under the `product-dev` (from product board), `internal-eng` (from recurring calendar events and internal eng roadmap), `tech-support` (via freshdesk) and `partnership-support` (via slack) buckets.

## Strategic open source work

> believe in the power of shared community resources and knowledge.

For our *tactic* of relying on upstream to maintain software we use to serve our communities, we must also help upstream do things that keep the overall ecosystem healthy even if it does not *directly* address a specific user community need. The *presence* of the healthy ecosystem addresses the community need itself.

This bucket accounts for work that is purely focused on *maintaining the health of the open source ecosystem*. It would include things like:

1. Help making releases
2. Provide code review
3. Help onboard new contributors to the project
4. Fix broken CI
5. Write documentation and tutorials

However, it would **not** include things like:

1. Adding a new feature to an upstream project (this should go through our own product process and prioritization)
2. Creating brand new projects
3. (give other examples here)

> Could we define _as an engineering team_ what work is most-important for keeping open source projects healthy, rather than just saying "you can do whatever you want to keep them healthy"? Part of what we want to do here is encourage more thoughtfulness about "what is the best way for an engineer to boost the general health of a project", so that we aren't being driven by reactive anxiety and busy work. Sometimes doing "general maintenance" is the best use of time, sometimes it is not. We should be thinking about this as a team and assigning work intentionally, even if it is not towards our product development.
>
> [name=Chris H]

> Regardless of the above - we need to do a better job of defining what value we've provided to open source, and why. Even if we let people just make whatever contributions they want, we need to be able to track what it is we actually did, or we won't be able to communicate externally this aspect of 2i2c's mission (which will make it much harder to raise funds that pay for people's time doing this kind of thing).
>
> [name=Chris H]

You *can* do those things, but then it would count as personal time rather than 2i2c time.

We currently don't have *structured systems* to help our engineers find this kinda work to do, so not everyone actually does this. We need to build a system that feeds into 'open source health building' work, that we can then distribute across the team. When left as unstructured time (as is now), it runs into all the general problems of unstructured time (primarily, not everyone *feels* like they can actually use them!). This would include plans for helping team members grow into roles that involve upstream work, as well as rotating ways to help with recurring roles, etc.

[^1]: https://github.com/2i2c-org/meta/issues/1289#issuecomment-2220950633