This document is a draft for discussion and still a work in progress. To contribute, please submit a pull request. Major changes will be discussed in the comment section.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in the RFC 2119

Unitex/GramLab is an open source, cross-platform, multilingual, lexicon- and grammar-based corpus processing suite. Project decision-making is based on a community meritocratic process. Anyone with an interest in Unitex/GramLab can join the community, contribute to the project design and participate in decisions. This document describes how that participation takes place and how to set about earning merit within the project community.

• All Unitex/GramLab programs, libraries and source codes are distributed under the terms of the GNU Lesser General Public License version 2.1 (LGPLv2), which itself incorporates the terms and conditions of the GNU General Public License.

• Linguistic Resources are distributed under the terms of the Lesser General Public License For Linguistic Resources (LGPLLR).

• Documentation is licensed under the terms of the GNU Free Documentation License version 1.3 (GFDL), as published by the Free Software Foundation.

• Unitex/GramLab includes copyrighted third-party libraries licensed under the terms of the Apache Software License version 2.0 (Apache-2.0), the BSD 2-Clause License (BSD License), and the MIT License (MIT). All third-party packages are copyright by their respective authors.

Unitex/GramLab is intended to be a safe, welcoming space for collaboration. All contributors and participants are expected to adhere to the Contributor Covenant version 1.4 code of conduct. To report violations, send an email to conduct@unitexgramlab.org.

All participants in the Unitex/GramLab 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 a community member. However, for those willing to engage with the project on its own terms, and willing to help support other users, the community support channels, as the developer mailing list or the users forum, are ideal.

Unitex/GramLab development is based on user consensus and open discussion between users. In order to have a smoothly running project, formal roles with corresponding responsibilities are established. A member of the community may have multiple roles.

Unitex/GramLab users are community members who have a need for the project, they are the most important members of the community: through their usage, they give the project a purpose. Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include, but are not limited to:

• Evangelising about the project.
• Informing developers of strengths and weaknesses from a new user perspective both through the Unitex/GramLab forum or following the Bug Reporting Guide.
• Identifying needs and filing feature requests.
• Participating on the users forum.
• Providing moral support, a 'thank you' goes a long way.

Anyone can be a user; there are no special requirements. Users who continue to engage with the project and the community will often find themselves becoming more and more involved. Such users may then go on to become Unitex/GramLab Contributors, as described below.

Unitex/GramLab Contributors are community members who contribute in concrete ways to the project. Contribution may be a one time participation or occur over time. Contribution can take place in many specific ways:

• Helping maintain existing linguistic resources.
• Submitting patches to fix bugs or add features.
• Identifying requirements.
• Participating in the community's activities.

Unitex/GramLab Committers are contributors who have shown dedication to the project, i.e. providing valuable contribution over a period of time, have a deep understanding of the code base and project strategy and work well with contributors and users. Committers have no more authorities than contributors, and they should engage with the community through the developer mailing list or the users forum regarding their intention. However committers have earn enough trust from the community to have direct access to the project code base without having to submit pull requests. Committers seeks approval after the contribution is made, rather than before. Therefor committers:

• Help contributors via the developer mailing list.
• Merge pull request submit by contributors.
• Have direct access to the code base.
• Nominate and vote new committers.
• Participate in the release planning.

[LR-contributor]

• Contributing to new linguistic resources and helping maintain existing ones.

You need to start being a Unitex/GramLab Contributor and be then be nominated as a Linguistic Resources Committer. Unitex/GramLab committers select and elect new ones using the Guidelines for assessing new candidates for committership from the Apache Software Foundation.

[DEV-Committer]

• Adding features.
• Assisting with project infrastructure.

The documentation for developers is a good place to start getting familiar with the coding style and documentation guidelines. We invite contributors to share their feature development and patch idea through the developer mailing list or the users forum. It is recommended to start with small patches and share your code early so the existing committers can provide feedback and guidance.

Non-code contributions ([Committer]) are incredibly valuable and very welcome, Here are some examples of simple ways to contribute:

• Writing and maintaining the documentation (e.g. tutorials)

Unitex/GramLab Sponsors are ...

The Unitex/GramLab Management Committee (UGMC) has additional responsibilities over and above those of a committer or sponsor. These responsibilities ensure the smooth running of the project. Project Management Committee activities include:

• Participate in strategic planning.
• Approve changes to the governance model.
• Manage the copyrights within the project outputs.
• Access to the project's private archives (They are never used for project management or planning. This include information about sensitive issues, and legal matters that cannot be discussed in public.)

The Unitex/GramLab Management Committee Members do not have significant authority over other members of the community, although they make decisions when community consensus cannot be reached.

Membership of the UGMC is by invitation from the existing members. A nomination will result in discussion and then a vote by the existing members. Membership votes are subject to consensus approval of the current members.

The UGMC Chair is a single committer and the project leader whom people interested in the project can consider the primary point of contact or first point of contact for the project. The chair is voted by the members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the UGMC casts a two-thirds majority vote to remove them.

The Chair has no additional authority over other members of the UGMC: the role is one of coordinator and point of contact. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.

From a practical point of view, the direction that the project takes is controlled by the contributors, not the users, unless they're contributors too. Development is made based on contributors and committers donating their time to the community. In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates using the Apache Decision Making process. This allows the majority of decisions to be made without resorting to a formal vote.

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 mails. 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 all cases silence is consent.

The lazy consensus is used for most the contribution ranging from bug fixes to minor changes where the contributor assume to have the support of the community to tackle the issue.

Not all decisions can be made using lazy consensus. If you feel that lazy consensus isn't appropriate for your proposal, you can explicitly request for feedback on the developer mailing list. Building consensus help contributors and committers to gather feedback early on and pool the interest by the community for a new feature.

Contributors are invited to express their opinion of any given feature or pull request. Support is expressed using:

Building community trust in the governance of an open-source project is vital to its success. To that end, Unitex/GramLab project decision making must be done in a transparent, open fashion. No decisions about the project's direction, bug fixes or features may be done without community involvement and participation. Discussions must begin at the earliest possible point on a topic; the community’s participation is vital during the entire decision-making process.

This document is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. This work is based upon the OpenRefine Governance Model and the OWIN Project Governance model, which themselves are based upon Meritocratic Governance Model by University of Oxford. This document contains information about the Lazy Consensus concept available from the Apache Community and uses the Semantic Versioning scheme to track version releases.

Copyright (C) 2022 Université Gustave Eiffel