conda / governance

The Conda & Conda-Incubator Governance Policy
Creative Commons Attribution 4.0 International
25 stars 28 forks source link

Move kkraus14 back to steering council. update funding status #74

Closed ericdill closed 1 year ago

ericdill commented 1 year ago

According to our new governance docs,

Nominated members will provide a list of organizations that fund above 25% of their time. ... In cases where people have absolutely no funding related to conda, we still document this funding state, but we do not require people to list their irrelevant funding. The "no funding" state can be held by an unlimited number of Steering Council members. What about cases where someone works on conda for work they are doing, but improving/directing the conda ecosystem is not a specific component of any of their funding? Generally, such cases should be considered as "no funding."

While the three of us (@kkraus14, @mariusvniekerk, and myself) work at Voltron Data, we are not funded to work on or participate in the conda ecosystem. According to our docs this puts all of us in a "no funding" status. Therefore it is irrelevant that the three of us work at Voltron Data and Keith should not have been forced to move to emeritus.

Refs #58

jezdez commented 1 year ago

This change seems to have been in mistake, the vote in question as documented in https://github.com/conda-incubator/governance/pull/51 had a "Set up transition from current Steering Council" part in the pull request that specifically called out Anaconda, Quansight and Voltron Data as parties to reduce their size to 2 to balance out the steering council.

This may have been missed by some here, the intention obviously of the governance update was strengthening the steering council by reducing the number of steering council members from common funding sources (e.g. companies).

tnabtaf commented 1 year ago

Hi all,

@ericdill, @chenghlee, and myself met to discuss this PR, and I have discussed it with several others as well. I'll try to summarize our (sometimes conflicting) goals, and then propose a solution. I'll also briefly discuss some other options that I think are less desirable than the proposed solution, but that could still work. Discussion is encouraged.

Goals

The goal of the two-person limitation in the recently adopted governance model is to

We always want the conda Organization to be driven by what is best for the larger community, not by the interests of any particular organization. The interpretation offered by Eric does not achieve this goal.

Eric's goals (@ericdill, please correct me when I go astray) are to

  1. Welcome anyone who has the time, energy, and knowledge to contribute to the conda Organization. We should not be turning people away just to prevent capture.
  2. Formally recognize the contributions of people who are currently excluded by the two person limit. The current governance makes vague mention of voting and non-voting members. "Non-voting member" is not actually defined anywhere, and they certainly aren't listed anywhere.

In my opinion, the goal of preventing capture is non-negotiable. How we achieve that goal in combination with these other goals is the subject of the rest of this post.

Background (you can skip this part, really)

This conflict came up during drafting of the proposal, discussion of the proposal, and the final vote on the proposal. And Eric's post shows that the concern has not gone away.

The initial (and not widely circulated) draft of the new governance included a weighted voting scheme that did not limit the number of Steering Council members, but did limit the voting weight of funded blocks with more than two members. Each new member past two would add a fractional vote to that block's total vote. The fractional vote added would decrease with each new member in a funding block.

This system was a thing of beauty! (And I will write a book about it one day. ;-) It was also very complicated and would lead to a lot of confusion and likely unnecessary conflict too. So we flipped from complicated to the simplest thing we could think of: the two person limit that we adopted. The simple system is (relatively) easy to explain, and is in use by other open source organizations.

Options for achieving all our goals

Here are several options that would preserve the no-capture goal, while also achieving Eric's inclusion goals. I am listing the options in my order of preference.

1. Create a Technical Council and delegate technical decisions to it

In the current governance model the Steering Council is responsible for governance and technical decisions that affect the community. We could create a Technical Council that the Steering Council would delegate technical decisions to.

My guess is that most people are actually more interested in technical decision making than they are in governance and cultural decisions. The Technical Council would have a different set of membership rules, that are more open, but that rely on the Steering Council's tighter rules when there is conflict:

2. Formally define and add non-voting members

Formalize what is informally stated in the current governance: We would explicitly list non-voting members, calling them something like "Consulting Members." This would expand the pool of people who are on the Steering Council. It is also an easy change to make.

The Steering council would keep the current 2 person limit for voting members. We would also drop the "no funding" provisions of the current document. All members would need to specify their funding.

Comments

I'm not sure how many people would want to be a "Consulting Member."

3. Open Steering Council membership; Add limiting option

This option would not restrict Steering Council membership based on shared funding. Most votes would proceed on a one-member one-vote basis. To prevent capture, a few provisions would be added:

4. Weighted Voting

We could reconsider the weighted voting proposal that was in the initial draft. This would give everyone who is interested a voice and a vote, while also limiting control based on shared funding.

Comments

This achieves our goals, but greatly increases the complexity and amount of text in our governance. This could be made clearer with graphics (which were not in that first proposal), but it still makes for a very long and still confusing voting system.

We would also drop the "no funding" provisions of the current document. All members would need to specify their funding.

kkraus14 commented 1 year ago

I'm happy to be moved back to emeritus.

It seems like all 4 options presented include dropping the "no funding" provisions of the current document which is where the confusion lied for me and others where there isn't clear guidance as to who is "funded" vs "not funded". Making everyone be "funded" feels like a good compromise.

tnabtaf commented 1 year ago

@kkraus14 Thanks for your flexibility. Moving you back to emeritus will address the immediate concern (and I am all for that).

And I am not opposed to just updating governance to state that everyone is funded! But, before I propose text to implement that, I think this is an opportunity to address @ericdill's (and other's) concerns as well.

So, I'll wait a week or two to propose any changes, and in the meantime, I will encourage discussion to see where the consensus ends up.