Hi all,

Here are my notes from the QUIPs session. Thank you for your patience. :-)

QUIPs are a proposed design process for Qt, modeled after Python’s PEPs.

QUIP 1 introduces the general concept:

  http://quips-qt-io.herokuapp.com/quip-0001.html

QUIP 2 details the Qt governance model, it’s simply the current wiki page
converted into a QUIP:

  http://quips-qt-io.herokuapp.com/quip-0002.html

QUIP 3 is an informational QUIP containing the session notes, which are
repeated below:

  http://quips-qt-io.herokuapp.com/quip-0003.html

The heroku domain is obviously a placeholder.

I have also attached the source files for proposed QUIPs 1, 2, and 3 to this 
e-mail.

One item left open was licensing of the QUIPs themselves. For these I propose
Creative Commons CC0.

Any and all feedback welcome.

Cheers,
Louai

---------------- BEGIN NOTES ----------------

At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the
idea of introducing QUIPs as a new process for Qt governance.

The general idea was introduced by looking at QUIPs 1 and 2, and by looking at
some Python PEPs. The general feedback was positive. An attempt was made to
identify the minimum set of work required to bootstrap QUIP, which was the main
theme of the session.

The overall discussion is summarized below, in roughly chronological order.

- Discussed background of QUIP, the process and the documents. Referred to
  Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the
  session.

  - The idea is to have a new git repository with the QUIP text files

  - Managed through Qt's normal work flow, currently gerrit code review

  - The maintainer of the quips repository takes on required editorial duties
- Agreed that the text documents should be limited to 80 character lines.

- Agreed that care must be taken to ensure that QUIPs are written in "proper"
  English so as to be clear, understandable and concise.

- Talked about how a new QUIP is introduced. The most important thing is to
  reserve a number, which is the identifier of any one QUIP. The title can
  change, and is expected to do so from time to time.

- New QUIP documents will go through a review process like any other patch to
  Qt. The author of the QUIP is responsible for logging this discussion in the
  evolving QUIP itself.

- The important thing is to bootstrap the process. Once it is bootstrapped, it
  is possible to fine-tune the QUIP process through QUIPs. It is expected that
  this will happen.

- The question of what goes into a QUIP was discussed. QUIP 1 gives a rough
  overview of the different kinds of possible QUIPs. It is expected that the
  content be further specified in revisions of QUIP 1 or in follow-up QUIPs.

- Like any other part of Qt, QUIPs are living documents. They can be updated,
  amended or entirely superseded by later ones.

- QUIP licensing was discussed. Python's PEPs are required to be either placed
  in the public domain or licensed under the Open Publication License. The
  former is not possible in all jurisdictions and the latter has apparently
  been superseded by the Creative Commons licenses the CC0 license was
  suggested.

- The minimum QUIP boostrapping process was discussed:

  1. Post QUIP 1 to qt-development mailing list for discussion.

  2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io
     has since been made available)

  3. Create new git repository to hold QUIPs

- The initial QUIP process was discussed:

  1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through
     gerrit

  2. The author gives notice of new QUIP by sending it to qt-development,
     either inline or as a text attachment (things like this can be refined
     later through QUIPs)

  3. Concurrently the author pushes the draft to gerrit where further
     discussion can take place. This discussion must be described in the QUIP.

  4. Decisions are achieved through the same lazy consensus mechanism that
     is in place today. In that respect nothing changes.

  5. A final +2 from the QUIP maintainer(s) is required. This differs slightly
     from other parts of Qt as only the maintainer(s) can +2 changes to this
     repository.

- Louai naively volunteered to convert existing material on the wiki into a
  series of QUIPs.

- There was a question whether community guidelines could be described in a
  QUIP. The answer is a resounding yes.

- The QUIP lifecycle was discussed. The following two items were explored:

  1. Superseding QUIPs. These are QUIPs that both change some mechanism
     described in an earlier QUIP and change the content of that QUIP
     substantially. For small changes existing QUIPs can be updated.

  2. Retroactive QUIPs are possible. That is to say, QUIPs can be written
     to describe a change that occured in the past. For instance, an
     Implementation Track QUIP can be written after something has been added.


QUIP: 1
Title: QUIP Purpose and Guidelines
Version: $Revision$
Last-Modified: $Date$
Author: Louai Al-Khanji,
        Andrew Knight,
        André Pönitz,
        Kai Köhne
Status: Active
Type: Process
Created: 2016-09-02


