The Qt Governance Model: Difference between revisions
No edit summary |
No edit summary |
||
| Line 1: | Line 1: | ||
[[Category:Developing_Qt::Guidelines]] | |||
==Overview== | = The Qt Governance Model = | ||
== Overview == | |||
The Qt Project is a meritocratic, consensus-based community interested in Qt. | The Qt Project is a meritocratic, consensus-based community interested in Qt. | ||
| Line 11: | Line 13: | ||
The model will probably change as the Qt Project and its community develop. | The model will probably change as the Qt Project and its community develop. | ||
==Objectives== | == Objectives == | ||
The main objectives of the Governance Model are to: | The main objectives of the Governance Model are to: | ||
| Line 20: | Line 22: | ||
The five levels of involvement: Users, Contributors, Approvers, Maintainers and Chief Maintainer are described below. | The five levels of involvement: Users, Contributors, Approvers, Maintainers and Chief Maintainer are described below. | ||
===Users=== | === 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. | 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. | ||
| Line 28: | Line 30: | ||
* Evangelizing about the Project (e.g. a link on a website and word-of-mouth awareness raising) | * 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 | * Giving the community feedback from a User perspective, and being courteous and constructive when doing so | ||
* Providing moral support (a | * 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. | 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 === | ||
Contributors are community members who provide significant input to the Project. Anyone can be a Contributor – there is no selection process. | Contributors are community members who provide significant input to the Project. Anyone can be a Contributor – there is no selection process. | ||
| Line 38: | Line 40: | ||
In addition to User inputs, Contributors might support the Project in many ways including: | In addition to User inputs, Contributors might support the Project in many ways including: | ||
* | * "Suggesting future developments":https://bugreports.qt.io | ||
* [[ReportingBugsInQt|Reporting bugs in Qt]] | * [[ReportingBugsInQt|Reporting bugs in Qt]] | ||
* Triaging bugs | * Triaging bugs | ||
* Fixing bugs | * Fixing bugs | ||
* Programming (writing code, new tests, etc.) | * Programming (writing code, new tests, etc.) | ||
* Commenting on others’ code in the review tool | * Commenting on others’ code in the review tool | ||
* [[ | * [[Writing Qt Documentation]] | ||
* Participating in the release process | * Participating in the release process | ||
* Providing graphics and web design | * Providing graphics and web design | ||
* Organizing conferences | * Organizing conferences | ||
* Doing community work (active on | * Doing community work (active on "mailing lists":http://lists.qt.io, forums, IRC and at events) | ||
* Supporting and coaching new Users | * Supporting and coaching new Users | ||
* [[Improve-Qt-Contribution-Process|Improving the Qt contribution process]] | * [[Improve-Qt-Contribution-Process|Improving the Qt contribution process]] | ||
Contributors engage with the Project through tools like the issue tracker, code review tool, | 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 | 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. | 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. | ||
| Line 62: | Line 64: | ||
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. | 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 === | ||
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 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 review all code contributions and decide which are accepted based on “technical fit” and “spirit fit” with the Project. The [[Commit_Policy|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. | 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==== | ==== How to become an Approver ==== | ||
A Contributor can be nominated as an Approver by an | 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. | 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. | ||
| Line 80: | Line 82: | ||
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. | 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 === | ||
Maintainers are recognized leaders in their area, and have been identified as [[Maintainers|owners of a component]] of the Project code. | Maintainers are recognized leaders in their area, and have been identified as [[Maintainers|owners of a component]] of the Project code. | ||
| Line 90: | Line 92: | ||
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. | 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==== | ==== 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. | 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. | ||
| Line 96: | Line 98: | ||
A Maintainer may also nominate a new Maintainer to take ownership of a subset of his / her component. | 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 | 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. | 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. | ||
| Line 106: | Line 108: | ||
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. | 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=== | === Chief Maintainer === | ||
The Chief Maintainer leads the Maintainer group, coordinating and facilitating its activities. | The Chief Maintainer leads the Maintainer group, coordinating and facilitating its activities. | ||
| Line 116: | Line 118: | ||
The Chief Maintainer will also oversee contributions from a strategic and roadmap perspective. | The Chief Maintainer will also oversee contributions from a strategic and roadmap perspective. | ||
====How to become Chief Maintainer==== | ==== 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. | 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. | ||
| Line 122: | Line 124: | ||
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. | 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== | == 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. | 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. | ||
| Line 128: | Line 130: | ||
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. | 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== | == 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. | 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. | ||
| Line 134: | Line 136: | ||
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. | 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=== | === Lazy consensus === | ||
Decision-making typically involves the following steps: | Decision-making typically involves the following steps: | ||
| Line 155: | Line 157: | ||
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. | 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== | == 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. | |||
Revision as of 14:23, 23 February 2015
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:
- "Suggesting future developments":https://bugreports.qt.io
- Reporting bugs in Qt
- Triaging bugs
- Fixing bugs
- Programming (writing code, new tests, etc.)
- Commenting on others’ code in the review tool
- Writing Qt Documentation
- Participating in the release process
- Providing graphics and web design
- Organizing conferences
- Doing community work (active on "mailing lists":http://lists.qt.io, forums, 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 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:
- 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 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.