conda Organization Steering Council Membership & Voting Proposal

[tnabtaf]

So far we have made small, non-policy changes to the conda governance proposal (see #40 and #42). I would like to start a discussion about significant policy changes. This issue is a proposal for how the conda Organization’s Steering Council membership and voting could work. This issue has a summary of the proposal, followed by a longer version. Eventually this discussion will be reflected in a (likely) longer form in the conda governance document.

Summary

This is an opinionated proposal that encourages both community and commercial contribution and innovation, while clearly limiting how much any single funding entity can control decision making and direction.

Several goals drive this effort:

1. Preserve most of the current proposed governance model in conda-incubator. This is based on conda-forge’s governance model.
2. Encourage community and commercial / organizational involvement and innovation.
3. Prevent capture of the conda organization by any one funding organization.
4. Assure the conda community that Anaconda and other commercial entities are truly limited in what they can do going forward
5. Make the conda Organization a fiscally sponsored project, most likely with NumFOCUS.

We propose limiting the number of Council members with common funding sources to a maximum of 2. We also propose expanding the Council to include Provisional Members - representatives of recently involved organizations that are funding at least 1 FTE working on the conda ecosystem, but that have not yet had time to establish their contribution credentials in the conda community.

This enables particularly active organizations to have an increased voice on the Steering Council (up to 2 members), while limiting these organizations’ total voting power. It also encourages new investors (in terms of FTE funding) to quickly become involved, as they can have a voice immediately. We believe this will encourage a Steering Council with independent / volunteer members and a wide range of interested funded organizations as well.

Of course the devil is in the details. The remaining sections dive into the specifics of how this proposal might be implemented. It is a specific and hopefully coherent proposal, but it is just a starting point. It is also long and detail oriented.

Steering Council Membership

Steering Council members should be invested in the conda ecosystem and community, and have time and energy to contribute to the conda Organization governance.

We propose to largely keep the current Steering Council membership model:

Nominate new Steering Council member: The proposer must provide a sufficient justification as to why the nominee should be welcomed into the Steering Council. Prior service to the community, including but not limited to: working on conda organization projects, writing conda specifications, and helping to bridge disparate communities are an important part of the nomination process.

• Sensitive
• 2/3rds majority to pass

We propose two changes to our Council membership rules. One limits membership, and the other expands it.

No more than 2 council members can have the same funder

This proposal is about the balancing act between encouraging individuals and commercial entities/grant funded groups to contribute to the projects they use, while preventing any one organization from dominating community governance, and then favoring their financial interests over the interests of the larger community. This proposed restriction is key to the prevention part of this dance.

This rule sounds straightforward and it mostly is. The challenge comes in determining who someone’s funders actually are.

Shared Funding: Proximate, Ultimate, and In Between

Keeping track of funding is central to our goal of encouraging participation while also limiting the potential impact on any one funding organization. However, funding can be multilayered and complicated.

For example, Robert is a researcher in the Computer Science department at Western Michigan University and is working on a National Science Foundation (NSF) grant. For the purposes of the conda Organization, is Robert’s funder his CS department, the university, the specific grant, a division of NSF, the NSF, the US government, or all of the above?

Meanwhile, across the world, Gouri works for GitHub, San-Yih works for LinkedIn, and João works on VS Code. Do they work for separate funders, or are they all funded by Microsoft?

We propose this guiding principle for determining which level(s) of funding to use for membership eligibility:

When determining if funding is shared, pick the broadest level of funding where people might have a common set of goals because of their shared funding source.

In Robert’s situation, two levels are good candidates for determining shared funding.

1. If Robert, or Robert’s department is widely involved in many aspects of the conda ecosystem, then we may want to include his department in the list of Robert’s funders.
2. If Robert is working on a grant that spans many universities then we may want to include the grant.

In most circumstances we would not include the university as a funder because projects in the CS department, and in the Economics department, for example, are unlikely to have shared interests driven by both being at the same university. People funded by NSF, divisions of NSF, or the US government are also unlikely to have shared interests that are driven by their shared funding.

In the corporate example we can imagine that since Microsoft is a large company, these three largely unrelated parts of it are unlikely to have common goals based mainly on their common ultimate funder. However, a company that wanted to control the conda Organization could do so by enlisting people from across their organization, claim separate funding, and then capture the council. In this case, the default guideline is to treat all parts of a company as having one funder.

Mechanisms for Tracking Funding

Nominated members need to provide a list of organizations that fund above some minimum amount of their time (25% ?). Nominees will need to provide a complete “chain of funding” for each such funding source. For example: “GitHub, a part of Microsoft”, or “CS Dept at Western Michigan University, Computational Reproducibility Made Easy grant, NHGRI, NIH, US Federal Government.”

The Steering Council will then determine the appropriate funding level(s) to consider when looking for common funding with existing and proposed members.

Council members will need to keep their funding documentation up to date, and notify the council whenever it changes.

There will also be cases where people have absolutely no funding related to conda (and we want to encourage passionate "volunteer" members like this). In these cases, we still need to document this funding state, but we may not want to require that people list their (irrelevant) funding.

Provisional Members

As mentioned above, we propose keeping this section in the governance document:

Nominate new Steering Council member: The proposer must provide a sufficient justification as to why the nominee should be welcomed into the Steering Council. Prior service to the community, including but not limited to: working on conda organization projects, writing conda specifications, and helping to bridge disparate communities are an important part of the nomination process.
(Emphasis added)

This criteria works really well for ensuring that Council members are invested in the community, and have a proven record of contributing to it before they can become part of community governance.

It does not assure commercial enterprises that, if they choose to commit funds to the conda ecosystem, then their voice will be heard, and their contributions will be given a fair evaluation by the existing community.

To better communicate our openness, and to quickly give these contributing organizations a voice at the table, we propose adding Provisional Memberships. Provisional Members have the same rights and responsibilities as other members, but have a different evaluation criteria for membership, and are subject to some restrictions.

In addition, no more than 1/3 of the Steering Council membership can be Provisional Members. Put another way, at all times, at least 2/3 of the Steering Council membership holds their seat because of their demonstrated contributions to the conda ecosystem. If these thresholds are violated then all other Council business is suspended until these requirements are met. The requirements can be met by dropping Provisional members, or by adding contributing members.

Details

Organizations that are not already involved in conda governance, and that are funding at least one FTE contributing to the conda ecosystem can request 1 provisional membership on the Steering Council. The evaluation criteria for evaluating this request should be based on the organization’s and the nominated person’s commitment to open source principles as demonstrated in other projects.

Provisional memberships are also expected to be temporary, lasting just long enough for contributors from that organization to demonstrate their values and earn representation just like everyone else. Provisional memberships can also be revoked at any time by a simple majority vote of the Steering Council, if and when the Council determines that the organization or the individual is no longer acting in the larger interests of the conda community.

Steering Council Size

We want the Steering Council to reflect a wide range of interests. We also want it to be small enough to be tractable and to have a reasonable expectation that quorum requirements can be met when votes are called.

Suggested minimum and maximum sizes for the Steering Council are:

• Minimum: 9
• Maximum: 21

The minimum of 9 works well with the minimum quorum size of 5 specified below. The maximum of 21 allows for a lot of participation, including as many as 7 Provisional Members, and representation from 11 to 21 different participating organizations.

Voting

This proposal has some impact on Council voting. Specifically, to prevent any one funder from being responsible for the majority of votes on any topic, the minimum quorum for a vote must be at least 5 members, or the specified council membership percentage for this type of vote, whichever is greater.

Steering Council and Project Teams Interaction

Will people associated with organizations that hold Provisional Membership have an easier entry to Project Team membership?

No. This proposal includes special Steering Council Provisional seats for new funding organizations. This encourages new organizations to get involved at the top level. However, contributors from these organizations must earn project team status just like everyone else: by first establishing themselves as contributing members to that project.

Can the Steering Council ever dictate that a Project Team must accept someone to their team?

Yes. But this usually isn’t directly related to their funding source. As per the current proposal, there are two types of active projects: Community and Federated. Federated projects are not required to be open to new membership. Community projects must be open to new members who demonstrate their capability and interest in the project through working with the project as a contributor first. If an application to join a Community project is rejected, the person can appeal to the Steering Council. If the rejected person can prove that they in fact meet the criteria for becoming a Project Team member and that they were rejected for inappropriate reasons, including their funding source, then the rejection will be overturned.

Voting policies and procedures in Community projects are established by each Project Team, subject to approval by the Steering Council.

Implications / Discussion

The Steering Council and the Project Teams have different roles and different motivations, and this model reflects that. Project Team members are heavily invested in their projects. This proposal aims to impose just enough oversight of Project Team procedures to ensure that membership and voting are indeed open and fair.

There is still a worst case here: A project may join as a Community Project, but in fact not be committed to open source principles. They could consistently reject “outside” applications for Project Team membership, even when applicants have proven their qualifications. This would result in the Steering Council overriding them, and a gradual shift in how that Project Team works. However, this would not be a pleasant transition for anyone involved, and the original team members would likely leave. This can be partially addressed by clearly communicating requirements for Community Projects before agreeing to add a new project

Trademarks

Community Projects need to license/assign their trademarks when entering the conda Organization. This is an act of good faith and communicates to the community that they are committed to our overall efforts.

The proposed trademark policy, in 3 easy pieces:

1. Trademarks are irrevocably licensed to the conda Organization's fiscal sponsor (will probably be NumFOCUS) when a project is added to the conda Organization as a Community Project.
2. The conda Organization in conjunction with our fiscal sponsor, then have the right to sublicense the trademarks to other projects, subject to specific limitations: The conda Organization may not degrade the distinctiveness of licensed trademarks, or use the licensed trademarks to disparage or misrepresent the assigner.
3. The Steering Council then makes trademark decisions, subject to agreed upon restrictions, and coordinating efforts with our fiscal sponsor.

There is a great discussion of trademarks in the context of the Dask project. Our governance model could also adopt several guidelines from that discussion as well. For projects that request to use conda Organization trademarks:

1. The project should be open source with a permissive license
2. The project should be related to the conda ecosystem
3. The project should be not be overly grand in claiming namespace
4. The project should not make subjective claims in the chosen project name

Examples of project names that violate the 3rd and 4th guidelines would be conda Pro, and google-conda-saves-the-day.

We are in an unusually challenging situation here because the conda name and logo are obviously derived from the Anaconda Inc. name and logo. We do however have some precedent to guide us: Projects like conda-forge (name), Bioconda (name and logo) and conda-lock (name) have been approved in the past. We should continue to expect that similar approvals will be forthcoming from the Steering Council after the core conda trademarks are licensed from Anaconda.

Finalization and Transition Proposal

A proposed plan for moving our governance model from Incubator status to "production" status

1. Establish a sub-team and channels to work on governance finalization

Does this work merit a formal sub-team? If so, we suggest a Dynamic Charter consisting of anyone who is in the Governance channel on Slack.

For communication channels we could use the Governance slack channel for discussion, and this issue for decisions and status updates.

2. Decide on what changes we want to make

Use our channels and calls to finalize our ideas. @tnabtaf sees this resulting in an updated version of the original proposal in this issue.

3. Translate those changes into our governance model

Take the ideas and convert them to formal text. Our intent must be spelled out in unambiguous text.

4. Set up transition from current Steering Council

Our current Steering Council membership exceeds the shared funding thresholds in this proposal.

A proposal:

1. To comply with the new limits, the vote to approve the new voting and membership model should also be a vote on what the initial membership of the revised council should be, once the new limits are applied. The new rules, and the revised council membership will happen simultaneously.
2. We will need to know the funders of every candidate for the revised council before we vote on the proposal
3. Currently, Anaconda, Quansight, and Voltron Data each fund more than the proposed maximum number of allowed council members (max: 2). We suggest that each block of members with common funding decide amongst themselves who will be on the revised Steering Council. We strongly suggest that anyone who drops from the Steering Council continue to be actively involved in community discussions and calls, and if you aren't already, join any conda or conda-incubator teams you are interested in.

To be clear, everyone on the current council will be eligible to vote on the rules change and the suggested revised Council membership.

5. Submit a pull request

The PR will apply policy changes, update the Steering Council, and move our governance documents from the incubator repo to the conda organization repo

6. Work with the Steering Council to address concerns and get approval

The existing Steering Council may want changes made to the proposal. Work with the Steering Council to clarify anything, explain our reasoning, and to apply updates.

Many, many thanks to Jannis Leidel (@jezdez), Matt Becker (@beckermr), Travis Oliphant (@teoliphant), Cheng Lee (@chenghlee), Peter Wang (@pzwang) and Van Lindberg for their feedback and help with this proposal.

Dave C

PS: "Feedback and help with this proposal" ≠ full endorsement of everything in this proposal!

[beckermr]

Thanks for this. We still need a mechanism for steering council members to leave if we are going to have a maximum. This could be a limit on the time someone is emeritus.

[teoliphant]

I'm curious about the reasoning for the Steering council size minimums and maximums. My view is that steering councils should be representative and small so that governance work can proceed without too much overhead. I have experienced large steering councils before and ultimately they end up taking a lot of overhead to maintain and manage. We don't have great tools (i.e. an app or crypto multi-sig for managing asynchronous coordination between people). I would prefer to see something like the minimum being 3 and the maximum being 9.

[kenodegard]

@teoliphant see this conversation (#51 (comment)) for the minimum/maximum, @tnabtaf should have more context for why the maximum was dropped

[mbargull]

gh-51 is about to pass.
There are a few outstanding review comments mostly regarding council size, declared funding state/sources/etc.
Referencing them here to keep track of them since (IMHO) we should revisit/discuss those concerns further:

• Governance Finalization #51 (review)
• Governance Finalization #51 (review)
• Governance Finalization #51 (review)

[beckermr]

We should leave this one open. Thanks for collating the comments @mbargull!

[tnabtaf]

Hi All,

The original min and max were set to 9 and 21. I picked 21 by taking the current size of the steering council (high 20's I think), then determining common funding for current members, and then knocking down each common funding block two 2 people. That gave me 21. We added a max size because Van Lindberg suggested that having a max size would let interested companies know how maximally diluted their council votes would be.

By then @CJ-Wright raised the case where someone might leave a funder, but not leave the council. That's fine if the council is not at maximum size, but if it is, it means that either the member's former company would no longer be able to get a seat, or that the person would have to quit. Neither of those seemed good, so we eliminated the maximum.

For @teoliphant's proposal, I don't think that a maximum of 9 will be workable for this community. I point to all the discussion about people being forced off now because of the two person common funder limit. I can imagine the pain if we went down to just 9 people.