Clarity Questions in Governance Doc; and a nomenclature suggestion.

[tnabtaf]

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.

[beckermr]

I like all of these suggestions. I also think we should get rid of specification projects in favor of CEPS.

For the "maintenance team," I think "developer team" is a nice alternative.

I like "steering committee" for the core team.

Personally, I am happy to have things reworded as long as they remain clear. The intent of the document as it is now is that voting rights are only extended to people on the core team. The only exception IIRC is for maintenance teams and petitions for commit rights.

[jakirkham]

Generally agree. Also like "steering committee".

I think the gist of the grant wording is to ensure folks are on board with the scope and intent of the work before requesting/using funds and beginning work. Agree that is a bit round about in the current wording (sometimes it is difficult to capture these things).

Maybe voting procedures can be specified in one place and then referenced to in others? This would hopefully cutdown on accidental departures from an intended procedure.

[tnabtaf]

Thanks for the feedback Matt.

I like all of these suggestions. I also think we should get rid of specification projects in favor of CEPS.

Ah, I like that too. I will include that in a coming policy update proposal, which might be a CEP itself.

For the "maintenance team," I think "developer team" is a nice alternative.

I like "developer team" as well, except that I want to encourage/recognize other types of contributions too, like triaging issues. Still, I think it is more compelling than "maintenance".

I like "steering committee" for the core team.

Personally, I am happy to have things reworded as long as they remain clear. The intent of the document as it is now is that voting rights are only extended to people on the core team. The only exception IIRC is for maintenance teams and petitions for commit rights.

Thanks.

[tnabtaf]

Hi John,

Thanks for the quick input.

Generally agree. Also like "steering committee".

I think the gist of the grant wording is to ensure folks are on board with the scope and intent of the work before requesting/using funds and beginning work. Agree that is a bit round about in the current wording (sometimes it is difficult to capture these things).

I'll wait to see if others add feedback, and then see what I can do.

Maybe voting procedures can be specified in one place and then referenced to in others? This would hopefully cutdown on accidental departures from an intended procedure.

Ah! I might be able to get away with moving things around and still calling it a "clarification." If I'm not able to justify that in my brain, then we can do this in a later CEP that's all about voting.

[beckermr]

The grant wording comes from a catch-22. If a member gets a grant and the organization receives the $$$, then in principle a vote is needed to spend the $$$. As John says, by voting before the grant is submitted, we can ensure everyone is on board. Otoh one could adopt a policy that grant funds are not subject to votes for spending. We hit this edge case before and so that's why it appears here.

I think a governance update should clean this up for sure!

[beckermr]

Policy updates fall under a different voting provision (higher quorum iirc) than ceps. We can adjust that but those are our current rules.

[tnabtaf]

The grant wording comes from a catch-22. If a member gets a grant and the organization receives the $$$, then in principle a vote is needed to spend the $$$. As John says, by voting before the grant is submitted, we can ensure everyone is on board. Otoh one could adopt a policy that grant funds are not subject to votes for spending. We hit this edge case before and so that's why it appears here.

Ah! (I say that a lot.) My assumption was that these were grants from the conda organization that people were applying to. Thanks for the clarification.

OK, my first interpretation of Matt's post was incorrect. :-(

[jakirkham]

Policy updates fall under a different voting provision (higher quorum iirc) than ceps. We can adjust that but those are our current rules.

Was trying to suggest we have a list of vote types with how they work:

• Simple majority
• 2/3 majority
• etc.

Then for relevant actions we just say this kind of vote needs to be held.

Looking at the list we have a bunch of things specifying different percentages (many repeated). This leaves room for them to diverge in unexpected ways. Having a list of vote types and then procedures that require particular kinds refactors out the voting portion in a more maintainable less error prone formulation.

In any event this may be too complicated for clean up, but it may be worth doing anyways.

There are also some vote thresholds that are so similar that we may opt to consolidate (a number of things use something in the 60-70%; maybe just pick one (2/3s?) and use for all?).

Anyways don't want to derail this thread on the voting point. Just wanted to clarify the suggestion a bit 🙂

[jezdez]

Thanks for the feedback Matt.

I like all of these suggestions. I also think we should get rid of specification projects in favor of CEPS.

Ah, I like that too. I will include that in a coming policy update proposal, which might be a CEP itself.

For the "maintenance team," I think "developer team" is a nice alternative.

I like "developer team" as well, except that I want to encourage/recognize other types of contributions too, like triaging issues. Still, I think it is more compelling than "maintenance".

