Clarity Questions in Governance Doc; and a nomenclature suggestion. about governance HOT 18 CLOSED

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?

from governance.

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

from governance.

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 🙂

from governance.

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

from governance.

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

from governance.

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.

from governance.

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.

from governance.

For team nomenclature I am going with:

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

Please yell if you disagree.

from governance.

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.

from governance.

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.

from governance.

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.

from governance.

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.

from governance.

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!

from governance.

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

from governance.

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. :-(

from governance.

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.

from governance.

+1 to multiple issues!

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

from governance.

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.

from governance.