SVTA Open Source Governance

This page describes how open-source projects developed as part of SVTA working group activity will be managed and, in the case of open-source projects that are made available to non-SVTA members, governed.

Publication

This governance model will be published as a GOVERNANCE.md file in every SVTA repository and will be the sole document governing all SVTA open-source projects.

Project Types

The SVTA will employ three types of open-source projects:

• Private. These projects will only be accessible by SVTA member companies and the resulting software can only be used by SVTA member companies.
• Hybrid (private with public usage). These projects will only allow SVTA member companies to contribute but will allow non-SVTA members to use the software as-is.
• Public. These projects will be completely accessible by anyone. They will continue to be governed and managed by the SVTA, through designated leadership within a working group, but non-SVTA members can contribute.

Project type will be recommended by the WG and documented in the scoping document. The scoping document will be ratified by the SVTA as part of the normal SVTA ratification process: Phase 1 will allow for SVTA Principal Member comments, Phase 2 for board review, and Phase 3 for final vote by SVTA Principal members. After ratification, if the WG wishes to change the project type, they will need to resubmit the modified scoping document to the board. All SVTA open source projects will be managed by an SVTA working group.

Project Governance Models

All SVTA open-source projects will be managed under the BDFL (Benevolent Dictator For Life) model. That means that all decisions about the project will be made by SVTA member companies.

Project Roles

Once a project has been moved from an incubation or scoping phase and is instantiated in a Github repo, it will have the following roles:

• Maintainer. This is the designated project lead(s) within the working group which owns the project related to the open-source repo.
  • It is important to note that this is not determined through meritocracy. The maintainer is appointed by the working group chairs. Non-SVTA members cannot be maintainers.
• Committer. This role represents an individual from an SVTA member company who can commit code to the repo. Committed code can only be approved by the Maintainer.
• Contributor. This role represents any individual, SVTA or non-SVTA member, who contributes in any way to the project. Contributions, which must be reviewed by a Committer and approved by a Maintainer, can include:
  • Code
  • Tests
  • Scripts
  • Documentation
  • Translation (for those projects with an output that might need to be in additional languages) 
  • Other roles as designated by the maintainer

All project roles will be identified within the root of the repo (in the GOVERNANCE.md file) and the process for participating within the project will be documented.

Repo Management

The following table describes how a repo, as part of an open-source SVTA project, will be managed.

* Note: as per the SVTA operating procedures, if the modification of the scope represents “material change” (i.e., such as changing the core functionality of the open source project), then it would need to be re-ratified.

Role Recognition

All official roles will be recognized on an SVTA LABS webpage specific to the repo. This page will be separate from the SVTA project page.

Role Participation

The following describes how a person would participate in a given role. The governing Working Group will determine, at its discretion, the required expertise for any individual requesting a role in the project. The Working Group chairs and project lead will be the final authority for approval of requested roles.

Project Work

It should be noted that all project work should align with the scoping document. It is part of the Maintainer and Committer role to evaluate contributions and ensure they align with the approved project scope.

Special Circumstances

There may be special circumstances which should be documented. The following have been identified which are not-exclusive of all special circumstances that may arise. This document will be updated as new circumstances arise.

• WG wind-down

WG Wind-down

In the event that a WG, with an active open-source project, winds-down or otherwise ceases operations within the SVTA, the following shall apply:

1. The board shall review and decide if the open-source project should continue
   1. If the project should continue, the board will recommend a transition to a new working group
      1. If the project is a public-facing project and the board decides that the project should not continue, SVTA staff shall update the repo to indicate that the project is no longer maintained
      2. If the project is not public-facing and the board decides that the project should not continue, SVTA staff shall update the repo to indicate that the project is no longer maintained and alert all SVTA members of such

Expectations

All SVTA open-source projects have the following expectations of anyone involved:

1. Any contributions will be the original work of the contributor. If a contributor wishes to provide input that is from another project (perhaps another open-source library), it will need to be cleared by the maintainer first. All requests for this should be sent to labs@svta.org (this mailbox will be accessible by all SVTA staff).
2. All comments made will be professional and related only to the project. No racist, misogynistic, defamatory, or personally attacking comments will be tolerated and violators will be blocked from the project immediately.
3. All contributors must agree to the DCO

Transparency

Every SVTA open-source project should employ a tool like Vossibility to report on project contributions by contributors.

Changes

In the event that changes to his governance model are required, such as terms or license applied to SVTA open source projects, those changes will be presented to and approved by the SVTA board of directors.