Related to the currently running application to the NumFOCUS fiscal sponsorship, I'd like to formerly propose a few steps to clear up some organizational debt we've accrued over the years:

• create a steering council GitHub team with owner permissions in the conda GitHub organization
• move the following repos from the conda-incubator to the conda GitHub organization:
  • governance
  • ceps
  • conda-dot-org
  • assets

Any other things we should fix at the same time?

Several of us are meeting on Monday, August 29 to launch an effort to get a conda community website up and running, hopefully this year. We would like to have a conda-incubator project while we define this effort.

We anticipate that whatever technical solution(s) we choose, it(they) will all place website content and infrastructure within a GitHub repository. This approach will support easy community contribution to the web site, and will also allow us avoid hosting costs for the web site.

Once we have a prototype implementation and minimal viable website content, we anticipate submitting a CEP to formally propose launching the website and taking this effort out of incubation. At that time we will also propose the formation of either a Website subteam, or a Community (or Outreach?) subteam to manage the repo and website.

See/Join the conda-dot-org Slack channel for more.

A github repository (probably inside conda or conda-incubator) where community members can submit health-check plugins that run with conda doctor.

References
conda/conda#12854

https://github.com/conda-incubator/governance/blob/main/steering.csv

Any serious plans to add non-"he/him" to this list? If so, I am interested in checking them out.

Currently, 12/16 are "he/him", assuming the others are unknown/tbd.

@jakirkham @jezdez We should settle on one thing. I don't think it matters what we do, but we need to be consistent.

As we (Quansight) consider, moving conda-store to conda-incubator, one thing that we are likely to want to do is call out some of the (fiscal) sponsors of that project in either the readme or the project website. I didn't see anything in the governance docs about this (or I missed it).

So two questions.

1. Do we need guidelines around this for incubator projects
2. Do we need guidelines around this for core projects

The main purpose for this is to encourage companies to participate/fund efforts to improve the Conda ecosystem. We have clients who want to be seen as good open source citizens and this is one way that they can do that. It would also be nice for the current core companies that are on the steering council and heavily investing in Conda to be acknowledged somewhere.

A somewhat related discussion from the dask community is here: dask/community#44

@conda-incubator/steering Here's my official proposal to create a new conda infra team

Proposal

I'm proposing to form a new "Infrastructure" subteam

Team Charter

Following the governance policy, this is a static charter with the additional condition that any member of the steering council may join this team if they so choose without the approval of the rest of the steering council.

The "Infrastructure" subteam helps with maintenance of the developer and community infrastructure of the conda project, as delegates of the conda steering council.

That includes the conda, conda-archive and conda-incubator organizations on GitHub and related lower-level infrastructure systems that enable the steering council, projects under the conda governance policy and the larger conda community to participate in an effective, open and transparent Open Source ecosystem.

Work areas

• maintenance of GitHub repository settings and permissions
• responding to and coordinating of feedback in infrastructure-specific discussions in the conda/infra repo, e.g. coordination with other community stakeholders
• respond to project maintainer feedback about continuous integration systems and similar build systems
• password management of backend systems
• shared GitHub workflows and actions
• documentation system setup
• domain management (e.g. conda.org)
• maintenance of the existing repositories:
  • https://github.com/conda/.github
  • https://github.com/conda/actions
  • https://github.com/conda/infra

Scope

The "Infrastructure" team works as delegates of the conda steering council and follows the Conda Code of Conduct. It provides the necessary help to members of the conda ecosystem, when they request it, and limits its scope of work according to their roles and responsibilities mentioned above.

Proposed members:

• @jezdez
• @kenodegard
• @dbast
• @beckermr

EDIT: Changed from "dynamic" to "static" charter, meaning:
EDIT 2: fleshed out team charter
EDIT 3: added actions and .github repos

Vote

This proposal falls under the "Sub-team Formation" policy of the conda governance policy, please vote and/or comment on this proposal. It needs 50% of the Steering Council to vote yea to pass.

To vote, please leave "Yes" or "No" below as comments.

If you would like to propose changes to the current proposal or have questions, please leave a comment below as well.

