[Development] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

Hi,

I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories.

Anyhow, it seems to me that we're stuck currently in the bootstrapping process
of QUIPs:

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

>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

So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git .

Regards

Kai

> -----Original Message-----
> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt-
> project.org] On Behalf Of Tero Kojo
> Sent: Monday, September 26, 2016 9:01 AM
> To: Louai Al-Khanji <louai.al-khanji at qt.io>; development at qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> Hi,
> 
> This initiative is much appreciated, thank you Louai!
> Having been in the session at QtCon, I don't have any problems with the
> proposed format and process as outlined in the initial QUIPS.
> 
> I'd like to request two QUIP numbers "Qt Community Code of Conduct", and
> another one for "Code of Conduct for Qt Events".
> I guess the repo isn't there yet, do we wait on the lazy agreement process
> until it is created?
>
> Tero
> 
> > -----Original Message-----
> > From: Development [mailto:development-bounces+tero.kojo=qt.io at qt-
> > project.org] On Behalf Of Louai Al-Khanji
> > Sent: tiistai 20. syyskuuta 2016 1.45
> > To: development at qt-project.org
> > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt
> >
> > 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.
> >
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development