Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged
merged 1 commit into from
Aug 12, 2022

Conversation

ericdill
Copy link
Contributor

@ericdill ericdill commented Aug 12, 2022

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

@beckermr beckermr merged commit eaf59a5 into main Aug 12, 2022
@beckermr beckermr deleted the move-kkraus branch August 12, 2022 16:10
@jezdez
Copy link
Member

jezdez commented Aug 12, 2022

This change seems to have been in mistake, the vote in question as documented in #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
Copy link
Contributor

tnabtaf commented Aug 24, 2022

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

  • Prevent "capture" of the conda Organization by any one organization.

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:

  • The Technical Council does not have a limit on the number of members with common funding.
  • The council must have members from at least 3 different funding sources.
  • If 2 or more members of the Technical Council believe that members of the largest shared funding block are making decisions based on what's best for their funder, rather than the community, then those two members can request that the Steering Council reclaim the issue. The Steering Council could then retake control of the decision
  • The Steering council would keep the current 2 person limit.
  • We would drop the "no funding" provisions of the current document. All Steering Council members would need to specify their funding.

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:

  • The council must have members in at least 3 different funding blocks on it.
  • if 2 or more members of the Steering Council believe that a funding block with more than 2 members is making decisions based on what's best for their funder, rather than the community, then those two members can invoke the "Two is the magic number" rule. This would limit each shared funding block to at most 2 votes.
  • This would require that 2 members of each funding block be designated in advance.
  • The Steering council would keep the current 2 person limit.
  • We would drop the "no funding" provisions of the current document. All members would need to specify their funding.
  • Our expectation is that this rule would rarely be invoked.

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
Copy link
Contributor

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
Copy link
Contributor

tnabtaf commented Aug 25, 2022

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants