Policies and procedures governing the PALISADE community
This document outlines the policies and procedures that manage the PALISADE community.
This is a living document and is expected to be updated in order to meet the changing needs as the Palisade organization evolves over time.
*Version 0.1 Prerelease Placeholder 9/20/2019 *Version 0.2 Draft for Steering Committee Approval 10/28/2019 *Version 1.0 Adopted by Steering Committee 1/28/2020
PALISADE is a Sponsored Project of NumFOCUS, a 501(c)(3) nonprofit charity in the United States. NumFOCUS provides PALISADE with fiscal, and administrative support to help ensure the health and sustainability of the project. Visit (http://numfocus.org for more information.
Donations to PALISADE are managed by NumFOCUS. For donors in the United States, your gift is tax-deductible to the extent provided by law. As with any donation, you should consult with your tax adviser about your particular tax situation.
PALISADE has a formal legal and fiscial relationship with DUALITY Technologies.
Here are defined the primary teams participating in PALISADE activities. Note, individuals are able to participate in multiple teams. The Steering team shall approve all changes in membership to all PALISADE teams, and maintain a Google Doc listing team member's names, contact info, and date of first inclusion into the team.
-
Steering: The Steering team is the governing body over the entire PALISADE organization. Members of the Steering team have full rights over all PALISADE repositories. Members of the Steering team are the face of the project, and are responsible for officially interfacing with external communities, organizations, non-profits, and companies. The Steering team may create new teams, as appropriate. Each member of the Steering team is entitled to one vote on all elected matters.
-
Pre-release: The Pre-release team administers the current pre-release branch in the palisade-development repository and is responsible for the review and publication of new pre-releases, as well as updates, patches and bug fixes to these pre-releases as they are evaluated for submission to stable-release status. The Pre-release team determines which features in the master branch of palisade-development are sufficiently mature to be chosen for pre-release. They also are responsible for quality control checking of associated documentation related to the pre-release. The team will follow the guidelines (below) for release numbering. Pre-release of Major releases (i.e. incrementing the initial release number) have significant impact and must be approved by the Steering team.
-
Stable-release: The Stable-release team administers the PALISADE stable release repository and is responsible for the review and publication of new stable releases, as well as the physical migration of the candidate pre-release and associated documentation to the stable release repostiory. It also is responsible for updating or patching the stable releases as applicable. The stable-release team will determine at what point in time a current pre-release is stable enough to be moved to the release repository according the the following suggested guidelines:
** The candidate pre-release has been tested independently by members of the community and no severe issues have been reported. Also no severe issues have been reported by the PALISADE Maintainers team.
** Sufficient time has passed for such independent review to occur. The duration of this review period is up to the judgement of the stable-release team and should be based on the number of new features and/or scope of patches applied since the last pre-release update.
** These guidlines are meant to be flexible to the needs of the community while maintaining overall software quality of the PALISADE release. As such, interested users may request an expedited (i.e. shorter) testing period provided they can assist with the required testing and evaluation. Such requests must be reviewd and approved by both the Stable-release team and the Steering team.
- Maintainers: A Maintainer is an individual responsible for the management of the palisade-development repository. Maintainers have the ability to commit/push source code and can handle merge/pull requests into the main branch of the repository with the following caveats:
** Merge/Pull requests from internal PALISADE Maintatiners require the review of one other member of the Maintainer team (i.e. a Maintainer cannot Merge their own branches).
** Merge/Pull requests from External contributors require an extra level of review and approval from the entire Maintainer team.
-
External contributors: This group encompasses all others who are not on the Steering team, Pre-release, Release or Maintainers teams. This includes first-time contributors, collaborators, and funders. They have no special rights within the PALISADE organization itself. External contributors are strongly encouraged to discuss potential contributions with the Maintainers and/or Steering committee members before proceeding with any major development, in order to ensure their intended work will align with work already in progress, or in planning.
-
Emeritus status: Steering team members that are inactive (commits, GitHub comments/issues/reviews, dev meetings and voting on polls) in the past six months will be asked if they want to become Emeritus. Any member of a PALISADE team can also request to become Emeritus if they wish to do so (e.g. taking a sabbatical or long vacation). Emeritus Steering team members can still vote and resume active status anytime, the only difference is that Emeritus-Steering team members will not count against the total Steering team members when computing the necessary votes a poll needs to pass. The membership Google Doc list should be updated when change in the status of a member occurs.
The Steering team may elect to create new sub-teams for managing the daily business of the organization. While sub-teams may have non-Steering members, every sub-team must have at least one Steering team member at all times. If a sub-team fails to have a Steering team member for more than 2 weeks, that team is considered to be dissolved. A new sub-team would need to be established by the Steering team in order to reinstate the activity.
Sub-teams have a charter that is either dynamic or static.
-
A dynamic charter means that the sub-team is self-organizing, with respect to its own internal policies, procedures, and membership. A sub-team may choose to modify its membership independent of the steering committee. For example, a Google Summer of Code team could be a good candidate for a dynamic charter. Alternatively, language-based maintenance teams also have a dynamic charter.
-
A static charter means that all membership decisions and non-trivial policies changes must be approved by the steering committee. For example, a finance team may require a static charter.
All sub-teams must adhere to the governance, policies, and procedures of PALISADE at all times.
This section presents descriptions and criteria for voting items in the PALISADE community. The Steering team is the only team with voting rights. The members of the Steering team may also call a vote on any topic. The restrictions on calling a vote are as follows:
- There must only be one vote active on a particular item at any time.
- The act of calling for a vote cannot itself violate the code of conduct. For example, Sam repeatedly called for votes immediately after a previous vote failed to achieve Sam's result. Sam is attempting to bully other members of core into agreeing, and is thus violating the code of conduct.
- Voting yes moves the proposal forward; voting no is the only way to express opposition to the proposal; not voting is discouraged, but non-votes do not count as "no".
- There should always be an option to abstain from voting.
Voting items are labeled as either standard or sensitive.
Standard items are ones where public record and discourse is
preferable. Sensitive voting items are ones where the results of the
vote should remain private to the voters after the vote has occurred.
Sensitive votes should take place on the Helios voting system <https://vote.heliosvoting.org/>_ in order retain anonymity.
The default voting period is 1 week (7 days). This may be modified at the time when a vote is called, but may never be less than 24 hrs.
Votes can happen on the following topics, with passing contingent on a 2/3 majority. All Steering team members should vote, but abstentions are permitted. Sample voting topics are as follows (but are not limited to this list):
- Modifications of these governance procedures (including permanently modifying these lists of sample voting topics).
- Adding/removing Steering team members Spending project funds
- Adding/removing people with commit rights to GitLab repositories
- Adding/removing moderators of PALISADE online groups and forums
- Adding/removing people to private communication channels
- Adding/removing people with rights to post as PALISADE on social
- media Establishing sub-committees and roles
Votes can happen on the following topics with passing contingent on a majority. At least 2/3 of the Steering team members should vote, but abstentions are permitted. Sample voting topics are as follows (but are not limited to this list):
- Approving an expedited release testing schedule
- Approving a Major Pre-release
The Steering team will maintain a Google Doc that records all votes (but not discussion). Access to the Google Doc will be limited to members of the Steering team.
Releases shall be numbered sequentially using the following triple numbering:
Major.minor.patch
Major release number must be incremented when the PALISADE user API changes, requiring user code rewrite.
Minor release numbers must be incremented when a new capability is added, or old capability is deprecated, but existing user code would still operate without a rewrite.
Patch release numbers must be incremented when patches/bug fixes are required.
When a Major pre-release is approved, the Major number is incremented from the last release and minor and patch are set to zero.
When a Minor pre-release is approved the Minor number is incremented from the lasts relese and the patch is set to zero.
When a pre-release is patched, the pre-release Major and Minor numbers are maintained, and the patch is incremented.
When a pre-release is approved for stable-release, the pre-release Major and Minor numbers are maintained, and the patch is incremented.
When a stable-release is patched, the pre-release Major and Minor numbers are maintained, and the patch is incremented. The patches applied to the stable-release are to be applied to the master branch of the development release as appropriate.
At no time will there be multiple pre-release versions supported. Only the latest pre-release will be considered active.
Once a pre-release is accepteqd for stable release, that pre-release is considered inactive. Governance.md Displaying Governance.md.