This vote will end on 2022-02-01.

Following the governance policy for subteams, as mentioned on the conda slack team, I'd like to initiate a communications subteam to better coordinate communication in the conda organizations.

See the formal proposal below.

As a first step, I'll propose to participate in the subteam as the required steering council member, but I'd like to invite other steering council members to join as well, if they are interested in this area of work.

Please respond below in case you're interested in joining the subteam.

The meeting left me feeling frustrated, and I've heard similar sentiments from a few of you. I want to discuss my perceptions, reconcile them with yours, and work on ways to have better meetings in the future.

In my humble opinion, it was unfair to say at the beginning of the meeting “we won’t be talking about the transfer of conda/conda-build/constructor/conda-pack projects” and then expect Cheng or other Anaconda team to cover when Peter and Michael Grant already left after they thought their part wouldn’t come up. I don't remember the exact language, but I'm hoping we can collectively agree on what was said, and why Peter and Michael Grant decided that they didn't need to stay.

Furthermore, the meeting felt very aggressive and impatient towards Anaconda. I am perhaps a bit biased towards Anaconda, given my past role there. What I will point out as an outsider is that Anaconda is trying to help, as evidenced by efforts to change the CLA system. That CLA system work is 100% selfless time for Anaconda - it does them no benefit, and only helps this community effort. We all need to find ways to move this community forward, not just make demands on Anaconda.

I perceived lots of discontent from several people at the meeting, but I'm not at all clear what their goals are, nor what any milestones might be. We need to focus on some achievable targets. I see several possibilities. For each of these, please bear in mind that there may be additional prerequisites to making these happen. Those would need to be negotiated individually.

1. Splitting code from major projects into new, community-owned repositories, which the major projects then depend on. This is similar to what was done with conda-package-handling. Any new projects would need to be identical in behavior/support with existing projects in order for the existing projects to use them. This task can be started now by any community member. Replacing the conda/conda-build code with the split-out library would need more participation on the Anaconda side.
2. Hold community meetings to establish roadmaps. Note that any roadmap that is just a wishlist for Anaconda will fail. Community input on the roadmap implies community effort on achieving it.
3. Community members have ability to merge PRs on projects
4. Community members have ability to tag releases
5. Community members have ability to add new maintainers to projects
6. What else? I'm sure there's lots.

Perhaps we need some way of prioritizing these? Ranked choice voting? Whatever we do, we need to get to a place where we ask "what can I do (minimally involving Anaconda) to help move this along" and not "why is Anaconda blocking this?" Again, I no longer have direct insight into Anaconda's activities. My experience, though, and Anaconda's efforts on things like the CLA bot, indicate that Anaconda is acting in good faith, and they deserve the benefit of the doubt.

One of the unconference segments in the NumFOCUS summit 2023 in Amsterdam was dedicated to packaging and we spoke a lot about how PyData maintainers experience friction when they are testing workflows or contributing packages to the conda ecosystem. One of the action items hinted at the necessity for better documentation and educational materials.

Inspired by the Numpy Newcomers meetings, I wonder if the conda (and conda-forge) communities would benefit from having such a space where novice (or not so novice!) users can pass by and ask their questions. Our current community calls have a tint of core decision making, expert discussions and reporting that might make it unaccessible or daunting to those that just want to solve a couple doubts.

My intention would be to run this session one hour before the core calls in case the attendees want to stay. With good note taking, we might be able to accumulate good documentation drafts for proper content in conda.org, FAQs and whatnot.

Tagging @travishathaway and @tnabtaf for their interest and alignment, but anyone is welcome to drop their thoughts here!

