# Governance audit and improvement suggestions

Authors: Tania Allard, Jaime Rodríguez-Guerra.
April-August 2025.

## Resources

- [`conda/governance` repository](https://github.com/conda/governance)
- [Supporting schematics](https://lucid.app/lucidchart/595d572d-59db-44b3-a820-7a087f64d2f8/edit?viewport_loc=-1432%2C-300%2C6134%2C4392%2C0_0&invitationId=inv_44f0ae4b-854f-49c1-8a75-d482b7d6a2be)

## Context

We conducted a review of the conda governance with the following goals:

* identify procedural or structural gaps in our current governance
* identify potential improvements or updates needed to the current governance to better reflect the projects/ecosystem status and the needs of our community (as our project and community evolve, our governance should follow/adjust to such changes)
* propose a plan to adress the gaps found or make our governance more robust

## Findings and recommendations

### Definition and clear use of "conda community" and "conda organization" terms

**Current status**:

The terms `conda community` and `conda organization` are currently ambiguous as they are often used interchageably in the [conda governance docs](https://github.com/conda/governance#conda--conda-incubator-governance).

Not only this creates confusion about who/what the governance applies to and in which capacity but by heavily relying on the term `conda organization` the scope of the existing governance is rather focused or centred around technical items (and code-related assets such as GitHub repositories), leaving the governance and ownership of other essential areas up to interpretation or out of the scope entirely.

For example, the [main governance docs state the following in its Manifest section](https://github.com/conda/governance#naming--manifest):

> This document defines the conda Organization as the body responsible for governing the tools, specifications, and libraries within the conda ecosystem, broadly speaking.

Following, the [Code of Conduct uses the term `conda organization`](https://github.com/conda/governance/blob/main/CODE_OF_CONDUCT.md#behavior-outside-of-conda-organization-spaces):

> The CoC Committee does not influence behavior and membership in spaces outside the conda Organization. However, if you are being harassed by a member of the conda community outside our spaces, you may still report it to the CoC Committee.

Such a wording leads to questions about who the CoC (and other policies) applies to (i.e. does this apply to all interactions within the GitHub organization or solely to the "body responsible for governing the tools..." per the manifest).
Which limits/muddies the scope and enforcement of the CoC, leading to uncertainties around spaces such as Zulip, mailing lists, and other fora or spaces where the conda community might interact and be present.

While the opening sentence of the governance docs define its scope as:

> This document outlines the policies and procedures that manage the conda community.

**Recommendations**:

- Align on scope and definition of `conda community` and `conda organization` for example who/what are we referring to in which case (and by extension who/which groups are impacted by our governance).
- For example, regarding scope: is [“conda and conda-incubator governance”](https://github.com/conda/governance#conda--conda-incubator-governance) correct? or should this be wider-reaching (i.e. conda community in the broader sense of the word) with provisions specific to the conda and conda-incubator projects/organisations as sections within the overall governance?
- Ensure consistent use of these terms throughout our governance to avoid confusion or ambiguity moving forward.

### Teams and roles documentation

**Recommendations:**

- Expand the [Teams and roles documentation](https://github.com/conda/governance#teams--roles): each of these groups is distinct enough to merit more thorough documentation covering items such as:
- Roles/membership: describe roles, responsibilities, requirements, and privileges/access of contributors, maintainers, teams members, etc.
- Subteams and project teams (types of teams, requirements, existing teams, charters, etc.).
- Explicitly document teams' governance, including expectations and escalation paths, among any other processes essential for the team's function.

> Example of documented roles, responsibilities and expectations https://jupyterhub-team-compass.readthedocs.io/en/latest/team/structure.html
> https://github.com/kubernetes/community/blob/master/community-membership.md

### Community, federated and archive maintenance

**Current status**: these types of projects are [documented in the governance repository](https://github.com/conda/governance#community-federated--archive-maintenance), though there is not a straightforward way to understand the processes for incorporation/incubation/graduation of a project nor a list of which projects fall into which categories (except for archived ones).

**Recommendations:**

- Explicitly document the processes for these types of projects
- Create a list or badge to indicate the category a project belongs to

### Sub-teams / project teams creation process improvements

**Current status:**

The process for sub-teams/project teams creation is implied in <https://github.com/conda/governance#voting-items>. The whole process is not clearly (or explicitly) documented, making it hard to find and leading to inconsistent processes (and results) for team creation/dissolution/refresh (for example, the CoC team is the only team with a documented and visible charter).

**Recommendations:**

- The team creation process should be defined and documented accordingly, in a section of its own rather than implicitly in the voting mechanisms section of the governance doc.
- Sub-teams/teams charters should be stored/documented in a `.md` file or similar (and could build on https://github.com/conda/governance/pull/147/files to add structured data as yaml frontmatter). There should be templates to streamline team-related processes.
- Existing charters and teams should be documented per the above bullet point.
- Processes to update an existing charter should be defined and documented.

> We should provide a template for new teams creation
> The CoC is the only team with the charter documented in the repository
> “Repositories SHOULD belong to one project team” -> now Infra is owner across all repos + project team

References:
- https://github.com/conda/governance/pull/147/files
- https://github.com/conda/governance#voting-items

### Consolidate Steering committee documentation

**Current status:**

Steering Committee (SC)-related documentation is scattered across different sections of the governance documentation.

**Recommendations:**

- It would be best to consolidate SC-related documentations for readability.
- Explicitly creating a charter for the SC (much of the content needed is already documented or in issues). This charter should include:
- Mission
- Direct responsibilities
- Membership
- Decision making/voting
- Members removal/emeritus (separate processes for intentional step-down/reafirm affiliation as well as removals, for example “no confidence” or similar)

- Additional docs worth adding:
- How to contact the SC

Additionally, the matter of access/GitHub privileges for emeritus members should be resolved (right now emeritus members inherit from the SC in GH and thus retain elevated access to the GitHub organisation, leading to potential security risks).

References:

- https://github.com/conda/governance#steering-council-membership
- https://github.com/conda/governance#voting-items

## Other suggested actions

1. Shepherd [Create a new Security sub-team #166
](https://github.com/conda/governance/issues/166)
1. Discuss project teams/sub-teams representing folks working for a single employer (Quansight, Anaconda, prefix). What is the scope of these? What are the expectations, privileges, and accountability? -> This somehow feels odd as a sub-team, so I would like to discuss and formalise this.
2. Some more context at https://conda.zulipchat.com/#narrow/channel/457607-general/topic/Sub-teams.20for.20planning.20purposes, https://github.com/conda/governance/issues/226#issuecomment-2784462620,
3. Reassess the type of the CoC sub-team. It is dynamic, as people in the SC can also be reported (fair), but in any case, the sub-team should not be entirely self-organizing, and substantial changes to the CoC should never go unnoticed by the SC. -> need to discuss and perhaps kickstart a charter update process, since the current charter enables substantial changes to be made to the CoC without SC review or approval.
4. Have an annual or 6-monthly community checkpoint to establish an opportunity for dialogue and communication across the SC, sub-teams, and other stakeholders
5. Reorganise the governance repo: break docs into smaller `.md` files or a Sphinx/docusaurus site to make it easier for the community to navigate and search the documentation.
6. Have a regular SC-only meeting to discuss sensitive & strategic items.
8. [Address issue](https://github.com/conda/governance/issues/235) to add labels to conda/governance.