Qt governance

Contributors

The Active Process QUIP 2: Qt Governance Model describes Contributors as people who take part in the project through work such as code, documentation, tests, bug reports, review, release work, or community support. Becoming a contributor does not require selection.

Participation is open; authority depends on the role and the project's review configuration. A reviewer suggestion, contribution count, or Qt Town ranking does not grant approval or maintainer rights.

Community conduct

The Qt Community Code of Conduct (QUIP 12) is marked Active / Process in the source checked on 19 October 2026. It applies to Qt Project contributors and users of Qt Project community services, and sets expectations for respectful participation. If you face a problem in a Qt community, consult the Code of Conduct and contact the moderators or leaders of the affected Qt channel. For a suspected open-source Qt vulnerability, see the guide's private security reporting guidance.

Approvers

Approvers are contributors recognized for their commitment to Qt and its long-term success. They assess contributions against Qt's technical direction and project goals, provide constructive feedback, and help contributors learn. Approval privileges are recorded in the Gerrit Approvers group; a maintainer-list match alone does not establish that someone is an approver. Approvers should review within their expertise and follow the review policy.

Maintainers

Maintainers are recognized leaders responsible for specific components. They oversee component quality and release readiness, follow contributor and reviewer activity, and give final approval to API and C++ header changes in their component during API review before a release. They also help keep included third-party code current under Qt's security policy and contribute to project planning, governance, and review.

The Qt maintainer list at revision 46241, checked 10 October 2026, records named responsibilities. A listed maintainer may delegate part of a component or temporarily delegate duties while retaining responsibility. Maintainer roles and approval scope depend on the project: maintainers of main Qt modules receive approval privilege throughout Qt, while a playground maintainer's privilege is scoped to that project. The list documents responsibility; it does not promise availability. Qt Town's missing badge or review statistics do not establish that a person lacks a role.

How to become an approver

An existing Approver can nominate a Contributor. Another Approver or Maintainer must second the nomination. The nominee is appointed unless a community member objects to the Chief Maintainer within 15 work days. If there is an objection, the Chief Maintainer decides, usually within 15 work days. The decision period is usual practice, not a guaranteed deadline. See QUIP 2's approver recognition process.

How to become a maintainer

A Contributor with substantial contributions, particularly to Qt's direction and long-term success, can be nominated by an existing Maintainer. Candidates are typically Approvers, but QUIP 2 does not make that a prerequisite. Another Maintainer must second the nomination. The nominee is appointed unless a community member objects to the Chief Maintainer within 15 work days; if there is an objection, the Chief Maintainer decides, usually within 15 work days. An existing Maintainer can also nominate someone to take responsibility for part of their component. After appointment, the maintainer list records the responsibility. See QUIP 2's maintainer recognition process.

These roles recognize sustained contributions and trust. QUIP 2 sets no minimum commit or review count, employment requirement, or automatic promotion threshold. Activity statistics cannot determine eligibility or confer a Qt role.

Discussion and consensus

QUIP 2 describes lazy consensus for project proposals and discussion on the development mailing list: participants should have an opportunity to review a proposal, raise concerns, and discuss a way forward. Allow a reasonable, inclusive time for input; QUIP 2 does not set one general fixed timeout. A lack of response should not be presented as instant approval; follow the proposal's stated review period and the relevant Qt process. For code, use the repository's Gerrit review requirements and address outstanding objections and checks.

What a QUIP means

A Qt Project Improvement Proposal (QUIP) is a versioned document for describing an idea, gathering input, and recording its status and decisions. The QUIP index lists proposal types and states. Informational QUIPs record information and do not necessarily claim consensus. Process and Implementation QUIPs generally require consensus under the process described in QUIP 1.

QUIP 1: QUIP Process explains how proposals are authored, reviewed, discussed, and accepted or rejected. Read both the type and current status of a proposal. A draft records a proposal under discussion; it is not an adopted project rule or commitment.

Active policy and a draft writing proposal

QUIP 2 is currently marked Active Process and describes the governance model. QUIP 25: Qt Documentation Writing Style is marked Draft / Informational in the source checked on 10 October 2026. It discusses documentation style, but it is not adopted policy. Qt Town follows the maintained Qt Writing Guidelines and links to the current Microsoft Writing Style Guide; see the contribution guide.

Check the live QUIP pages and relevant project policies for updates. Qt Town presents public-source guidance and does not speak for the Qt Project.