feat: Update governance process #135

vikas-agarwal76 · 2025-07-29T10:53:33Z

Closes Issues: #127, #136, #137
Closes PRs: #133 , #134

jpower432 · 2025-07-29T14:39:08Z

@vikas-agarwal76 @jflowers I've opened issue #136 to discuss the process for future alterations to our governance documents. To ensure transparency and minimize the impact of sweeping changes, I propose we adopt a practice of documenting individual decisions and significant changes within dedicated issues or PR descriptions. This will allow for a clearer understanding of their rationale and potential ramifications. What do you think?

jflowers · 2025-07-29T14:41:09Z

@vikas-agarwal76 @jflowers I've opened issue #136 to discuss the process for future alterations to our governance documents. To ensure transparency and minimize the impact of sweeping changes, I propose we adopt a practice of documenting individual decisions and significant changes within dedicated issues or PR descriptions. This will allow for a clearer understanding of their rationale and potential ramifications. What do you think?

Yes, I agree. Thanks for the suggestion.

jpower432 · 2025-07-30T22:25:30Z

@vikas-agarwal76 Is this ready for review or feedback?

jflowers · 2025-07-31T15:06:03Z

Hello! Thank you for your work on evolving the GOVERNANCE.md. This is a crucial aspect of the project's long-term health, and I appreciate you taking the lead on this.

I've reviewed the proposed changes, and I'd like to offer some feedback based on best practices from the CNCF and its graduated projects. My main concern is that some of the proposed changes could inadvertently create a more closed-off governance system than is typical for successful open-source communities. I'd like to suggest a few amendments to ensure we build a model that is as open, transparent, and meritocratic as possible, in line with CNCF principles.

My primary concern is with the new line introduced at line 23: "In case of any conflict between the decision of the oversight committee and that of individual projects, the decision of the oversight committee will be binding."

While the Oversight Committee should indeed be a point of escalation for unresolved disputes, this "binding" clause could unintentionally undermine the autonomy of our individual projects. A core CNCF principle is that technical decisions should reside with the project maintainers who are closest to the code. A top-down, binding override from the committee should be a measure of last resort for resolving deadlocks, not the default expectation for any conflict.

To better align with CNCF principles, I suggest we rephrase this to emphasize collaboration and the committee's role as a facilitator, rather than a top-down authority. For example:

"While technical decisions for a project reside with its maintainers, the Oversight Committee may be asked to help mediate cross-project disputes or resolve decisions that a project's maintainers are unable to reach a consensus on."

This preserves the committee's authority to resolve blocking issues without undermining the day-to-day autonomy of the projects.

This concern about top-down control is also reflected in a few other changes in this PR. To ensure we are building a truly community-driven project, I would also recommend we discuss the following:

Voter Eligibility for Oversight Committee Elections (Line 102): The PR currently restricts voting for the Oversight Committee to only current committee members. This is a significant deviation from the CNCF model, where projects typically allow a broader group of active community members (like all active Members, Reviewers, and Maintainers) to vote for their leadership. This ensures the leadership is accountable to the community they serve. I strongly recommend we allow all active community members to be eligible to vote.
Candidate Eligibility for Oversight Committee (Line 114): The new requirement that a candidate must be a current/emeritus committee member or a maintainer of a core project creates a very small pool of eligible candidates. CNCF projects encourage leadership paths for any trusted and active contributor who meets the qualifications, regardless of their formal title. We should broaden the eligibility to any community member who meets the documented requirements, without the prerequisite of being a maintainer, to foster a healthier and more sustainable leadership pipeline.
Company Representation Limit (Removed from ~line 124): The removal of the company representation limit is a major concern for vendor neutrality, a core CNCF principle. Nearly all successful projects enforce a limit on how many leadership seats can be held by employees of a single company to prevent any one company from having undue influence. We should re-introduce this limit; a common standard is that no more than 1/3 or 50% of the seats are held by employees of the same company.
Tie-Breaking in Elections (Line 110): The PR specifies a simple re-vote between tied candidates, which can be inefficient. The CNCF and many of its projects have adopted more robust, single-round voting systems like the Schulze method to handle ties gracefully. I recommend we adopt the Schulze method to align with modern open-source best practices.
Abstaining from a Vote (Line 148): The PR states that "Abstaining from voting means a negative vote." This is an unusual and potentially punitive rule. In most governance models, abstention is a neutral action, and votes are decided by the majority of those who cast a vote ("yes" or "no"). Equating abstention with a "no" vote can force members to vote on topics they are not familiar with. I recommend removing this clause.

I believe that incorporating this feedback will help us create a governance model that is more transparent, resilient, and aligned with the best practices of successful open-source projects.

I am happy to discuss these points further. Thank you again for your work on this important document.

