[Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 20:02:54 André Pönitz <apoenitz at t-online.de> wrote:

> On Mon, Nov 21, 2016 at 11:06:52AM +0000, Edward Welbourne wrote:
>> Giuseppe D'Angelo:
>> >> I would also like to point out that, despite we have a repository, we
>> >> still don't have a tool for properly discussing the actual content of
>> >> QUIPs.
>> >>
>> >> * Gerrit does not work because comments cannot be threaded, they
>> >>   don't stick to multiple reviews, and they can be ignored
>> >> * Email does not work (it may work for the overall direction, but not
>> >>   for the in depth discussion) because a single message may cover
>> >>   multiple discussion points, disrupting the threading, and
>> >>   discussion points can get ignored (*)
>> 
>> All of which plays into my desire to introduce you all to Critic [0]
>
> Guys,
>
> the idea of QUIPs was to *fix* a problem, namely the current inability
> to pinpoint results of mailing list discussion. This *is* a problem for
> the Project, as lazy consensus on the mailing list is *the* official
> decision making process in the Qt Governance model, but it works in
> practice rather accidentally, if at all.
>
> Discussions are observed to deteriorate, develop into completely
> unrelated discussions, and even if something appears like consensus or
> the discussion dies, it typically turns out that different people think
> differently about what the consensus actually was, and the discussion
> re-starts half a year later.
>
> You both nicely demonstrate that this problem exist, thank you for that,
> but beyond that this particular sub-discussion misses the point.
> QUIPs were not meant to require new or different tooling, and I still
> believe such will be needed.
>
> The rough idea is that a topic is presented as usual on the mailing
> list, and when someone, usually the original proponent, gets the feeling
> that the usual rounds of bike-shedding, trolling and name-calling is
> over, and the occasional sensible arguments all have been heard, writes
> up what appears like a potential consensus and puts that on Gerrit,
> where some review process commences.
>
> The only difference to a normal review process I'd like to see would be
> a *much* higher bar for approval, to ensure that QUIPs are really close
> to consensus and to ensure some consistency within the set of QUIPs.
>
> None of this requires new tools, certainly not the bootstrapping of
> the first QUIP. There's also nothing changing processes, so everybody
> will be free to continue to present his views on his favourite tools
> in the future, but for now I'd really like to get this here done.
>
> IMNSHO it boils down to the question: Does anybody have any fundamental
> problem with main idea of having documents summarizing the lazy consensus
> of certain mailing list discussions? If not I'd call that a lazy
> consensus and would ask to proceed with reviewing the final wording
> on Gerrit.
>

I think it's modeled after Python PEP and RFCs? Do we have a first QUIP who is describing the process? 

I think we should copy a successful model like https://www.python.org/dev/peps/pep-0001/ and don't try to be smarter.

And yes, I don't think document a random email conversation is the answer. 

> Andre' 
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development