Skip to content

Latest commit

 

History

History
15 lines (8 loc) · 1.7 KB

process-for-new-or-revised-policies.md

File metadata and controls

15 lines (8 loc) · 1.7 KB
Raw

Process for proposing and adopting new and revised community policies

Proposing new/revised policy:

  • Open a GitHub Pull Request on the xsdk-community-policies repository with the proposed updates and a discussion of the recommended changes (this can be comments in the GitHub pull request). This is important to make sure policies are not too ambiguous and to ensure that high level ideas are not agreed to, while contentious details are left undefined.

  • Send a note to [email protected] with a link to the GitHub Pull Request and a very brief summary of the proposed addition/change at least 3 days before an xSDK project meeting. Comments can be added to the Pull Request by anyone to get the conversation started. If someone is unable to attend the meeting and their concerns cannot be resolved via GitHub Pull Request comment discussion, they can cast a “no” vote in the body of the Pull Request to prevent consensus at the meeting, as discussed under the “Adopting new/revised policy” section.

  • Add a discussion of the GitHub Pull Request to the xSDK meeting agenda. Anyone who cannot attend the meeting should comment in the body of the GitHub Pull Request.

Adopting new/revised policy:

  • The new or revised policy can be adopted at a meeting by consensus of attendees if at least 10 xSDK team members are present.

  • If consensus cannot be reached, then the policy proposal should either be revised, or can be put to a formal vote of member package leads (or their delegate). One vote is allowed per member package. When this approach is used, new/revised policies are adopted with a minimum of 75% yes votes from member package leads.