path: root/quip-0002.rst

QUIP: 2
Title: The Qt Governance Model
Author: Thiago Macieira
        Lars Knoll
        Louai Al-Khanji
Status: Active
Type: Process
Post-History: https://lists.qt-project.org/pipermail/development/2016-September/027218.html
Created: 2016-09-03

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 may change as the Qt Project and its community evolve.

Objectives
==========

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
-----

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
------------

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://forums.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
---------

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`_.

.. _`Gerrit Approvers group`: https://codereview.qt-project.org/admin/groups/12,members

How to become an Approver
'''''''''''''''''''''''''

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
-----------

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`_.

.. _`on the Qt project Wiki`: https://wiki.qt.io/Maintainers

How to become a Maintainer
''''''''''''''''''''''''''

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.

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.

Chief Maintainer
----------------

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.

How to become Chief Maintainer
''''''''''''''''''''''''''''''

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.

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 voting.

Lazy consensus
''''''''''''''

Decision-making typically involves the following steps:

# Proposal
# Discussion
# Decision, by
## Consensus
## 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.