[Proposal] Acceptance Criteria for Contributions

[eddie-knight]

Hi, it occurs to me that community contributions to this repo may be experiencing a slowdown due to a lack of clear acceptance criteria for contributions.

I'm happy to draw on my experience in Linux Foundation projects to help draft such a document, if it would be useful to the OSCAL community.

[iMichaela]

@eddie-knight Nice "seeing" you here! Thank you for your proposal. NIST team welcomes it. We tried in the past, through calls to action sent via e-mail or by labeling issues and by announcing them during recurrent meetings or annual conference. We asked that all new proposals be endorsed by other members in the community representing distinct institutions, to demonstrate in this way that the proposed features are accepted or needed by a larger majority of adopters. Also, having community members review PRs in addition to the NIST team, it boosts up the confidence that the implementation is correct. Also, having more than NIST team members responding to opened issues is still challenging.

Looking forward to learning from you.

[eddie-knight]

Here's a suggestion for an addition to CONTRIBUTING.md:

## Making Functional Changes to the Standard
Contributing functional changes to the standard is a collaborative process aimed at maintaining its quality and usability for the broader community. Contributors should follow these guidelines to ensure all changes are thoroughly vetted, well-documented, and move quickly to release:

1. Maintain Industry Neutrality
  - A guiding principle for functional changes is that they should be equally useful for all users and avoid introducing industry-specific elements. Contributions that benefit only a particular sector or use case will not be accepted.
2. Establish Community Consensus
  - Begin by opening a GitHub Issue that clearly outlines the problem you aim to solve and your proposed solution.
  - Where applicable, all proposals should be exemplified with XML. This will accelerate the review process and reduce overhead on the maintainers as your proposal is considered.
  - Engage the community in discussions on the issue to gather feedback and refine the proposal.
  - If necessary, create a corresponding Pull Request (PR) to demonstrate the proposed change in detail. This PR should be kept in [draft mode](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/changing-the-stage-of-a-pull-request) until sufficient consensus is gained on the Issue.
  - All changes, except for bug fixes or documentation updates, must be explicitly linked to an open Issue. This ensures traceability and provides context for the contribution.
  - If a change is not backwards compatible, a scheduling discussion should be had at this time to ensure a low frequency of releases with breaking changes.
3. Propose Changes with Supporting Materials
  - Create a pull request with the functional changes that have achieved a community consensus. The Pull Request process is detailed elsewhere in this contribution guide.
  - Every functional change proposal must include:
    - **Documentation Updates:** Clearly explain how the change affects the standard and its usage.
    - **Tests:** Provide tests that verify the functionality and correctness of the change.
    - **CLI Updates:** If the change impacts any command-line interfaces, ensure they are updated and tested accordingly.
4. Request Community Review
  - Before merging a functional change, submit a Request for Comments (RFC) to the community mailing list.
  - Allow a minimum of 7 days for community members to review, discuss, and provide feedback on the proposed change.

@iMichaela Please note that this proposed addition mentions “sufficient consensus.” It would be good to have a definition of that requirement here as well, if you have an idea of what that consensus should look like.

[aj-stein-gsa]

Do you want assistance in coordinating changes to the CONTRIBUTING.md, the issue templates, and other related docs as Michaela recommended in #2074 (comment)? I am volunteering to help if that would be beneficial, @eddie-knight.

[iMichaela]

@eddie-knight and @aj-stein-gsa -- If there is interest from the community too (and I would like to see reviews of the proposed criteria beyond thumbs ups), I would like to work on the updates next week when I'll be back in the office for few days before holidays PTO. Thank you all!

[eddie-knight]

Brilliant, thanks @aj-stein-gsa! I'll reach out directly to set up a time for us to collab on this.

[iMichaela]

Thank you, @eddie-knight . This is great.
We also have templates for PRs which guide through some of the similar requirements you are listing, and a Wiki page with guidance: https://github.com/usnistgov/OSCAL/wiki/Issue-Review provided in our Wiki. I would like to compare and combine, with