degenaro · 2025-09-05T12:53:02Z

MEMBERSHIP.md

+* You have been sponsored by **two Maintainers**. **Note the following requirements for sponsors**:
+  * Sponsors must have close interactions with the prospective Reviewer - e.g. code/design/proposal review, coordinating on issues, etc.
+  * Sponsors must be from multiple member companies to demonstrate integration across community.
+  * One of the sponsor has to be from the same sub-project.


degenaro · 2025-09-05T12:53:45Z

MEMBERSHIP.md

+* You have been sponsored by **two Maintainers**. **Note the following requirements for sponsors**:
+  * Sponsors must have close interactions with the prospective Maintainer - e.g. code/design/proposal review, coordinating on issues, etc.
+  * Sponsors must be from multiple member companies to demonstrate integration across community.
+  * One of the sponsor has to be from the same sub-project


degenaro · 2025-09-29T16:29:51Z

Abstaining from a Vote (Line 148): The PR states that "Abstaining from voting means a negative vote." This is an unusual and potentially punitive rule. In most governance models, abstention is a neutral action, and votes are decided by the majority of those who cast a vote ("yes" or "no"). Equating abstention with a "no" vote can force members to vote on topics they are not familiar with. I recommend removing this clause.

@jflowers For a called vote to pass, either 51% (majority vote) or 67% (super majority vote) in favor is needed.

jpower432 · 2025-10-07T16:27:25Z

GOVERNANCE.md

+Significant adopters are those projects and/or organizations that have significant usage of OSCAL Compass **core** projects and are using it for at least six months or more. They need to acitvely contribute/engage with the projects through GitHub events like creating issues, creating PRs, reviewing PRs, commenting on issues, etc. and/or other activities such as publishing joint blogs/papers, giving joint talks, demos, etc. and should also be a member of the OSCAL Compass organization.

-The Oversight Committee functions as the organization maintainers.
+An adoptor can be designated as a significant adopter with a simple majority of the oversight committee. Their name would be added to the [significant adopters list](./ADOPTERS.md).


@vikas-agarwal76 As discussed in the community meeting, I think it would be make sense to keep the ADOPTERS.md as a low friction option for collecting information about projects or organizations using OSCAL Compass for project visibility and growth.

I think i'm confused with adopters vs advocates. I could be using oscal compass across every project in a fortune 100 yet not be proactive in the community.

This is almost like an 'ecosystem' rather than adopters based on the definition of significant adopters.

I think places to capture ecosystem information makes sense. OPA has something like this where it captures things like tool integrations. The original intent of the ADOPTERS.md was just to gather information about organizations who are willing to publicly share their use and experience with OSCAL Compass.

butler54

I've left a large number of comments here. The overall goal is to remove wiggle room for debate and or objections that a person is being excluded.

butler54 · 2025-10-21T07:36:01Z

GOVERNANCE.md

+Changing the status of a project from non-core to core, or core to non-core will require a 2/3 majority of the oversight committee.

-#### Stepping Down and the Emeritus Process
+### OSCAL Compass 'lab/workgroup' projects and 'significant adopters'


I think this section can be separated.

e.g. OSCAL Compass 'lab' and 'core' projects; second section 'significant adopters'

butler54 · 2025-10-21T07:37:31Z

GOVERNANCE.md

+### OSCAL Compass 'lab/workgroup' projects and 'significant adopters'