I fairly strongly believe that the "maintenance" and "developer" terms are excluding people in the conda community at the moment, who may have an interest and ability to contribute but don't see themselves as neither maintainer (it's a learned skill to maintain something long-term) nor software developer (which arguably is a very wide term and doesn't fit with the reality of so many working in the field but never having gotten formal training).

For example roles that other Open Source projects have profited from in my experience: product managers, technical writers and editors, user interface designers, user experience designer, graphic designers, user researchers, community managers, interns and students, QA engineers, test engineers, infrastructure and devops engineers, security engineers, hackers, meetup organizers, conference organizers, software architects etc.

I'd suggest to call the "maintenance teams" what they are: project teams.

Or - if we want to follow precedence set in other projects like Python - we could call them "working group" since that'd allow to setup them up without specifically tying them to one code project alone, but a topic as well like "documentation".

I like "steering committee" for the core team.
Personally, I am happy to have things reworded as long as they remain clear. The intent of the document as it is now is that voting rights are only extended to people on the core team. The only exception IIRC is for maintenance teams and petitions for commit rights.

Thanks.

+1 on Steering Committee or Steering Council (like Python).

[jezdez]

Policy updates fall under a different voting provision (higher quorum iirc) than ceps. We can adjust that but those are our current rules.

Was trying to suggest we have a list of vote types with how they work:

• Simple majority
• 2/3 majority
• etc.

Then for relevant actions we just say this kind of vote needs to be held.

Looking at the list we have a bunch of things specifying different percentages (many repeated). This leaves room for them to diverge in unexpected ways. Having a list of vote types and then procedures that require particular kinds refactors out the voting portion in a more maintainable less error prone formulation.

In any event this may be too complicated for clean up, but it may be worth doing anyways.

There are also some vote thresholds that are so similar that we may opt to consolidate (a number of things use something in the 60-70%; maybe just pick one (2/3s?) and use for all?).

Anyways don't want to derail this thread on the voting point. Just wanted to clarify the suggestion a bit 🙂

Let's not derail but just divert this important topic to a separate ticket and dive into the voting thresholds a bit. IMO we should work through the complexity of the current voting scheme and see if we can simplify some of them to make it a bit more practical for a lived governance.

[jezdez]

I like all of these suggestions. I also think we should get rid of specification projects in favor of CEPS.

Yeah, I agree, this is related to #35 where you correctly identified the need to align the governance document with the reality of the CEPs process I restarted last year among other things. Since the CEP process is now stalled for various reasons, it makes sense to include it in @tnabtaf's suggestions.

[beckermr]

Great point @jezdez on the team name. Let's go with project teams!

[tnabtaf]

Since the CEP process is now stalled for various reasons, it makes sense to include it in @tnabtaf's suggestions.

I'm all for merging specifications into CEPs, but not in this issue. I want this issue and the resulting PR to only be about clarity issues. I am (now) planning to followup on specifications/CEPs in a subsequent discussion.

[beckermr]

+1 to multiple issues!

We should have a single vote on all of the governance changes at once to make life easier for folks.

[tnabtaf]

I'm torn on that one. I like having a clean, easy to follow history to go back to a year from now. But, governance votes are notoriously difficult to finish. My goal for focusing on clarity on this particular issue is that any changes tied to it would not trigger governance voting (and thus avoid at least one vote).

[tnabtaf]

I've been thinking about the grants paragraph that confused me:

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.

@beckermr response was particularly helpful to me (although I initially misunderstood it):

The grant wording comes from a catch-22. If a member gets a grant and the organization receives the $$$, then in principle a vote is needed to spend the $$$. As John says, by voting before the grant is submitted, we can ensure everyone is on board. Otoh one could adopt a policy that grant funds are not subject to votes for spending. We hit this edge case before and so that's why it appears here.

I think we could clarify the existing paragraph by adding some text at the front (Updated text bolded.):

The conda Organization, through our fiscal sponsorship with NumFOCUS, can be the coordinating organization for grants from external funders. In order for conda to do this, grant proposals must be supplied the Steering Council prior to submitting it to the potential funders. A vote will be called under the Spending of funds policy. If the vote does not pass, then 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.

But, we can't say that yet, because conda is not yet fiscally sponsored by NumFOCUS.

So, I suggest that for now we leave the paragraph just as it is until we actually are fiscally sponsored by NumFOCUS (which I hope is later this year.)

Thoughts?

[tnabtaf]

For team nomenclature I am going with:

• Maintenance Team → Project Team
• Core Team → Steering Council

Please yell if you disagree.

[tnabtaf]

PR #42 was merged yesterday. It resolved these items that were raised in this issue:

• Voting Ties
• Voting and Maintenance Teams
• Nomenclature

It does not resolve this item:

• Grant Proposals

That item is clarified in the discussion in this issue, but the resolution requires conda to become fiscally sponsored, and that won't happen for several more months. Thus, PR #42 does not touch this section of the governance document.