Policies

NumFOCUS Affiliation

OpenFHE is a Sponsored Project of NumFOCUS, a 501(c)(3) nonprofit charity in the United States. NumFOCUS provides OpenFHE with fiscal, and administrative support to help ensure the health and sustainability of the project. Visit NumFocus.

Donations to OpenFHE 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.

Teams & Roles

Here are defined the primary teams participating in OpenFHE activities. Note, individuals are able to participate in multiple teams. The Steering team shall approve all changes in membership to all OpenFHE 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 OpenFHE organization. Members of the Steering team have full rights over all OpenFHE 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.
  • Crypto: The Crypto team is a group of members of the Homomorphic Encryption Community who have been invited to participate by the Steering Committee. The team should meet as needed but at least once every three months. If there is a situation requiring an immediate response, such as a newly published attack, the Team may call an “extraordinary” meeting. The Crypto Team recommends actions and responses. All recommendations must be agreed to unanimously by members of the Crypto Team. Recommendations are then passed on to the Steering Team for an immediate vote for adoption. Areas of responsibility of the Crypto Team are outlined as follows:
    • Decide whether a particular scheme/capability should be added or removed from an upcoming OpenFHE release.
    • Identify/recommend various hardening techniques, such as PRNG, Gaussian sampling, constant-time samplers, etc.
    • Discuss/recommend the choice and inclusion of new lattice parameter settings, e.g., non-power-of-two cyclotomics.
    • Develop/recommend any patches/fixes related to newly discovered vulnerabilities or attacks, and draft public announcements regarding those attacks and OpenFHE’S corresponding response. Note, all resulting draft announcements must then be approved by the Steering Team, which is then responsible for publishing the announcement accordingly.
  • Advisory Board: The Advisory Board is a group of technologists and thought leaders expert in the HE field or associated application areas who have been invited to participate by the Steering Committee. The Board should meet with the Steering Team in an advisory session no more frequently than once every six months, with a minimum frequency of once every year. The role of the advisory board is to provide input and guidance to the Steering Team regarding emerging technologies, applications, and other agenda topics to be determined by the Steering Team for each meeting.
  • Pre-release: The Pre-release team administers the current pre-release branch in the openfhe-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 main branch of openfhe-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 OpenFHE 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 OpenFHE 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 OpenFHE 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 openfhe-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 OpenFHE 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 OpenFHE 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 OpenFHE 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.

Sub-Teams

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 OpenFHE at all times.

Voting

This section presents descriptions and criteria for voting items in the OpenFHE community. The Steering team is the only team with voting rights. Other teams may pass recommendations up to the Steering team for a vote. 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 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 OpenFHE online groups and forums
  • Adding/removing people to private communication channels
  • Adding/removing people with rights to post as OpenFHE 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.