-It is inevitable that people's focuses will change over time. Contributors can retire and move to emeritus Maintainers. If a contributor needs to step down from their current role, they should inform the appropriate project Maintainers. No vote is required for a contributor to remove themselves, and any project Maintainer can approve the PR. Maintainers who step down become emeritus Maintainers.
+New projects that are not core to the functionality of OSCAL Compass but are closely related may be incubated as a lab/workgroup project in a separate [oscal-compass-lab](https://github.com/oscal-compass-lab) Github org managed by OSCAL Compass maintainers. Existing projects closely related to OSCAL Compass, but in a separate github org can also be moved to oscal-compass-lab Github org. All the lab projects will follow a similar project maintenance structure as projects in OSCAL Compass.


All projects that are demostrations or templates should be in the lab?

butler54 · 2025-10-21T07:38:58Z

GOVERNANCE.md

+
+The election process is as follows:
+
+1. **Call for Nominations**: One month before the election, a call for nominations will be sent out to the OSCAL Compass community.


I think how should be added to point one.

butler54 · 2025-10-21T07:39:15Z

GOVERNANCE.md

+The election process is as follows:
+
+1. **Call for Nominations**: One month before the election, a call for nominations will be sent out to the OSCAL Compass community.
+2. **Nomination Period**: Community members will have one month to nominate candidates for the Oversight Committee. Self-nominations are permitted.


butler54 · 2025-10-21T07:43:24Z

GOVERNANCE.md

+1. **Call for Nominations**: One month before the election, a call for nominations will be sent out to the OSCAL Compass community.
+2. **Nomination Period**: Community members will have one month to nominate candidates for the Oversight Committee. Self-nominations are permitted.
+3. **Candidate Statements**: Each candidate will be asked to provide a statement of interest and qualifications.
+4. **Vetting**: There is usually a process for the existing committee or another body to review the nominations and confirm that the candidates meet the eligibility criteria.


This leaves room for manoeuvre. I would argue 4 needs a sub point such as:

Negative determination of eligibility needs to be affirmed by a majority vote of the current oversight committee.

e.g. exclusion needs to be explicitly documented so that no one is excluded for invalid reasons.

butler54 · 2025-10-21T07:55:15Z

GOVERNANCE.md

+
+Oversight committee members are elected to serve a two year term. Members can serve two consecutive terms (4 years). Bootstrap and terms that result in equal to or less than one year served are exempt.
+
+Election cycles are scheduled such that roughly half of the seats come up for re-election each year for purposes of continuity. The exact number of seats alternates between 3 and 4.


Further to the point above, I think you should specify that the election cycle should be annual. it's not explicitly spelled out.

butler54 · 2025-10-21T07:57:07Z

GOVERNANCE.md


 Some examples include:

 * Carrying out [Code of Conduct](https://oscal-compass.github.io/compliance-trestle/mkdocs_code_of_conduct/) decisions requiring severe censure (supermajority of the Oversight Committee)


Supermajority is not defined. I believe you are saying 2/3rds but it should be explicit

butler54 · 2025-10-21T08:01:38Z

MEMBERSHIP.md

 To become a project Reviewer, you must meet the following requirements:

+* Member for at least **3 months**.
+* Primary reviewer or author for at least **5 substantial PRs** to the codebase.


I'm not sure we want to put numbers in here yet. It might make sense to decrease each of the numbers to one and add a note at the bottom of this section that as OSCAL compass matures we expect the PR review / author count to increase.

butler54 · 2025-10-21T08:02:50Z

MEMBERSHIP.md

+  * Sponsors must have close interactions with the prospective Reviewer - e.g. code/design/proposal review, coordinating on issues, etc.
+  * Sponsors must be from multiple member companies to demonstrate integration across community.
+  * One of the sponsors has to be from the same sub-project.
+  * With no objections from other maintainers of the same sub-project


No objections is potentially exclusionary. might make sense if there are objections those objections must be voted on.

butler54 · 2025-10-21T08:03:41Z

MEMBERSHIP.md


+## OSCAL Compass Ecosystem
+
+OSCAL Compass also has a 'lab' GitHub organization for incubating new projects and hosting closely related projects from the community. If you are an OSCAL Compass org member, you are implicitly eligible for membership in the related 'lab' Github org, and can request membership when it becomes relevant, by creating a PR directly or opening an issue against the 'lab' Github org community repo.


Insert lab org links here including for PR to community repo

butler54 · 2025-10-21T08:15:41Z

@vikas-agarwal76 looking at this document along with the PR's from @jpower432 and @jflowers it looks like this is consolidating a number of request and issues into once cohesive document.

Before voting occurs I believe we should add the closes: #issueorprnumber explicitly to the PR body to ensure the reviewer understand all the documents / issues this is intended to complete / supersede

Clarified terms for oversight committee service and election cycles.

vikas-agarwal76 · 2025-11-12T09:37:24Z

@butler54 As discussed, I have incorporated your suggestions. Please see.
@jpower432 Incorporated your suggestion on keeping adopters separate from significant adopters (now termed Advocate). Also updated membership doc to allow maintainers to self nominate.

vikas-agarwal76 · 2025-11-20T05:17:34Z

/vote-super

git-vote · 2025-11-20T05:17:37Z

Vote created

@vikas-agarwal76 has called for a vote on feat: Update governance process (#135).

The members of the following teams have binding votes:

Team
@oscal-compass/oversight-committee-members

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 28days. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

git-vote · 2025-11-20T12:25:10Z

Vote closed

The vote passed! 🎉

66.67% of the users with binding vote were in favor and 0.00% were against (passing threshold: 66%).

Summary

In favor	Against	Abstain	Not voted
4	0	0	2

Binding votes (4)

User	Vote	Timestamp
@butler54	In favor	2025-11-20 8:06:34.0 +00:00:00
@degenaro	In favor	2025-11-20 10:26:34.0 +00:00:00
@vikas-agarwal76	In favor	2025-11-20 5:18:00.0 +00:00:00
@yuji-watanabe-jp	In favor	2025-11-20 5:33:38.0 +00:00:00

butler54

LGTM - approved based on gitvote

degenaro

LGTM

vikas-agarwal76 added 5 commits July 29, 2025 16:22

feat: Update governance process

d9c8fb3

fix lint errors

0ecfe1c

Update GOVERNANCE.md

e26a10e

Update GOVERNANCE.md

ba447c8

Update GOVERNANCE.md

5f4b460

vikas-agarwal76 added 11 commits September 3, 2025 17:45

fix: Update GOVERNANCE.md

dc50578

fix: Update GOVERNANCE.md

39bbcf6

fix: Update GOVERNANCE.md

7613c71

fix: Update MEMBERSHIP.md

753d8ce

fix: Update MEMBERSHIP.md

0d16dfa

fix: Update MEMBERSHIP.md

7ffd11c

fix: Update MEMBERSHIP.md

254d77e

fix: Update GOVERNANCE.md

828150b

fix: Update GOVERNANCE.md

0ef552f

fix: Update GOVERNANCE.md

e282330

fix: Update MEMBERSHIP.md

2a4337e

degenaro reviewed Sep 5, 2025

View reviewed changes

vikas-agarwal76 added 8 commits September 9, 2025 10:22

fix: Update GOVERNANCE.md

13f6e48

fix: Update MEMBERSHIP.md

5441b04

fix: Update GOVERNANCE.md

0656e1d

fix: Update GOVERNANCE.md

9dc0b1e

fix: Update GOVERNANCE.md

89f7eb5

fix: Update GOVERNANCE.md

434e32e

fix: Update GOVERNANCE.md

25762d5

fix: Update MEMBERSHIP.md

34aec96

jpower432 reviewed Oct 7, 2025

View reviewed changes

butler54 reviewed Oct 21, 2025

View reviewed changes

degenaro added the governance Project governance label Oct 21, 2025

vikas-agarwal76 added 6 commits November 12, 2025 13:10

fix: updated governance based on feedback

b51099c

Clarified terms for oversight committee service and election cycles.

Merge branch 'main' into vikas-agarwal76-patch-2

fe4e3a9

fix: clarify PR requirements for Reviewer and Maintainer

febbfeb

feat: add advocates.md file

ce0ef15

feat: added election-process.md file

5d813b3

fix: update maintainer to self nominate

12561ae

git-vote bot added gitvote gitvote/open labels Nov 20, 2025

git-vote bot added gitvote/closed gitvote/passed and removed gitvote/open labels Nov 20, 2025

vikas-agarwal76 requested review from butler54 and degenaro November 24, 2025 04:11

butler54 approved these changes Nov 24, 2025

View reviewed changes

degenaro approved these changes Nov 24, 2025

View reviewed changes

vikas-agarwal76 merged commit bfef145 into main Nov 24, 2025
4 checks passed


		The election process is as follows:

		1. Call for Nominations: One month before the election, a call for nominations will be sent out to the OSCAL Compass community.


		Oversight committee members are elected to serve a two year term. Members can serve two consecutive terms (4 years). Bootstrap and terms that result in equal to or less than one year served are exempt.

		Election cycles are scheduled such that roughly half of the seats come up for re-election each year for purposes of continuity. The exact number of seats alternates between 3 and 4.


		Some examples include:

		* Carrying out [Code of Conduct](https://oscal-compass.github.io/compliance-trestle/mkdocs_code_of_conduct/) decisions requiring severe censure (supermajority of the Oversight Committee)


		## OSCAL Compass Ecosystem

		OSCAL Compass also has a 'lab' GitHub organization for incubating new projects and hosting closely related projects from the community. If you are an OSCAL Compass org member, you are implicitly eligible for membership in the related 'lab' Github org, and can request membership when it becomes relevant, by creating a PR directly or opening an issue against the 'lab' Github org community repo.

feat: Update governance process #135

feat: Update governance process #135

Conversation

vikas-agarwal76 commented Jul 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jpower432 commented Jul 29, 2025

Uh oh!

jflowers commented Jul 29, 2025

Uh oh!

jpower432 commented Jul 30, 2025

Uh oh!

jflowers commented Jul 31, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

degenaro commented Sep 29, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

butler54 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

butler54 commented Oct 21, 2025

Uh oh!

vikas-agarwal76 commented Nov 12, 2025

Uh oh!

vikas-agarwal76 commented Nov 20, 2025

Uh oh!

git-vote bot commented Nov 20, 2025

Vote created

How to vote

Uh oh!

git-vote bot commented Nov 20, 2025

Vote closed

Summary

Binding votes (4)

Uh oh!

butler54 left a comment

Choose a reason for hiding this comment

Uh oh!

degenaro left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

vikas-agarwal76 commented Jul 29, 2025 •

edited

Loading