QUIP 2 | The Qt Governance Model
|Title:||The Qt Governance Model|
|Author:||Thiago Macieira Lars Knoll Louai Al-Khanji|
The Qt Project is a meritocratic, consensus-based community interested in Qt.
Anyone who shares that interest can join the community, participate in its decision-making processes, and contribute to Qt's development.
This document describes the current "governance model" for the Project, i.e. the five levels of participation and how community members get involved in making decisions.
The model may change as the Qt Project and its community evolve.
The main objectives of the Governance Model are to:
- Put decision-making power in the hands of the community, i.e. the people who contribute to the Project's success
- Make it easy to understand how to get involved and make a difference
The five levels of involvement are described below: Users, Contributors, Approvers, Maintainers and Chief Maintainer.
Users are community members who have a need for the Project. 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 Qt Project asks its Users to participate in the community as actively as possible. Common User contributions will include:
- Raise awareness of the Project (e.g. a link on a website or word of mouth)
- Giving the community feedback from a User perspective, and being courteous and constructive when doing so
- Providing moral support (a 'thank you' goes a long way)
Users who continue to engage with the community will often become more and more involved. Such Users may find themselves becoming Contributors, as described in the next section.
Contributors are community members who provide significant input to the Project. Anyone can be a Contributor – there is no selection process.
In addition to User inputs, Contributors might support the Project in many ways including:
- Suggesting future developments
- Reporting bugs
- Triaging bugs
- Fixing bugs
- Programming (writing code, new tests, etc.)
- Reviewing other people's code
- Writing Documentation
- Participating in the release process
- Designing web sites and graphics
- Organizing conferences
- Doing community work (being active on mailing lists, forums like https://forum.qt.io, IRC and at events)
- Supporting and coaching new Users
- Improving the Qt contribution process
Contributors engage with the Project through tools like the issue tracker, code reviewing system, IRC and mailing lists, or by writing or editing documentation and wikis.
Code changes are submitted via patches, which will be considered for inclusion in the Project by existing Approvers (see next section). The developer mailing lists or IRC are the most appropriate places to ask for help when making a first contribution.
The project's code-review tool is publicly readable. By registering, one may become a Contributor and comment on changes proposed there as well as propose new changes. In that way they can help improve the code quality and may also be able to influence the review process, which ends at the acceptance or rejection by the Approver.
This commit-then-review process is efficient, as it allows everyone to make direct contributions into a review system. This levels the field between Contributors and Approvers, ensures that all contributions are reviewed, and allows all reviews and comments to be more easily tracked by the community as a whole.
The Contributor's profile will increase as they gain experience with the Project and make significant contributions to it. As a result they may be nominated as an Approver, described in the next section.
Approvers are Contributors who have shown that they are committed to the Project and its objectives, and perform an essential role safeguarding its long-term success.
Approvers review all code contributions and decide which are accepted based on "technical fit" and "spirit fit" with the Project. The Commit Policy is the authoritative guide by which contributions should be evaluated.
Approvers are expected to provide constructive feedback to rejected contributions. This helps Contributors learn the expected quality and direction of the Project, and thus improve the future contributions. Approvers are also expected to participate on relevant mailing lists and to coach Contributors.
The authoritative list of Approvers with the provilege to approve code contributions is the Gerrit Approvers group.
A Contributor can be nominated as an Approver by an existing Approver, and seconded by one other Approver or Maintainer. Once nominated and seconded, the Approver is appointed unless a community member objects to the Chief Maintainer within 15 work days. If an objection is raised, the Chief Maintainer decides, usually within 15 work days.
Discussion about the nomination may happen in private between existing Approvers. This allows Approvers to freely express their opinions about a nominee without causing embarrassment. The nominee can request an explanation of any rejection from the Chief Maintainer.
Once someone has been appointed Approver, they remain in that role until they choose to step down by informing the Chief Maintainer.
In extreme circumstances Approver privileges can be revoked by a vote of no confidence, proposed by an existing Approver or Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those Approvers and Maintainers who express an opinion.
Maintainers are recognized leaders in their area, and have been identified as owners of a component of the Project code.
A Maintainer may delegate responsibility for a subset of their component to another Maintainer.
Maintainers are responsible for the overall quality and spirit fit of their component, so they need good visibility of Contributor and Approver activity. They ensure the smooth running of the Project and must always be aware of the current state of their component, normally ensuring it is ready for beta release at any time.
Maintainers are expected to participate in strategic planning, approve changes to the governance model, manage intellectual property rights discussions within the community, and review code contributions which have not been reviewed by others.
The authoritative list of Maintainers, including the components they own, is on the Qt project Wiki.
A Contributor who makes a high level of contribution to the Project (typically as an Approver), particularly to its strategic direction and long-term success, may be nominated as a Maintainer by an existing Maintainer.
A Maintainer may also nominate a new Maintainer to take ownership of a subset of their component.
All new Maintainer nominations must be seconded by another Maintainer.
Once seconded, a new Maintainer is appointed unless a community member objects to the Chief Maintainer within 15 work days. If an objection is raised, the Chief Maintainer decides, usually within 15 work days.
When a Maintainer is newly appointed, the authoritative list of Maintainers on the Qt project Wiki is updated to record their area of responsibility and the new maintainer is added to the security mailing list (see QUIP 15), if not already subscribed.
Becoming Maintainer of anything in a main module of Qt implies becoming Approver throughout Qt, if one is not so yet. The Maintainer of a playground project is an Approver for that project, even if not so more generally.
Maintainers may delegate their responsibilities temporarily to people they trust, such as when unavailable for extended periods. In this case, the Maintainer who has delegated retains responsibility for the actions of the person who received the delegation.
Once someone has been appointed Maintainer, they remain in that role until they choose to step down by informing the Chief Maintainer, preferably with one month's warning.
In extreme circumstances Maintainer privileges can be revoked by a vote of no confidence, proposed by an existing Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those Maintainers who express an opinion.
The Chief Maintainer leads the Maintainer group, coordinating and facilitating its activities.
The Chief Maintainer sets the overall vision and direction of the Qt Project.
The Chief Maintainer has the final say when the Project fails to reach consensus. The Chief Maintainer is expected to ensure that all governance processes are adhered to, and to intercede if other community members aren't acting appropriately.
The Chief Maintainer will also oversee contributions from a strategic and roadmap perspective.
When the Chief Maintainer decides to step down, the Maintainers will arrange a vote to choose a successor by simple majority vote of all Maintainers.
Once someone has been appointed Chief Maintainer, they remain in that role until they choose to step down by informing the Maintainers, preferably with one month's warning, or until there is a vote of no confidence by two-thirds of all Maintainers.
All participants in the community are encouraged to provide support for new Users. This support is an important way to grow the community. Those seeking help should recognize 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 seek to purchase a support contract from other sources, but for those willing to engage with the Project on its own terms, and willing to help support other Users, the community support channels are ideal.
Decisions about the future of the Project are made through mailing list discussion with the members of the community, from the newest User to the Chief Maintainer.
In order to ensure that decisions are not bogged down by requiring formal consensus, the Project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to formal voting.
Decision-making typically involves the following steps:
- Decision, by
- Maintainer, if consensus is not reached through discussion
- Chief Maintainer, if Maintainers disagree and cannot reach consensus
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the Project Contributor mailing list or submit a patch implementing the idea to the review tool, which is the preferred option. 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 community tend to 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 recognized 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 mails.
For lazy consensus to be effective, a reasonable amount of time should pass before assuming no objections. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period should be chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.