As part of recent discussion around governance, a somewhat smaller (though still quite important) point about what date deadlines mean came up. In particular when a deadline is reached. This comment ( #51 (comment) ) suggested AoE (Anywhere on Earth) deadlines might make sense. IOW the deadline is reached when Anywhere on Earth is past that deadline. This makes a lot of sense given our distributed nature. Adopting this clearly and clarifying it would help avoid future confusion around deadlines.

cc @beckermr @jezdez

Name:

Code of Conduct Finalization Committee, to be replaced by the
Code of Conduct Committee, once a proposal is adopted by the Steering Council.

Role and Responsibility:

The Code of Conduct Finalization Committee will be responsible for

• Finalizing our current code of conduct
  • Implement supporting infrastructure for the committee, such as reporting forms and email addresses.
  • Update existing policies and add other content.
• Nominating the initial members of the Code of Conduct Committee. These will be listed in the pull request submitted to the Steering Council for approval.

The Code of Conduct Committee will be responsible for

• Maintaining a welcoming and safe culture in the conda ecosystem
  • via the mechanisms described in the CoC document.
• Nominating replacement members as committee members depart.
  • This process will be described in the proposal.

The driving goal of the CoC Committee is:

Maintaining a welcoming and safe culture in the conda ecosystem

This will drive numerous subgoals in the Code of Conduct, including promoting a welcoming and safe culture across the ecosystem, having clear mechanisms for reporting, and taking prompt action on any reported or observed incidents, and, whenever possible, informing the community when incidents happen, and what actions were taken.

We will strive to incorporate current best practices from other projects.

Charter:

We are seeking a Dynamic Charter. We believe that the Code of Conduct committee should be as independent as possible from the Steering Council. Unfortunately, there are well known examples of leadership in open source projects being the source of Code of Conduct violations. Therefore we believe the Code of Conduct Committee should be able to select its own members, and also have minimal overlap with the Steering Council membership.

Initial Members:

The Finalizing committee will finalize the Code of Conduct, and will include in that document nominations for the Code of Conduct Committee that will take over once the Code of Conduct is approved. We expect some overlap between the finalizing committee and the first actual committee.

Initial Finalizing Committee members:

• Crystal Soja (@csoja), Anaconda
• Eric Dill (@ericdill), Voltron Data and conda-forge
• Ken Odegard (@kenodegard), Anaconda
• Mahe Khan (@ForgottenProgramme), Anaconda
• Filipe Fernandes (@ocefpaf), IOOS/NOAA
• Dave Clements (@tnabtaf), Anaconda

Note:

• This initial membership is Anaconda and North America heavy. However, we are an open committee and hope to add more interested people as we go.
• When finalizing the Code of Conduct, we are likely to add restrictions on what percentage of that committee's members can come from one organization. Thus any skew in the finalizing committee will not be perpetuated in the actual CoC committee.

As discussed in the conda community meeting of June 8th, we asked if we could create a new team to guarantee the maintenance of constructor, menuinst and conda-pack.

These are the people that I know they expressed interest in being part of these efforts:

• @jaimergp
• @jezdez
• @pseudoyim
• @chenghlee
• @isuruf
• @hmaarrfk
• @hoechenberger
• @larsoner

Hi @myancy-anaconda!

I hope you have been well. Would you like to remain active in the conda organization or should we move you to emeritus?

You are more than welcome to stay active, but we have not seen you in a while.

Following changes at anaconda inc and the creation of conda/ceps and https://github.com/conda-archive, it seems to be time for us to revisit the governance, proposing an update and voting on it.

I am starting this issue to gather comments/feedback.

cc @jezdez

In order to help us manage a curated list of plugins, we will need to form a sub-team for this purpose as specified in our code of conduct. This sub-team will be responsible for approve which plugins get promoted to a special index which will be promoted on platforms such as the future conda.org website.

What needs to be done?

• Find at least one steering council member to be a part of this team
• Find at least one non-steering council member to join
• Create a pull request against this repository outlining exactly who is on the team and what it's purpose is. Exactly how to do this is yet to be determined. Stay tuned! 😅

Following the terms defined under "Teams & Roles", I was wondering if it's time to ask the core team if anyone wants to become emeritus-core (e.g. since some have moved on)?

Core members that are inactive (commits, GitHub comments/issues/reviews, dev meetings, and voting on polls) in the past six months will be asked if they want to become emeritus-core developers. One week after asking, if the inactive core member has not responded, they will be automatically moved to emeritus status.

Full disclosure: I'm not a core member (read: applied and voted in by the core membership) and can't do this myself.

Hello everyone, I would like to move the conda-recipe-manager project to conda-incubator.

We hope that this move will allow others to easily contribute to our recipe automation efforts. To start, our primary focus is on the conversion of our existing recipe format to the new "v1" format proposed in CEP-13 & CEP-14

I am currently working through migrating this work from another Anaconda project, percy. As of writing this proposal, the conversion is not complete BUT most of the applicable code and configuration files have been copied-over.

I would like to migrate the repository at: https://github.com/anaconda/conda-recipe-manager
I would like the existing build-team to manage this project.

I am submitting this issue for the historical record. Any feedback is welcome and appreciated! Thanks!

(The text of this issue was heavily based on the precedent set by Issue #108)

Hi team, the conda-tui team would like to move our project to conda-incubator.

I would like to migrate the repository at: https://github.com/anaconda-hackdays/conda-tui

And create a conda-incubator/conda-tui team with the following collaborator: @mattkram

I am submitting this issue for the historical record. Any feedback is welcome and appreciated!

As our new governance in #51 has passed, we are now in the situation where we likely have exceeded some limits on people per funder and most steering committee members do not have their funder listed.

I am opening this issue to track the changes so we can get back to business.

@conda-incubator/steering Please add your funding state and work amongst yourselves to adjust things!

This vote is to ratify the conda governance document in its current form, which you can read here.

This PR falls under the ratification policy, please vote and/or comment on this PR.
This vote needs 75% of votes yea to pass.
To vote please leave Approve (yea 👍) or Request Changes (nay 👎) reviews.
If you would like changes to the current language please leave a comment to be incorporated on the next version.
This vote will end on August 13th, 2020.

We keep notes of our meeting in this repo, but we have a little gap between June 2022 and March 2023. AFAIK the notes are still in the HackMD team, but it'd be nice to have a copy here too.

Proposal

I’m proposing to form a “Technical Review Board” subteam to improve the process of authoring, reviewing and voting on Conda Enhancement Proposals.

Team Charter

Following the governance policy, this is a static charter with the additional conditions that:

• any member of the Conda Steering Council may join this team at any time
• the number of non-steering TRB members is at most 3
• the Conda Steering Council may change the number of non-steering TRB members via a simple majority vote
• the non-steering TRB members are elected, and can also be removed, by the Conda Steering Council in a secret ballot similar to sensitive voting items listed in the Conda Governance Policy
• the vote threshold for addition or removal of a non-steering TRB member is a simple majority
• the elections happen annually after an application period of 2 weeks before the election date
• the Conda Steering Council will call for applications
• applications must contain a short statement by the candidate towards confirming their credentials and their ability to work as a technical reviewer
• the Conda Steering Council retains the right to call votes on CEPs without the approval of the TRB

Work areas

The Technical Review Board is charged with the following:

• follow the Conda Code of Conduct
• act in the best interest of the conda community
• provide their technical expertise to the conda governance process
• facilitate the review, handling and shepherding of Conda Enhancement Proposals that are labelled as "technical"
• enable the Conda Steering Council to vote on technical CEPs

Responsibilities

• co-maintenance of the conda-incubator/ceps repository, especially of CEPs labelled "technical"
• guide and mentor the CEP authors in scope of this team charter
• provide quarterly reports to the Conda Steering Council about the current status of the technical CEPs
• submit all technical CEPs that are deemed ready for vote by the CEP author(s) and TRB for vote to the Conda Steering Council
• provide a recommendation to the Conda Steering Council (e.g., “Our vote recommendation: yes”)
• to reduce the effort needed by the Conda Steering Council, the technical CEPs may be submitted as an omnibus proposal set (read: one vote for many technical CEPs)
• if the vote by Conda Steering Council does not match the TRB’s recommendation, the technical CEPs must be reviewed again by the TRB and may be submitted in the future, after appropriate changes are made
• communicate the voting results to the CEP authors and communications team

Scope

The “Technical Review Board” is working for the Conda Steering Council and follows the Conda Code of Conduct. The team provides guidance to new and existing authors of Conda Enhancement Proposals with the objective to submit the proposals for vote to the Conda Steering Council individually or optionally as part of a regular (quarterly) omnibus set.

The team in particular exists to enable the Conda Steering Council to conduct votes on matters that require deep technical understanding and to facilitate the participatory process.

Initial applications

As part of the adoption of this proposal, I suggest to:

• vote on the proposal (see below)
• if passed, call for applications for the founding Technical Review Board

Since we're now starting to add a few non-project subteams such as the communications and infrastructure team, we should start tracking them for easier maintenance via PRs and record-keeping.

Maybe it would suffice to have a SUBTEAMS.md that lists the teams from top to bottom, including their team charter, members and important links like chat rooms etc.

If we're making sure the content is nicely formatted, we could even possibly render it as part of the conda-incubator/conda-dot-org work when it's ready?

Hi All,

You may have noticed recent activity in the conda-governance incubator project. So far changes have been limited to typos/formatting (PR #40), and clarity updates (Issue #41)—updates that don’t change policy in any way.

However, that is about to change. I really, really want to get our governance out of incubator status and into actual use. In the next 2-3 months look for these three efforts:

1. Code of Conduct

We need to have a working, welcoming, and enforceable code of conduct and we need it soon. Not having this sends absolutely the wrong message to both current and potential community members.

Our current draft code of conduct is a copy of the NumFOCUS CoC template. It’s a great place to start, but I suspect we could improve it some before we adopt it. We are also going to need a CoC committee to respond to reports.

Expect an issue in a week or two about the CoC. If you care about CoCs then please join that discussion (and maybe the committee too). Several of you expressed an interest on the most recent conda community call. Expect a shout when this issue is created.

2. Fiscal Sponsorship

The conda Organization has historically been funded by Anaconda, Inc. and is currently not Fiscally Sponsored by a non-profit. conda is a NumFOCUS Affiliated Project, but that doesn’t allow the conda Organization to handle trademarks, and we can’t deal with outside funding in any way (receiving or distributing).

Expect an issue (maybe in May?) about applying for fiscal sponsorship, probably with NumFOCUS. Their next application review period is in July. If you have experience with fiscal sponsorship or with NumFOCUS then please consider joining this discussion.

3. Propose a Novel Voting and Membership Structure for conda Governance

A widespread and continuing issue in open source is how to encourage contributions (including input on project direction) from commercial entities, while avoiding having companies’ financial interests override what is best for the overall community.

Look for an issue proposing a Steering Council model that considers the source of Council members’ financial backing when weighting the Council votes of individual members. Whenever more than one Council member has common funding the weight of their votes will be reduced compared to Council members that do not share common funding sources with other Council members. We hope to propose a weighting that makes it impossible for any one company (or grant consortium) to unilaterally enforce its will on the conda Organization.

Of course the devil is in the details. We hope to publish a draft proposal by the end of April. We are pretty sure there will be plenty of discussion on this one.

Thanks for reading this far. Please let me know if you have questions, and please keep your eyes open for governance issues in the next few months.

Cheers,
Dave C

Hi all,

A new governance model for the conda community has been in the works for several years. This topic has a huge amount of interest (it came up in last week's libmamba webinar Q&A; it was the first topic of discussion spawned by the opening of the @condaproject account; it is the topic of our two already open issues; ...).

I started as an Open Source Community Manager at Anaconda in December of 2021. I am the first person to have this position. Getting community conda governance in place is currently my biggest task. This issue, and this PR #40 are the first two baby steps before addressing harder issues like policy and conduct committee membership. PR #40 deals with typos and formatting in the current governance proposal. It also includes small fixes to improve clarification.

However, there are a number of things where it is not straightforward what the intent of the text is (to me anyway), and that's what this issue is about: seeking clarity on those (or other points).

Here goes:

Voting Ties

The document implies in at least two places that if there is a 50-50 tie in the voting, that the "Yes" votes win.

Q: Is that what we want?

If so, we should say that explicitly. If not, we should say something like:

Votes require more than half of the total votes to pass. Ties result in a "no" decision.

Voting and Maintenance Teams

First, the current verbiage seems a wee bit dominant to me. An example:

The core team is the only team with voting rights.

Second, it is rarely explicitly stated which type(s) of teams each voting rule is for. Is there any objection if I

1. modify wording to say: core and maintainer teams have distinct responsibilities, and therefore different areas where they vote in.
2. Indicate in each situation discussed if this rule applies to core, or maintainers, or both.

I would attempt to preserve current policy in every way.

Grant Proposals

The current text is confusing to me. It is:

Prior to their submission, grant proposals must be supplied to 
the core members and a vote called under the Spending of funds 
policy. If the vote does not pass the proposal is not to be 
submitted in its current form and an additional round of voting 
is required on any subsequent draft. If the vote passes and the 
funds are awarded, further voting to spend the funds is not 
required.

Maybe it's just me? Is there a more direct way to say what we are trying to say?

Nomenclature

Note: This is not a point of clarity, but is does not involve policy changes, only nomenclature changes; and it strikes me as something we should do sooner rather than later.

The document talks about Core and Maintainer teams. I (and others) argue that both of these terms are sub-optimal.

Core

First Core does not tell people what this group does. It is also slightly confusing: every repo we have has a core of people supporting it. Finally, Core sounds vaguely exclusionary to me.

Some options:

• conda Steering Committee
• conda Governing Council
• conda Leadership Council

I dunno, but something.

Maintainers / Maintenance

Our current title is descriptive of what the groups do, and our naming does not strike me as exclusionary in any way. But, I don't think Maintainers is a compelling word either. I would love to have something that great in an email invitation to join the team:

• Dear X,

  We could like to formally invite you the join the Maintenance team for project Y in the conda Organization.

See?

I'm fine leaving this term as it is, but if someone has a cooler idea then now is a convenient time to change this.

Thanks everyone. Discussion is encouraged.

Cheers,
Dave C.

What's the idea?

I was recently reading through the governance document to figure out exactly how projects move from conda-incubator to conda. Even after reading these two sections:

1. Incubation
2. Project Team Details

In order to make the process of graduating from incubation to conda a little more clear, I propose adding a special section that defines this process in more of a linear way and perhaps even uses examples to make it more clear.

Additionally, we could even add a check list temple issue for this repository that incubation projects could use when making the jump to "conda". This template could look like the ones we have for releases:

https://github.com/conda/infra/blob/main/.github/sync/RELEASE.md#1-open-the-release-issue

Hey team, the conda-store team would like to move their projects to conda-incubator.

This means transferring:

• https://github.com/Quansight/conda-store
• https://github.com/Quansight/conda-store-ui
• https://github.com/Quansight/jupyterlab-conda-store

And creating a conda-incubator/conda-store team with the following external collaborators:

• @dharhas
• @pierrotsmnrd
• @costrouc
• @aktech
• @anirrudh
• @trallard
• @pavithraes
• @iameskild
• @smeragoel
• @steff456
• @asmeurer
• @kcpevey

I am submitting this issue for the historical record, but any feedback is welcome and appreciated!

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!

Hi All,

The last of the three major goals in the Finalizing Governance issue (#43) is Fiscal Sponsorship:

The conda Organization has historically been funded by Anaconda, Inc. and is currently not Fiscally Sponsored by a non-profit. conda is a NumFOCUS Affiliated Project, but that doesn’t allow the conda Organization to handle trademarks, and we can’t deal with outside funding in any way (receiving or distributing).

Applications are due by July 15. With that in mind, I have walked through the NumFOCUS application form and created draft responses to each question (see below).

Note that this application has been given a lot less thought and by a lot less people, than have the Code and Conduct and Governance proposals. Most of these items will be only included in the application, but some of them will end up on the Conda project web page at NumFOCUS. Please review this proposal in the next few weeks. Improvement to anything, but especially text that will eventually show up on the NumFOCUS website, are strongly encouraged.

1. Does your project have a contributor Code of Conduct? (Yes/No)

Yes

2. What is the name of your project?

conda (or is it is Conda? See this conda-docs issues).

3. Please provide the url of your project's (primary) repo:

https://github.com/conda

4. Your project's website:

We currently are focused around our two GitHub organizations:

1. https://github.com/conda
2. https://github.com/conda-incubator

We are planning to turn conda.org into a project community website later this year.

5. Please provide a summary description of your project in a few sentences:

Conda is an open source package management system and environment management system that runs on Windows, macOS, Linux and z/OS. Conda quickly installs, runs and updates packages and their dependencies. Conda easily creates, saves, loads and switches between environments on your local computer. Conda supports software written in any language.

6. Does your project have a logo?

Yes

7. Please upload a .svg file of your project's logo. A "square" format is best.

Will use the conda C logo

8. Your project's Twitter handle or other social media handles/urls

Twitter: @condaproject

9. Why do you want your project to join NumFOCUS?

The Conda Organization currently has no legal status. We cannot accept funding or formally sponsor work or events, and we can't manage trademarks. Joining NumFOCUS enables us to do all those things, and would also raise Conda's visibility in the open source scientific software community.

10. Are you applying for Fiscal Sponsorship or Affiliation?

Fiscal Sponsorship

11. Is your project wanting to apply for the Comprehensive or the Grantor-Grantee fiscal sponsorship model?

Comprehensive.

12 .Please provide us with the following information about your project:

A. The publicly visible location of your governance document:

This is currently under Conda-Incubator project on GitHub.
https://github.com/conda-incubator/governance/blob/master/README.md
It will be moving out of the Conda-Incubator and into the Conda repo this summer. It will then be at https://github.com/conda/governance/blob/master/README.md

B. The publicly visible location of your roadmap

https://github.com/orgs/conda/projects/2/views/1

C. URL to “how to get started as a contributor” documentation:

The Conda Developer Guide is at https://conda.io/projects/conda/en/latest/dev-guide/index.html

D. The names and email addresses of five people willing to act as signatories for your project:

⇒⇒⇒⇒ We need 5 volunteers from the Steering Council here.

1. Matthew R. Becker, [email protected]
2. John Kirkham,
3. Marius van Niekerk,
4. Jannis Leidel, [email protected]
5. Crystal Soja,

And what are signatories? They are the ones who sign the contract with NumFOCUS. The most relevant bit of that contract is

The Signatories, each a signatory hereto, hereby establish and comprise the initial members of the {{Leadership Body Name}} to carry out the Project's activities as stated in §3. The Signatories acknowledge that the {{Leadership Body Name}} shall be subject to all of the terms of this Agreement. As of the effective date of this Agreement, the Signatories hereby transfer all rights, benefits, obligations, and privileges under this Agreement to the {{Leadership Body Name}}.

Which to me says that the signatories are signing for the Steering Council, and the Steering Council is now responsible for what is in the document.

E. The name of your project's leadership body: It cannot contain the word "board" other than that it can be whatever you choose.

Conda Organization Steering Council

F. A physical mailing address for your project

None. Or someone's home address?

G. Please provide a short description of your project geared toward funders/grantors/non-expert audience: See example at the top of the page here: https://numfocus.org/project/pandas

Conda is widely used to simplify installation of open source software across operating systems, and to cleanly manage multiple (and possibly conflicting) run time environments on the same computer.

Or a one liner:

Conda simplifies dependency and environment management for open source software.

H. Please provide a short project description for developers/users: See example under “Technical Details” tab at the bottom of this page: https://numfocus.org/project/pandas

Conda is an open source package management system and environment management system that runs on Windows, macOS, Linux and z/OS. Conda quickly installs, runs and updates packages and their dependencies. Conda easily creates, saves, loads and switches between environments on your local computer. Conda supports software written in any language.

I. Please provide us with a a few sentences describing the known applications of your project: See example under “Applications” tab at the bottom of this page: https://numfocus.org/project/pandas

Conda is an operating system, programming language, and domain agnostic tool. It is used in education, research and commercial applications to simplify software installation and manage run-time environments.

OK, that is not very specific, but it is true…

J. Please provide us with project Industry, Languages, and Applications tags:

What Industries is your project mainly used in? Ex: Government, Higher Education, Finance, Business Applications, etc.
What Languages does your project use? Ex: Python, C, Javascript, R, Julia, etc.
What are some simple one or two-word applications for your project? Ex: Data Wrangling, Numeric Computing, Modeling, Visualization, etc.
See example here: https://numfocus.org/project/pandas

• Education, Government, Finance, Business, Artificial Intelligence, Science, Research

K. Any upcoming or annual events held by your project

Sprint at SciPy 2022, July 16-17, 2022

L. Link to your project's blog or newsletter:

We do not have one. One will appear on conda.org later this year.

13. How does your project relate to or integrate with the existing ecosystem of NumFOCUS tools?

Many NumFOCUS tools have been packaged in Conda, and are widely deployed using Conda. The most closely integrated project is conda-forge (https://numfocus.org/project/conda-forge). Most of the NumFOCUS sponsored tools are available in conda, usually through conda-forge, including:

• NumPy
• Matplotlib
• pandas
• Project Jupyter
• IPython
• SciPy
• nteract
• Stan
• PyMC
• Julia
• PyTables
• Shogun
• SymPy
• FEniCS Project

And then we stopped looking. Of the first 15 project listed on the NumFOCUS at least 14 of them have been made available through conda

14. Describe how your project furthers the NumFOCUS mission: https://numfocus.org/community/mission

The mission of NumFOCUS is to promote open practices in research, data, and scientific computing by serving as a fiscal sponsor for open source projects and organizing community-driven educational programs.

Conda enables tool developers to create versions of their tools that can be easily installed on many different operating systems. This lowers the barrier to using these tools and allows many users who otherwise could not manage installation of software dependencies, or multiple run-time environments.

15. How many active contributors does your project currently have?

The Conda ecosystem consists of several projects. From June 2021 to May 2022 these projects had 5 or more contributors (commits only)

16 - grayskull
14 - conda-build
13 - conda
13 - conda-docs
13 - conda-lock
9 - constructor
8 - governance
7 - conda-package-handling
6 - conda-pack

The number of unique committers across all projects is likely around 25 to 30.

16. Any comments you’d like to make on the number of your active contributors:

The number of committers is easy to measure, we believe this is a poor indicator of active contributors. This does not include Pull Request reviews, call participation, training, code of conduct committee membership, and many other types of contribution.

17. What is your project doing to attract and/or mentor new contributors and maintainers?

We are holding a sprint at PyCon 2022. We also are planning to work with Outreachy for their upcoming intern cohort.

18. Where do you host conversations about project development and governance (e.g. mailing lists, forums, etc.), and how many participants do you have?

These are hosted in several places:

1. Issues in the conda and conda-organization GitHub repos
2. Slack, 100 people

We also have forums for users:

1. Google Group https://groups.google.com/a/anaconda.com/g/conda, 858 members
2. Gitter https://gitter.im/conda/home, 712 people

19. What license(s) does your project currently use?

We require a permissive license. Licenses currently in use include

• BSD 3-Clause (most common)
• MIT (next most common)
• BSD
• CC-By-4.0
• CC0-1.0
• Apache-2.0

20. Projects must adopt the NumFOCUS Code of Conduct or one similar in spirit. Please tell us how you plan to meet this requirement:

Our Code of Conduct is currently in incubator status, and is based on the NumFOCUS template. We expect this to be fully deployed this summer.

21. Your Name (First & Last)

Dave Clements

22.Your Email

[email protected]

23. Questions or Comments:

There was some discussion in the steering council chat room about record-keeping and discoverability of onging and past votes, since the they are becoming harder to track down.

As such @jakirkham and me are suggesting to do:

• require votes to be submitted as PRs to a to-be-created votes directory in this repository
• automatically request review from the steering council GitHub team via CODEOWNERS
• automatically assign the vote Voting following governance policy label
• update the governance policy to mention the use of pull requests (which may trigger a governance policy change vote)

We also may want to look into if there is already a service that would provide automated vote reporting for standard votes (read: public ones).