# Butt DisCO (and the future of our GitHub orgs)

## Problem statement

**Management** of our open source libraries is confusing and scattered. There are important SSB (mostly JS) libraries spread across GitHub `ssbc`, `ssb-js`, `ssb-ngi-pointer`, `auditdrivencrypto`, `fraction`, and on personal scopes too (`dominictarr`, `arj03`, `staltz`, etc).

**Security** of libraries is hard to guarantee since we have too many (apparently inactive) maintainers that may not have 2FA enabled, and could be suscetible to hacks (true story).

**Participation** in these organizations is unclear, except for the well defined [governance doc in ssb-js](https://github.com/ssb-js/ssb-js). It would be good to have a clear guidelines on who can join, when can they join, and when (or whether) should they be automatically removed.

**Process** is either too rigid (e.g. in ssb-js) or too loose (e.g. in ssbc). Too rigid process can create participation overhead and spook contributors away. Too loose process can lead to security problems or lack of clarity/agreement on how to handle coordination issues.

## Inspiration

[DisCO](https://disco.coop/) sounds really cool, and fits our situation. It's a way for people to work together in ways that are cooperative, commons-oriented, feminist economic. It's an alternative to DAOs.

## Pre-goals

(Things I propose be our goals, but could change when we discuss about them)

- **Centralize our libraries**
- Make it easier to find libraries
- Make it more consistent how those libraries are handled, e.g. all libraries have npm rights set correctly
- **Define a lightweight process**
- Should fit into, say, **maximum 1024 characters**, roughly 4 tweets
- This means we only develop consensus on those things that are **important** and in the big-picture cohesive
- Consistency does not to be thorough (e.g. not all libraries need to have the exact same code style and tool set), it needs to be **quick to understand and adhere to**
- **Encourage joining and automate leaving**
- Encourage participation, making it easier to put a new library in this bucket, making it easier to become a maintainer as opposed to cementing the small clique of maintainers
- Simultaneously, we should have rules to remove maintainers as they become inactive. This would be primarily for security, because those people could easily return as a maintainer
- **Algorithmic trust**
- To determine who gets access to admin rights, we could develop a score that is automatically determined based on trust
- E.g. run TrustNet on "PR approvals"
- We should use computer automation to remove a ton of types of coordination work, and to remove individual bias
- We used to have [ssbc-owners](https://github.com/ssbc/ssbc-owners) as one such kind of automation, but it got obsolete, we could make it a priority to have scripts to maintain the organization up to date
- **Consider scopes / categories**
- We need to define: is this org for all JS libraries, or only core libraries? Do we split libraries by type and importance? Do we include libraries for non-JS languages? Do we include specs and documents too?

## Let's video call!

Let's discuss these in a video call! Anyone who has ever had a **pull request approved and merged** on `ssbc`, `ssb-js`, `auditdrivencrypto`, `ssb-ngi-pointer` is invited to attend.

— @andrestaltz, @mixmix, @arj