QUIP 2: The Qt Governance Model

This is mostly a copy of http://wiki.qt.io/The_Qt_Governance_Model
as of 2017-02-07, reformatted according to QUIP 1.

Some smaller adjustments for readability and clarity have been
made.

Change-Id: I7751ab07eeef5f66583c75ae1c13175071a75a02
Reviewed-by: Robert Loehning <robert.loehning@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>

1 files changed, 284 insertions, 0 deletions

diff --git a/quip-0002.txt b/quip-0002.txt
new file mode 100644
index 0000000..d785ba4
--- /dev/null
+++ b/quip-0002.txt
@@ -0,0 +1,284 @@
+QUIP: 2
+Title: The Qt Governance Model
+Author: Thiago Macieira
+        Lars Knoll
+        Louai Al-Khanji
+Status: Active
+Type: Process
+Post-History: http://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.
+
+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.
+
+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.