Add governance document. (#1225)

GOVERNANCE.md

@@ -0,0 +1,377 @@
+# UV Governance Document
+
+Adopted 8 November 2024
+
+Last updated 7 November 2024
+
+Developed and drafted by members of the Universal Viewer Steering Group (alphabetically: Saira Akhter, Erin Burnand, Demian Katz, James Misson, Lanie Okorodudu), inspired by [the work of the VuFind® Community Planning Group](https://github.com/vufind-org/vufind/blob/dev/GOVERNANCE.md); see [**Acknowledgements**](#acknowledgements) below for additional
+attributions.
+
+## Overview
+
+The Universal Viewer was developed as a community driven, open source project. 
+Its mission is to ensure the long-term technical and financial sustainability of the software,
+its documentation, and its development processes. Anyone with an
+interest in the project can join the community, contribute to the
+project design, and participate in the decision-making process.
+
+The Universal Viewer Steering Group (SG) provides a unified strategic direction and sustainability to the UV community and to allocate Open Collective funds as appropriate. Steering group membership is open to all institutions at the sponsor level on Open Collective and to other major contributors to project code and administration, subject to Steering Group approval.
+
+This document describes how community participation takes place and how
+to set about earning merit within the project.
+
+## Roles And Responsibilities
+
+### Users
+
+Users are community members who have a need for the Universal Viewer. They are the
+most important members of the community and without them the project
+would have no purpose. Anyone can be a user; there are no special
+requirements.
+
+The Universal Viewer asks its users to participate in the project and community as
+much as possible. User contributions enable the project team to ensure
+that they are satisfying the needs of those users. Common user
+contributions include (but are not limited to):
+
+* evangelising about the project (e.g. a link on a website and word-of-mouth awareness raising)
+* informing developers of strengths and weaknesses from a new user perspective
+* starting conversations between the Universal Viewer community and
+    complementary projects
+* sharing manifests
+* testing with different types of content
+* providing practical support on all aspects of UV implementation 
+* providing moral support (a 'thank you' goes a long way)
+* providing financial support (the software is open source, but the
+    project and community need to be sustainable)
+
+Users who continue to engage with the project and its community will
+often become more and more involved. Such users may find themselves
+becoming contributors, as described below.
+
+### Organizational Users
+
+Organizational users are commercial or non-profit entities which rely
+upon the Universal Viewer for some or all of their day-to-day operations.
+Organizational users might:
+
+* sell Universal Viewer-related services (hosting, support, development)
+* offer online tools powered by Universal Viewer (searchable databases,
+    catalogs, etc.)
+* use Universal Viewer for internal business processes (e.g. enabling search of
+    an intranet)
+
+As long as they comply with the legal terms of the software's [license](https://github.com/UniversalViewer/universalviewer/blob/dev/LICENSE.txt),
+organizational users have no specific obligations to the Universal Viewer
+community. However, it is in their best interest to support the
+sustainability of the software to ensure that it continues to meet their
+needs. As such, organizational users are strongly encouraged to
+contribute back to the community by sharing locally-developed code, by
+encouraging and/or supporting staff to dedicate time to the project, and
+by offering financial support when possible. Some forms of support also
+have specific tangible benefits; see below under "Financial Membership"
+for more details.
+
+### Contributors
+
+Contributors are community members who contribute in concrete ways to
+the project. Anyone can become a contributor, and contributions can take
+many forms. There is no expectation of commitment to the project, no
+specific skill requirements and no selection process.
+
+In addition to their actions as users, contributors may also find
+themselves doing one or more of the following:
+
+* supporting new users (existing users are often the best people to
+    support new users)
+* reporting bugs
+* identifying requirements
+* programming (fixing bugs / adding features)
+* assisting with project infrastructure
+* writing and editing documentation
+* offering useful services (hosting, procurement, etc.) to the
+    community
+
+Contributors engage with the project through the project's [GitHub
+organization](https://github.com/UniversalViewer). They submit changes to the project itself via
+[pull requests](https://github.com/UniversalViewer/universalviewer/blob/dev/CONTRIBUTING.md),
+which will be considered for inclusion in the project by existing
+committers (see next section). The [Universal Viewer
+Slack](https://universalviewer.slack.com)
+is the most appropriate place to ask for help when making
+that first contribution.
+
+All contributions will be carefully reviewed, and detailed feedback will
+be provided by the community in a timely fashion. In most cases, some
+revisions will be suggested or required before a contribution can be
+merged into the project. As per the project's [code of
+conduct](https://github.com/UniversalViewer/universalviewer/blob/dev/CODE_OF_CONDUCT.md),
+feedback should always be provided in a constructive fashion, and
+contributors should view this feedback as an opportunity to learn more
+about the project and to develop new coding techniques; it is never
+intended as a personal criticism or attack.
+
+As contributors gain experience and familiarity with the project, their
+profile within, and commitment to, the community will increase.
+Contributors who demonstrate a detailed understanding of the project by
+consistently submitting stable and impactful contributions may be
+nominated to become committers for the project (see below).
+
+### Committers
+
+Committers are community members who have shown that they are committed
+to the continued development of the project through ongoing engagement
+with the community. Committership allows contributors to more easily
+carry on with their project related activities by giving them direct
+access to the project's resources. Most importantly, they have the power
+not only to submit pull requests, but also to merge them into the
+project.
+
+This does not mean that committers are free to do what they want. In
+fact, committers have no more authority over the project than
+contributors. While committership indicates a valued member of the
+community who has demonstrated a healthy respect for the project's aims
+and objectives, their work should still be submitted in the form of pull
+requests and must still be reviewed by the community before acceptance
+in an official release. The key difference between a committer and a
+contributor is that a committer can merge work that has been
+successfully reviewed, while a contributor must wait for assistance from
+a committer. For more details on the process, see the 
+[CONTRIBUTING page](https://github.com/UniversalViewer/universalviewer/blob/dev/CONTRIBUTING.md).
+
+Anyone can become a committer; there are no special requirements, other
+than to have shown a willingness and ability to participate in the
+project as a team player. Typically, a potential committer will need to
+show that they have an understanding of the project, its objectives and
+its strategy. They will also have provided valuable contributions to the
+project over a period of time.
+
+New committers can be nominated by any existing committer. Once they
+have been nominated, there will be a vote by the Steering Group (SG; see below). Committer voting is one of the few activities that takes place through private SG communication. This is
+to allow SG members to freely express their opinions about a nominee
+without causing embarrassment.
+
+The nominee will be directly notified by email of voting results, and is
+entitled to request an explanation of any 'no' votes against them,
+regardless of the outcome of the vote. This explanation will be provided
+by the SG Chair (see below) and will be anonymous and
+constructive in nature. New committers who pass the SG vote are announced
+in the [Universal Viewer
+Slack](universalviewer.slack.com).
+
+Nominees may decline their appointment as a committer. However, this is
+unusual, as the project does not expect any specific time or resource
+commitment from its community members. The intention behind the role of
+committer is to allow people to contribute to the project more easily,
+not to tie them into the project in any formal way.
+
+It is important to recognise that committership is a privilege, not a
+right. That privilege must be earned and once earned it can be removed
+by the SG (see next section) in extreme circumstances. However, under
+normal circumstances committership exists for as long as the committer
+wishes to continue engaging with the project.
+
+
+### Universal Viewer Steering Group
+
+The Universal Viewer Steering Group (SG) consists of those
+individuals identified on the [Universal Viewer
+website](https://github.com/UniversalViewer/universalviewer/wiki/Steering-Group). The SG has additional
+responsibilities over and above those of a committer. These
+responsibilities ensure the smooth running of the project. SG members
+are expected to review code contributions, participate in strategic
+planning, approve changes to the governance model/document, and manage
+the copyrights within the project outputs. The SG also votes to fill
+key roles related to Universal Viewer's membership in the Open Collective,
+including a Treasurer to manage the project's finances. All special SG
+roles are documented on the [Steering Group page of the Universal Viewer
+website](https://github.com/UniversalViewer/universalviewer/wiki/Steering-Group).
+
+Members of the SG do not have significant authority over other members
+of the community, although it is the SG that votes on new committers
+and responds to code of conduct violations. It also helps to make
+decisions when community consensus cannot be reached. In addition, the
+SG has access to the project's private communication channels. Private
+communication is used for sensitive issues, such as votes for new
+committers (see above), discussion of misconduct reports, and legal or
+financial matters that cannot be discussed in public. It is never used
+for project management or planning.
+
+In the case of gross misconduct, such as repeated code of conduct
+violations or serious breach of reviewing/merging protocol, a SG member
+or committer can be removed from their role. Such a removal requires a
+two-thirds majority vote of the SG. The SG may also vote on whether to
+make the ban temporary or permanent, as appropriate to the
+circumstances.
+
+
+### Other Project Roles
+
+While this document details some of the largest and most critical roles
+and responsibilities within the Universal Viewer project, there are many smaller
+jobs that support the project's success, ranging from responding to newcomer questions
+to release management. Because these roles may grow and evolve over
+time, it is impractical to try to capture all of them in this document;
+they are instead listed on the [UV Community Team](https://github.com/UniversalViewer/universalviewer/blob/dev/COMMUNITY_TEAM.md)
+web page. The assignment of individuals to these roles is accomplished
+by vote of the SG.
+
+## Support
+
+All participants in the community are encouraged to provide support for
+new users within the project management infrastructure. This support is
+provided as a way of growing the community. Those seeking support should
+recognise that all support activity within the project is voluntary and
+is therefore provided as and when time allows. A user requiring
+guaranteed response times or results should therefore seek to purchase a
+support contract from an external support provider. However, for those
+willing to engage with the project on its own terms, and willing to help
+support other users, the community support channels on [Slack](universalviewer.slack.com) are ideal.
+
+## Financial Membership
+
+Financial membership enables the project to be financially sustainable
+and, in time, financially independent. Financial membership is available
+at various levels, with certain benefits applying to each level.
+Membership levels and benefits are set by the SG, and current options
+are summarized on the [Open Collective](https://opencollective.com/universalviewer)
+web page. Lack of financial membership does not preclude any member of
+the community from contributing in any
+other way to the project. Financial
+support is essential and greatly appreciated, but it is not a substitute
+for meaningful engagement with the work of the project.
+
+## Decision Making Process
+
+Decisions about the future of the project are made through discussion
+with all members of the community, from the newest user to the most
+experienced SG member. All non-sensitive project management discussion
+takes place on the [Universal Viewer
+Slack](universalviewer.slack.com). Occasionally, sensitive discussion occurs in private, as
+discussed above under [**Universal Viewer Steering Group**](#universal-viewer-steering-group).
+
+In order to ensure that the project is not bogged down by endless
+discussion and continual voting, the project operates a policy of lazy
+consensus. This allows the majority of decisions to be made without
+resorting to a formal vote.
+
+### Lazy consensus
+
+Decision making typically involves the following steps:
+
+* Proposal
+* Discussion
+* Vote (if consensus is not reached through discussion)
+* Decision
+
+Any community member can make a proposal for consideration by the
+community. In order to initiate a discussion about a new idea, they
+should submit a [pull
+request](https://github.com/UniversalViewer/universalviewer/pulls) or [issue](https://github.com/UniversalViewer/universalviewer/issues). For complex
+or potentially controversial submissions, sending a message to the
+[Universal Viewer
+Slack](https://universalviewer.slack.com)
+is also strongly encouraged, to ensure that the submissions
+receive an appropriate amount of attention. This will prompt a review
+and, if necessary, a discussion of the idea. The goal of this review and
+discussion is to gain approval for the contribution. Since most people
+in the project community have a shared vision, there is often little
+need for discussion in order to reach consensus.
+
+In general, as long as nobody explicitly opposes a proposal or patch, it
+is recognised as having the support of the community. This is called
+lazy consensus - that is, those who have not stated their opinion
+explicitly have implicitly agreed to the implementation of the proposal.
+
+Lazy consensus is a very important concept within the project. It is
+this process that allows a large group of people to efficiently reach
+consensus, as someone with no objections to a proposal need not spend
+time stating their position, and others need not spend time reading such
+messages.
+
+For lazy consensus to be effective, it is necessary to allow at least 72
+hours before assuming that there are no objections to the proposal. This
+requirement ensures that everyone is given enough time to read, digest
+and respond to the proposal. This time period is chosen so as to be as
+inclusive as possible of all participants, regardless of their location
+and time commitments.
+
+In cases where lazy consensus cannot be reached, discussion should take
+place within the comments of the issue ticket or pull request
+representing the proposal, in order to keep the conversation associated
+with the submission. If a real-time discussion is desirable, a request
+can be sent to the [Universal Viewer
+Slack](https://universalviewer.slack.com)
+list to have the item added to the agenda for the next scheduled
+[Community Call](https://github.com/UniversalViewer/universalviewer/wiki/Community-Call). If 72
+hours pass with no dissenting comments left unresolved in the
+conversation, and with no pending Community Call discussion scheduled,
+consensus can be considered to have been reached. Otherwise, voting may
+be necessary to reach a final decision.
+
+### Voting
+
+Not all decisions can be made using lazy consensus. Technical
+conversations that cannot be fully resolved through conversation may
+need a vote for resolution, and issues such as those affecting the
+strategic direction or legal standing of the project must gain explicit
+approval in the form of a vote. Every member of the community is
+encouraged to express their opinions in all discussion and all votes.
+However, only a subset of the community have binding votes for the
+purposes of decision making. The voting mechanism and participants vary
+depending on the type of vote.
+
+#### Technical Votes
+
+Technical votes are required when consensus cannot be reached around a
+proposal or submission. The question being voted on should be phrased
+clearly and unambiguously, such as "Should we merge pull request X?" or
+"Should we make architectural change / technical decision Y?" Voting
+should be announced through a message on the [Universal Viewer
+Slack](https://universalviewer.slack.com).
+Feedback is welcomed from the entire community, but only committers have
+binding votes. Votes are made through public comment on the issue or PR
+under discussion. If, after one week from the start of voting, a simple
+majority has been reached among eligible voters, the issue is considered
+resolved. In the case of a tie, a simple majority among SG members can
+serve as a tie-breaker. In the case of a further tie, the SG Chair can make the final decision.
+
+#### Steering Group Votes
+
+As noted above, there are a number of circumstances that may require a
+vote of the SG: resolving code of conduct
+issues, adjusting policies, and making high-level decisions about legal
+and financial matters. Any member of the SG may raise such an issue for
+voting via the group's private communication channel, and group members
+will have one week to respond. At the end of the voting period, a
+two-thirds majority must be reached to take the proposed action or make
+the proposed change. The voting period may be resolved early if all SG
+members have participated.
+
+Because SG voting takes place in private, it is important for project
+transparency that voting outcomes are shared with the larger community.
+Votes involving interpersonal conflict resolution \-- for example, code
+of conduct violations \-- will not be shared to protect the privacy of
+the parties involved. All other decisions should be shared to the
+[Universal Viewer
+Slack](https://universalviewer.slack.com)
+by a SG member. 
+
+
+#### Communication and Monitoring
+
+Committers and members of the SG are strongly encouraged to follow the
+project's GitHub organization so that they will receive notifications of
+new pull requests and can contribute reviews as their time and expertise
+permit. Contributors are also encouraged to send a message about their
+contribution to the [Universal Viewer
+Slack](https://universalviewer.slack.com)
+if they do not receive a review in a timely fashion.
+
+
+## Acknowledgements
+
+This document is based in large part on the OSS Watch \"[Template for a Meritocratic Governance Document](http://oss-watch.ac.uk/resources/meritocraticgovernancemodel##template-for-a-meritocratic-governance-document),\"
+which was written by Ross Gardler and Gabriel Hanganu and licensed under
+a Creative Commons Attribution-ShareAlike 4.0 International License.
+