What is a QUIP?
===============

QUIP stands for Qt's Utilitarian Improvement Process and for Qt User-Submitted
Improvement Proposal. QUIP is the Qt Project's community design process, while
a QUIP is a design document providing information to the Qt community, or
describing a new feature for Qt or its processes or environment. A QUIP should
provide a concise technical specification of the feature and a rationale for
the feature.

If this preamble seems familiar to you, then you are probably familiar with
the PEP documents maintained by the Python community. Thanks, Python!

We intend QUIPs to be the primary mechanism for proposing major new features,
for collecting community input on an issue, and for documenting design
decisions that have gone into Qt. The QUIP author is responsible for building
consensus within the community and documenting dissenting opinions.

Because QUIPs are maintained as text files in a versioned repository, their
revision history is the historical record of the feature proposal [1]_.


QUIP Types
==========

There are three kinds of QUIPs:

1. An **Implementation Track** QUIP describes a new feature, module or
implementation for Qt. QUIPs describing API changes are also Implementation
Track QUIPs.

2. An **Informational** QUIP describes a Qt design issue, or provides general
guidelines to the Qt community, but does not propose a new feature.
Informational QUIPs do not necessarily represent a Qt community consensus, so
users and contributors are free to ignore Informational QUIPs or follow their
advice.

3. A **Process** QUIP describes a process surrounding Qt, or proposes a change
to (or an event in) a process. Process QUIPs are like Implementation Track
QUIPs but apply to areas other than the Qt framework itself. They may propose
an implementation, but not to Qt's codebase; they often require community
consensus; unlike Informational QUIPs, they are more than recommendations, and
users are typically not free to ignore them. Examples include procedures,
guidelines, changes to the decision-making process, and changes to the tools
or environment used in Qt development. Any meta-QUIP is also considered a
Process QUIP, as is any QUIP documenting the deprecation of a Qt module.


QUIP Formats and Templates
==========================

QUIPs are UTF-8 encoded text files using the reStructuredText_ format.
ReStructuredText_ allows for rich markup that is still quite easy to read, but
also results in good-looking and functional HTML. A script automatically
converts QUIPs to HTML for viewing on the web.


QUIP Header Preamble
====================

Each QUIP must begin with an RFC 822 style header preamble.  The headers must
appear in the following order.  Headers marked with "*" are optional and are
described below.  All other headers are required. ::

    QUIP: <quip number>
    Title: <quip title>
    Version: <version string>
    Last-Modified: <date string>
    Author: <list of authors' real names and optionally, email addrs>
    Status: <Draft | Active | Accepted | Deferred | Rejected |
             Withdrawn | Final | Superseded>
    Type: <Implementation Track | Informational | Process>
  * Qt-Version: <version number>
  * Content-Type: text/x-rst
  * Requires: <quip numbers>
    Created: <date created on, in yyyy-mm-dd format>
    Post-History: <dates of postings to qt-development>
  * Replaces: <quip number>
  * Superseded-By: <quip number>
  * Resolution: <url>

The Author header lists the names, and optionally the email addresses of all
the authors/owners of the QUIP.  The format of the Author header value must be

    Random J. User <addr...@dom.ain>

if the email address is included, and just

    Random J. User

if the address is not given.

If there are multiple authors, each should be on a separate line following RFC
2822 continuation line conventions.  Note that personal email addresses in PEPs
will be obscured as a defense against spam harvesters.

The Type header specifies the type of QUIP: Implementation Track,
Informational, or Process.

The format of a QUIP is specified with a Content-Type header. The only
acceptable, and default, value is "text/x-rst" for reStructuredText.

The Created header records the date that the QUIP was assigned a number, while
Post-History is used to record the dates of when new versions of the QUIP are
posted to qt-development. Both headers should be in yyyy-mm-dd
format, e.g. 2016-09-02.

Implementation Track QUIPs will typically have a Qt-Version header which
indicates the version of Qt that the feature will be released with.
Informational and Process QUIPs do not need a Qt-Version header.

QUIPs may have a Requires header, indicating the QUIP numbers that this
QUIP depends on.

QUIPs may also have a Superseded-By header indicating that a QUIP has
been rendered obsolete by a later document; the value is the number of
the QUIP that replaces the current document.  The newer QUIP must have a
Replaces header containing the number of the QUIP that it rendered
obsolete.


Auxiliary Files
===============

