The name of this open source project is Tethys Platform
Lower the barrier to creating earth sciences web applications.
The Tethys Platform Project Steering Committee (PSC) is the official governing body of the Tethys Platform open source project and is responsible for all management aspects. The PSC is responsible for setting the overall direction of the project and its releases, determining what features go in, managing the documentation, assigning and revoking commit rights, etc.
This section describes how the (PSC) is formed and operates to make decisions on all aspects (both technical and non-technical) of the Tethys Platform project.
Current committee members are:
The PSC is made up of individuals who are either developers, users, or other stakeholders. Members are elected to participate in the PSC based on merit irrespective of their organizational ties. It is desirable but not strictly required of the PSC to be made up of an odd number of members to prevent ties in the voting process. The PSC should consist of at least 3 members, but no more than 7 to prevent too much bureaucracy.
One member of the PSC is appointed Chair, who has additional responsibilities to organize regular meetings and to resolve tie votes should they occur. The Chair may also appoint one member to act as Secretary. In the case where the Chair's position is vacated due to term limit, the committee will re-elect the chair, even if the person who was previously the Chair is voted back into the committee.
Positions in the PSC have a term limit of 3 years on alternating years, such that at least one position will be vacated and filled by election every year, and at least two positions stay consistent each year. Terms will expire at the beginning of the calendar year, although committee members should continue to serve until a replacement has been officially voted in.
Positions in the PSC will be labeled as Term 0, Term 1, Term 2 and so on, which indicate when the term expires according the following rules:
When a vacancy in the PSC is created, the PSC must call for nominations to fill the position on Tethys Platform GitHub Discussions. Nominees must indicate acceptance of the nomination by responding to the discussions post to be eligible for election. A self-nomination is treated as already being accepted by the nominee.
Nominations should be open for at least 1 week (7 days) at which point a list of all eligable nominees will be compiled into a ballot for voting. The ballot will be made available on Tethys Platform GitHub Discussions and be conducted in a way that votes can be cast privately (such as an anomynous web survey). All members of Tethys Platform GitHub Discussions may participate in the voting process for filling a PSC vacancy.
If for any reason a PSC member is not able to fully participate then they may step down. If a member is not active (e.g. no voting, no Tethys Platform GitHub Discussions participation, no participating in Code Modification Process, etc.) for a period of two months then the PSC reserves the right to seek nominations to fill that position. Should that person become active again, they would need to be re-elected to participate on the PSC again. Removing members for any reason (inactivity, a person that counteracts the goals of the project, etc.) requires a majority vote from the PSC or a supermajority (2/3) vote from members of Tethys Platform GitHub Discussions. Any vacancy created through resignation or removal must be filled as soon as possible as described previously.
The PSC is responsible for all aspects of managing the Tethys Platform open source project including setting the overall direction of the project and releases. This section outlines the responsibilities of the PSC as a whole and responsibilities of its members.
The PSC is responsible for defining the project roadmap, deciding which new features and significant code changes are accepted into the project, and into which release the change will appear. Deciding what features are accepted and when they are accepted is a multi-faceted decision, but the roadmap will always have a strong influence. The PSC should meet at least quarterly.
New project features and/or functionality is proposed to the PSC via the Code Modification Process. The PSC uses the Code Modification Process to decide if the change will be accepted and which release it will go into. In addition, the PSC determines when a branch enters the stabilization phase and ultimately when it is ready for release.
The PSC is responsible for defining the policies and procedures, including:
For actions that require a PSC vote a motion must first be made via a post on the Tethys Platform GitHub Discussions. Once a motion has been made the voting procedure will be as follows:
PSC members should take an active role guiding the development of new features they feel passionate about. They should stay engaged and ensure the change is implemented and documented in a way that is most beneficial to users. Note that this applies not only to change requests that affect code, but also those that affect the website, procedures, policies, etc.
PSC members are expected to participate in development and PSC meetings. If known in advance that a member cannot attend a meeting, the member should let the other members know through Tethys Platform GitHub Discussions or email. Continuously missing the development meetings may result in the member being asked to step down. Non-developer PSC members are expected to review the Tethys Platform development meeting minutes and attend the PSC meetings.
PSC members are expected to be active members of Tethys Platform GitHub Discussions. Non-developer members of the PSC are not expected to respond to coding level questions on Tethys Platform GitHub Discussions, however they are expected to provide their thoughts and opinions on user level requirements and compatibility issues when proposal discussions take place.
The chair has the extra responsibility to set up development and PSC meetings regarding future work, whenever he deems it necessary. The chair must schedule at least one development meeting and one PSC meeting every quarter. Development meetings are for the developers to report progress and ask/answer questions related to their tasks, whereas PSC meetings are for members of the PSC committee to discuss issues related to the project roadmap and governance.
The chair is responsible for closing votes and summarizing PSC member votes or appointing another PSC member to do so. The chair is responsible for adjudicating should there be a voting dispute.
The chair may appoint one member of the PSC committee as secretary to take minutes during the meetings.
All members of the community are expected to adhere to the Code of Conduct, which can be found in the GitHub repository. This includes all activities on the forum, in the code repository, during weekly scrum calls, during PSC meetings, and at any events hosted by the Tethys Platform organization such as annual Tethys Summit meetings. If members do not adhere to the Code of Conduct they may be removed from the forum and not allowed to participate in other events.
The main responsibility of the PSC lies in the management of the Tethys Platform code base. This the Tethys Platform repository on GitHub and other projects that are part of the Tethys Platform GitHub Organization. The decision-making process is based on reaching consensus through discussion from the community and approval from the PSC. More specifically, GitHub Flow workflow is used by the community and the PSC to manage ongoing code development.
Any member of the Tethys Platform community (including PSC members) can request code modifications (e.g. feature requests, bug fixes, documentation changes). This can be done in one of two ways:
By using the issue tracking system requesting a code modification the community member is, in essence, suggesting or proposing that a change be made. Discussion about the proposed change directly in the issue tracker is welcomed and encouraged among all interested community members. If, after appropriate discussion, the PSC deems that the suggested changes in an issue are in line with the project direction then they will add the issue to a milestone and, when suitable, assign it to a specific developer. Alternatively, the issue can be labeled with “help wanted” to encourage community members to address the issue and submit a PR. If the PSC does not accept an issue then they should mark it with the “wontfix” label and close it.
The process for accepting an issue is informal and does not require the formal approval process that is required by PRs since the issue does not include any actual changes to the code. However, it should be assumed that if an issue is accepted (i.e. not disputed), that a pull request that implements the suggested changes will also be accepted provided that the implementation meets the contribution guidelines.
The most formal way to submit a code modification is by submitting a pull request (PR) that includes all of the proposed modifications. All changes to the code base must be submitted as a PR. PRs that incorporate new features or major changes go through a formal review and approval process before they are merged into the code base.
Minor updates to existing features and bug fixes that are backwards compatible don't need official approval from the PSC, but should still go through the review processes. Once the review is complete then the code may be immediately merged by someone with commit access. However, those with commit access should not abuse this "right". If in doubt, get official approval from the PSC! If, after a commit, the PSC disagrees, the committer has the responsibility of undoing the changes without causing other people to redo their work.
When a new PR is received the submitter, if at all possible, should present/demo/describe the changes to the community at the next possible weekly scrum call. (If the submitter is unable to present the PR during a scrum then they may indicate via the comments on the PR and request that a review be assigned.) The PSC will then assign someone (either a PSC member or another member of the repository) to review the PR and make an official recommendation. Anyone from the community is also welcome and encouraged to review and comment on PRs. The reviewer may provide feedback to the developer who submitted the PR and suggest changes that would enable them to give a positive recommendation. Once the review process is complete and the reviewer has made an official recommendation to the PSC, the official approval process begins.
For a PR to be officially approved and merged into the code at least two PSC members must approve the PR after it has been reviewed and a recommendation is made, and no members of the PSC disapprove. If a PSC member disapproves they must provide a clear reasoning and, if applicable, alternate approaches to resolving the problem within two days. If the person that is submitting the PR is a PSC member, then they may still be one of the PSC members to approve the PR (indeed it is assumed that they do approve). However, PRs submitted by PSC members must still go through the review process.
Changes to this governing document can be proposed on Tethys Platform GitHub Discussions by creating a post with the "Amendment" tag. The specific language and section must be included in the proposal. The voting and comment period must last a minimum of 3 business days and only PSC member votes are binding. An amendment motion passes with a 2/3 majority of PSC members voting "+1". No vetoes are allowed for amendment motion votes.
Adapted from GEOMAJAS Project Steering Committee.