QUIP 3: "QUIPs for Qt" - QtCon 2016 Session Notes

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

1 files changed, 139 insertions, 0 deletions

diff --git a/quip-0003.txt b/quip-0003.txt
new file mode 100644
index 0000000..bfc92e0
--- /dev/null
+++ b/quip-0003.txt
@@ -0,0 +1,139 @@
+QUIP: 3
+Title: "QUIPs for Qt" - QtCon 2016 Session Notes
+Author: Louai Al-Khanji
+Status: Active
+Type: Informational
+Post-History: http://lists.qt-project.org/pipermail/development/2016-September/027218.html
+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. As 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 finds the next free QUIP number.
+
+  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.
+     If the QUIP is materially changed during review, the mailing list should
+     be notified and given time to respond.
+
+  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 occurred in the past. For instance, an
+     Implementation Track QUIP can be written after something has been added.
+
+Community Reception
+-------------------
+
+Following the session at the contributor's summit, the first three draft QUIPs
+along with a preview of the generated HTML content were sent to the Qt
+development mailing list.
+
+The overall feedback from the larger developer community was positive. There
+was some concern that there would be added bureaucracy for no gain.
+
+In the resulting discussion the topics "Why QUIPs?" and "What a QUIP is not"
+were briefly addressed. The overall view is as follows.
+
+Why QUIPs?
+''''''''''
+
+There appears to be a tentative consensus that the mailing list discussions
+that were the main decision-making channel prior to QUIP often failed to arrive
+at clear conclusions. Often it was unclear when a discussion was over, and what
+the actual outcome was. QUIPs are meant to scratch that itch by documenting the
+result.
+
+What a QUIP is not
+''''''''''''''''''
+
+Responding to concerns of QUIP being bureaucracy for bureaucracy's sake, it was
+discussed that the Qt governance model is not being changed. Instead, QUIP
+documents simply intend to document results of the existing process(es) in one
+place. It is not the intent that QUIP documents will be required for simple bug
+fixes or smaller feature additions. The impact on most Qt developers should be
+fairly minimal, apart from providing one place to look up prior policy
+decisions.