Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

The Qt Governance Model

From Qt Wiki
Revision as of 14:23, 23 February 2015 by Maintenance script (talk | contribs)
Jump to navigation Jump to search


The Qt Governance Model

Overview

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 will probably change as the Qt Project and its community develop.

Objectives

The main objectives of the Governance Model are to:

  • Put decision 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: Users, Contributors, Approvers, Maintainers and Chief Maintainer are described below.

Users

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:

  • Evangelizing about the Project (e.g. a link on a website and word-of-mouth awareness raising)
  • 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

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:

Contributors engage with the Project through tools like the issue tracker, code review tool, 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.

Both Users and Contributors are able to see and comment on all contributions to the Project via the code review tool. 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.

A Contributor’s profile will increase as he / she gains experience with the Project and makes significant contributions to it. As a result they may be nominated as an Approver, described in the next section.

Approvers

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.

How to become an Approver

A Contributor can be nominated as an Approver by an "existing Approver":http://codereview.qt.io/#admin,group,12 , 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

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 his / her 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, ideally 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.

How to become a Maintainer

An Approver who makes a high level of contribution to the Project, 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 his / her component.

All new Maintainer nominations must be seconded by "another Maintainer":http://codereview.qt.io/#admin,group,13 .

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.

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.

Chief Maintainer

The Chief Maintainer leads the Maintainer group, coordinating and facilitating its activities.

He / she sets the overall vision and direction of the Qt Project.

The Chief Maintainer has the final say when the Project fails to reach consensus. He / she 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.

How to become Chief Maintainer

When the Chief Maintainer decides to step down, the Maintainers will arrange a vote to choose his / her 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 there is a vote of no confidence by two-thirds of all Maintainers.

Support

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.

Decision-making process

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 consensus discussions.

Lazy consensus

Decision-making typically involves the following steps:

  1. Proposal
  2. Discussion
  3. Decision, by
    1. Consensus
    2. Maintainer, if consensus is not reached through discussion
    3. 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 should 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.

Contribution process

The new process is documented in the Qt Contribution Guidelines

Based on the "Meritocratic Governance Model":http://www.oss-watch.ac.uk/resources/meritocraticGovernanceModel.xml OSS-Watch template.

Retrieved from "https://wiki-qt-io-staging.herokuapp.com/index.php?title=The_Qt_Governance_Model&oldid=2799"