Document a processes for altering and voting on Governance documentation

[jpower432]

Issue

The process for adding changes to the GOVERNANCE.md documentation is unclear.

Some specific points of confusion:

• If a vote is cast, can a PR change? What is the process for notification of changes that alter intent?
• If the PR changes fundementally, do we cancel the vote?
• Should we focus on voting on proposed changes being discussed in issues and let specific wording be worked through the code review process?

Completetion Criteria

• Update the GOVERNANCE.md to include a clear process for proposing updates and putting the changes update for a vote including what type of vote is required for specific types of changes.

[jflowers]

@degenaro I bet you want to participate on this 🙂

[degenaro]

@***@***.*** ***@***.***> I don't have any special insight. One suggestion is for a reasonable process is: 1. Submit votable PR 2. Advertise new or changed PR and upcoming vote 3. Allow reasonable time for collaboration, comments, discussion, or changes prior to voting 4. Call for and advertise vote after reasonable time expiration 5. Changes to PR (other than typos) after someone has voted but before vote passes/fails requires cancel of present vote, then go to step 2. This suggested process does not require complete consensus prior to vote, but does eliminate voting ambiguity once the vote is called...at least that is my claim anyway.

…

On Tue, Jul 29, 2025 at 10:43 AM Jay Flowers ***@***.***> wrote: *jflowers* left a comment (oscal-compass/community#136) <#136 (comment)> @degenaro <https://github.com/degenaro> I bet you want to participate on this 🙂 — Reply to this email directly, view it on GitHub <#136 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAD66XOFH4GYVXASC63GGFL3K6CBFAVCNFSM6AAAAACCUEJCKKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMZSHA3TQMJUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[jpower432]

Thanks @degenaro. I agree, this process sounds reasonable. I have a few points where we might want to clarify the process further to ensure smooth execution:

• Defining "Reasonable Time": For the sake of clarity, we might want to define (at least loosely) what a reasonable time is for collaboration so initiatives are not getting stalled. Perhaps a range or maximum number of days?
• Standardizing Advertisement: We also might want to document the notification process. A convention I have been following is to open a PR or issue and mark it with the vote label. To build on this, we could use that label to create a Voting project board and announce through GitHub Discussions in the community repository.

What are your thoughts on these suggestions?

[degenaro]

@jpower432 I think it is fine to suggest guidelines for "reasonable time", "standard advertising", etc. It likely depends on several factors - how large, how controversial, etc. A voting project board will be help to some but not all. With respect to requirements, I think the rule should be that the vote is canceled if a non-trivial change is made to the PR.

[butler54]

@vikas-agarwal76 I think this need to be added to your PR as well.

[vikas-agarwal76]

PR #135 closes this.