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; see Acknowledgements below for additional attributions.
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.
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 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, 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 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. They submit changes to the project itself via pull requests, which will be considered for inclusion in the project by existing committers (see next section). The Universal Viewer Slack 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, 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 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.
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.
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.
The Universal Viewer Steering Group (SG) consists of those individuals identified on the Universal Viewer website. 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.
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.
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 web page. The assignment of individuals to these roles is accomplished by vote of the SG.
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 are ideal.
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 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.
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. Occasionally, sensitive discussion occurs in private, as discussed above under 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.
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 or issue. For complex or potentially controversial submissions, sending a message to the Universal Viewer Slack 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 list to have the item added to the agenda for the next scheduled 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.
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 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. 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.
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 by a SG member.
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 if they do not receive a review in a timely fashion.
This document is based in large part on the OSS Watch "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.