1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
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.
|