QUIPs may include auxiliary files such as diagrams.  Such files must be
named ``quip-XXXX-Y.ext``, where "XXXX" is the QUIP number, "Y" is a
serial number (starting at 1), and "ext" is replaced by the actual
file extension (e.g. "png").


References and Footnotes
========================

.. [1] This historical record is available by the normal git commands
   for retrieving older revisions, and can also be browsed via HTTP here:
   https://code.qt.io/qt/quips

.. _reStructuredText: http://docutils.sourceforge.net/rst.html
QUIP: 2
Title: The Qt Governance Model
Version: $Revision$
Last-Modified: $Date$
Author: Louai Al-Khanji
Status: Active
Type: Process
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 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
* 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, forums e.g.
  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
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, 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, 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 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.

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 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.
QUIP: 3
Title: "QUIPs for Qt" - QtCon 2016 Session Notes
Version: $Revision$
Last-Modified: $Date$
Author: Louai Al-Khanji
Status: Active
Type: Informational
Created: 2016-09-19


Description
===========

At the Qt Contributors' Summit 2016 in Berlin a session was held to discuss the
idea of introducing QUIPs as a new process for Qt governance.

The general idea was introduced by looking at QUIPs 1 and 2, and by looking at
some Python PEPs. The general feedback was positive. An attempt was made to
identify the minimum set of work required to bootstrap QUIP, which was the main
theme of the session.

The overall discussion is summarized below, in roughly chronological order.

- Discussed background of QUIP, the process and the documents. Referred to
  Python and looked at QUIP 1 and QUIP 2 which had been prepared prior to the
  session.

  - The idea is to have a new git repository with the QUIP text files

  - Managed through Qt's normal work flow, currently gerrit code review

  - The maintainer of the quips repository takes on required editorial duties
- Agreed that the text documents should be limited to 80 character lines.

- Agreed that care must be taken to ensure that QUIPs are written in "proper"
  English so as to be clear, understandable and concise.

- Talked about how a new QUIP is introduced. The most important thing is to
  reserve a number, which is the identifier of any one QUIP. The title can
  change, and is expected to do so from time to time.

- New QUIP documents will go through a review process like any other patch to
  Qt. The author of the QUIP is responsible for logging this discussion in the
  evolving QUIP itself.

- The important thing is to bootstrap the process. Once it is bootstrapped, it
  is possible to fine-tune the QUIP process through QUIPs. It is expected that
  this will happen.

- The question of what goes into a QUIP was discussed. QUIP 1 gives a rough
  overview of the different kinds of possible QUIPs. It is expected that the
  content be further specified in revisions of QUIP 1 or in follow-up QUIPs.

- Like any other part of Qt, QUIPs are living documents. They can be updated,
  amended or entirely superseded by later ones.

- QUIP licensing was discussed. Python's PEPs are required to be either placed
  in the public domain or licensed under the Open Publication License. The
  former is not possible in all jurisdictions and the latter has apparently
  been superseded by the Creative Commons licenses the CC0 license was
  suggested.

- The minimum QUIP boostrapping process was discussed:

  1. Post QUIP 1 to qt-development mailing list for discussion.

  2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io
     has since been made available)

  3. Create new git repository to hold QUIPs

- The initial QUIP process was discussed:

  1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) through
     gerrit

  2. The author gives notice of new QUIP by sending it to qt-development,
     either inline or as a text attachment (things like this can be refined
     later through QUIPs)

  3. Concurrently the author pushes the draft to gerrit where further
     discussion can take place. This discussion must be described in the QUIP.

  4. Decisions are achieved through the same lazy consensus mechanism that
     is in place today. In that respect nothing changes.

  5. A final +2 from the QUIP maintainer(s) is required. This differs slightly
     from other parts of Qt as only the maintainer(s) can +2 changes to this
     repository.

- Louai naively volunteered to convert existing material on the wiki into a
  series of QUIPs.

- There was a question whether community guidelines could be described in a
  QUIP. The answer is a resounding yes.

- The QUIP lifecycle was discussed. The following two items were explored:

  1. Superseding QUIPs. These are QUIPs that both change some mechanism
     described in an earlier QUIP and change the content of that QUIP
     substantially. For small changes existing QUIPs can be updated.

  2. Retroactive QUIPs are possible. That is to say, QUIPs can be written
     to describe a change that occured in the past. For instance, an
     Implementation Track QUIP can be written after something has been added.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to