Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Shawn Rutledge]

> On 21 Nov 2016, at 21:11, André Pönitz  wrote:
> 
> QUIPs were not meant to require new or different tooling, and I still
> believe such will be needed.

Me too.

See? we have consensus.  ;-)



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 20:02:54 André Pönitz  wrote:

> On Mon, Nov 21, 2016 at 11:06:52AM +, 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@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Pönitz]

On Mon, Nov 21, 2016 at 03:29:01PM +0300, Konstantin Tokarev wrote:
> 
> 
> 21.11.2016, 15:26, "Giuseppe D'Angelo" :
> > On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
> >  wrote:
> >>>  Any idea to how to actually make this work?
> >>  how about taking the existing processes seriously and exercising social
> >>  pressure on those who think they are above them?
> >
> > May I just say that prefer a tool that mandates a workflow over using
> > political and social pressures, which in the long term hurt the
> > project?
> 
> Well, tools cannot help with social issues, and ignoring review comments is
> more like the latter.

Well, right, and wrong, kind of ;-)

I think tools can help to *prevent* social issues. As example, I think it
easier for people to accept a -1 from the Sanity Bot than to accept
exactly the same comment from a human reviewer, specifically when it
comes to arbitrary choices like prefering American over British spelling
in comments. With the bot I usually just swallow and "fix" the issue,
no matter how insane it appears to me.

Sounds irrational? It is. It is human. 

Andre'

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Pönitz]

On Mon, Nov 21, 2016 at 11:06:52AM +, 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.

Andre' 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 14:29:10 Shawn Rutledge  wrote:

>
>> On 21 Nov 2016, at 12:06, 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
>> 
>> [0] https://github.com/jensl/critic
>> 
>> I would dearly love to replace Gerrit with it - I realise that's hoping
>> for too much - but, for a new repository on which Gerrit isn't adequate,
>> maybe we could consider it …
>
> Maybe it’s worth a try.  But someone has to install it on a server so that we 
> can try it, right?  Is that easy enough?

Yes, some server for evaluation would be nice. 

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Shawn Rutledge]

> On 21 Nov 2016, at 12:06, 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
> 
> [0] https://github.com/jensl/critic
> 
> I would dearly love to replace Gerrit with it - I realise that's hoping
> for too much - but, for a new repository on which Gerrit isn't adequate,
> maybe we could consider it …

Maybe it’s worth a try.  But someone has to install it on a server so that we 
can try it, right?  Is that easy enough?

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 13:51:10 Oswald Buddenhagen  
wrote:

> On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
>> On November 21, 2016 12:58:59 Oswald Buddenhagen  
>> wrote:
>> > how about taking the existing processes seriously and exercising social
>> > pressure on those who think they are above them?
>> 
>> Sorry, not everybody likes to use social pressure (mobbing).
>>
> the thing is that there there is no tooling which is absolutely
> foolproof. people will always come up with creative ways to
> circumvent it, and the only way to deal with that is showing them that
> doing so is not acceptable. it's a bit of a stretch to call that
> mobbing, and i gladly laugh it off when it happens.

But you see that a tool who makes it easy to snippet on some argument is maybe 
more suboptimal than other. It's not about using the perfect tool but using one 
which is better. Ones that sets 'loud'  people at a disadvantage. And it's not 
only the tool,  it's the culture too. A culture which is appreciating new 
arguments and not loves to repeat arguments again and again, especially to hide 
some private agenda. If an argumentation is more about individual agendas and 
less about the common good it is doomed.  Especially if people try to sell the 
first as last. The tool should help to make that transparent but it is only one 
building stone. 

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Mon, Nov 21, 2016 at 01:37:50PM +0100, Marco Bubke wrote:
> On November 21, 2016 12:58:59 Oswald Buddenhagen  
> wrote:
> > how about taking the existing processes seriously and exercising social
> > pressure on those who think they are above them?
> 
> Sorry, not everybody likes to use social pressure (mobbing).
>
the thing is that there there is no tooling which is absolutely
foolproof. people will always come up with creative ways to
circumvent it, and the only way to deal with that is showing them that
doing so is not acceptable. it's a bit of a stretch to call that
mobbing, and i gladly laugh it off when it happens.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 21, 2016 12:58:59 Oswald Buddenhagen  
wrote:

> On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote:
>> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen 
>>  wrote:
>> > the repository has been created.
>> 
>> 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,
>>
> when you use inline comments, the locality is good enough to
> make threading generally unnecessary.
>
>> they don't stick to multiple reviews,
>>
> this is true, but becomes a real problem only if the change owner
> doesn't bother handling all comments before pushing new changesets.
>
>> and they can be ignored
>>
> that's correct, and having real issue tracking would be advantageous
> (which gerrit upstream knows very well).
> otoh, it's the responsibility of the reviewers and the submitter (a role
> we have intentionally restricted in this repo, mind you) to verify that
> all comments have been (actually) acted upon.
>
>> Any idea to how to actually make this work?
>> 
> how about taking the existing processes seriously and exercising social
> pressure on those who think they are above them?

Sorry, not everybody likes to use social pressure (mobbing). And could it be 
that the outcome of the argumentation is be quite different of what we would 
describe as good in the long run. My impression is generally that many smart 
people don't like too spend their time for that games. But people who thinks 
that their arguments are smarter think that they deserve to be chosen. 

Or let our describe it that way,  the rationality of people is quite limited 
and you need a good framework to get a better outcome. You can easily derail 
cooperation with a dysfunctional framework. Is shown in many experiments and 
believe me, we are not different. Actually people who working in IT have more 
trouble because they often describe the world  not as contingent but as based 
on a all-time, universal fundament (truth). So it's hard to compromise because 
that would be deviate from truth. If the discussion is based on experience it 
is actually quite positive to compromise because all arguments together give a 
bigger picture, based on much more experience. 

So the truth based world description leds to few 'specialists' discuss that 
matter but the latter is a cooperation of all people with experience about that 
matter. Neither is guaranteed to succeed but if you get the last in a 
cooperative mode you have a good chance. 

> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Konstantin Tokarev]

21.11.2016, 15:26, "Giuseppe D'Angelo" :
> On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
>  wrote:
>>>  Any idea to how to actually make this work?
>>  how about taking the existing processes seriously and exercising social
>>  pressure on those who think they are above them?
>
> May I just say that prefer a tool that mandates a workflow over using
> political and social pressures, which in the long term hurt the
> project?

Well, tools cannot help with social issues, and ignoring review comments is
more like the latter.

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Giuseppe D'Angelo]

On Mon, Nov 21, 2016 at 12:58 PM, Oswald Buddenhagen
 wrote:
>> Any idea to how to actually make this work?
>>
> how about taking the existing processes seriously and exercising social
> pressure on those who think they are above them?

May I just say that prefer a tool that mandates a workflow over using
political and social pressures, which in the long term hurt  the
project?

Cheers,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Sun, Nov 20, 2016 at 08:38:50PM +0100, Giuseppe D'Angelo wrote:
> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen 
>  wrote:
> > the repository has been created.
> 
> 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,
>
when you use inline comments, the locality is good enough to
make threading generally unnecessary.

> they don't stick to multiple reviews,
>
this is true, but becomes a real problem only if the change owner
doesn't bother handling all comments before pushing new changesets.

> and they can be ignored
>
that's correct, and having real issue tracking would be advantageous
(which gerrit upstream knows very well).
otoh, it's the responsibility of the reviewers and the submitter (a role
we have intentionally restricted in this repo, mind you) to verify that
all comments have been (actually) acted upon.

> Any idea to how to actually make this work?
> 
how about taking the existing processes seriously and exercising social
pressure on those who think they are above them?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

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], a
code-review tool my former colleague Jens wrote at Opera.  It knows how
to carry comments forward from one patch set to another, even through
rebases (within limits), it knows the range of lines a comment relates
to, it distinguishes issues (which must be resolved) from comments
(which can be discussed).  Discussions on a particular issue are linear
- i.e. forking off side-threads to separately discuss different parts of
a comment or follow-up would need to be implemented.  It handles whole
branches, making it possible to review a set of related changes
together; the reviewer can chose whether to review all changes to a file
together or each commit's changes separately; it helps keep track of
what you have reviewed so that you can tell when you're done.

[0] https://github.com/jensl/critic

I would dearly love to replace Gerrit with it - I realise that's hoping
for too much - but, for a new repository on which Gerrit isn't adequate,
maybe we could consider it ...

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marc Mutz]

On Sunday 20 November 2016 20:29:01 Giuseppe D'Angelo wrote:
> On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira
> 
>  wrote:
> > Can you remember the list of C++11 features we're allowed to use? We had
> > a discussion on the mailing list.
> 
> Going back to this particular point: so should this list go into the
> QUIPs repository, or in qtbase? (The idea of putting it in qtbase was
> to re-use the same branching scheme, so for a given branch you can
> know which features you are allowed to use).

IMHO, we need a QUIP that says where in each Qt module such a file should be 
located, what its format is, what the process is to update it, whether it 
should be machine-readable (read: run from configure checks), etc.

Neither the wiki, nor the QUIP itself is the place to put the actual lists.

Thanks,
Marc

-- 
Marc Mutz  | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Giuseppe D'Angelo]

On Sun, Nov 20, 2016 at 9:13 PM, Marco Bubke  wrote:
> Do you think about a wiki where you can comment? I think you want something 
> with the capability to describe, comment,  argument and poll with a version 
> history. Like you described email is a terrible tool for it.

If a wiki allows for all of this, then sure, let's use a wiki. Does
MediaWiki support these features? I've got the impression that
discussion pages are totally independent from the "main" page. The
threading must be somehow manually managed and I don't think there's a
way to mark some argumentative point as "this requires a resolution".

(Maybe the right tool does not exist, but we'll need to settle for
using an existing one "in the right way")

Cheers,

-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Marco Bubke]

On November 20, 2016 20:39:08 Giuseppe D'Angelo  wrote:

> On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen
>  wrote:
>> the repository has been created.
>
> 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 (*)
>
> Any idea to how to actually make this work? Try reviewboard maybe?
>
> My 2 cents,
> -- 
> Giuseppe D'Angelo
>
>
> (*) This still happens all the time. User A proposes something; user B
> replies with "I don't think it works in scenarios X, Y, Z"; user A
> counter-replies "but Z is not a scenario we consider" and the
> discussion derails about Z. Noone talks about X and Y, which instead
> *must* be talked about, for the proposal to be accepted. We need
> something that makes it impossible to ignore the comment about X and
> Y.

Do you think about a wiki where you can comment? I think you want something 
with the capability to describe, comment,  argument and poll with a version 
history. Like you described email is a terrible tool for it. 


> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Giuseppe D'Angelo]

On Thu, Nov 10, 2016 at 12:29 PM, Oswald Buddenhagen
 wrote:
> the repository has been created.

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 (*)

Any idea to how to actually make this work? Try reviewboard maybe?

My 2 cents,
-- 
Giuseppe D'Angelo


(*) This still happens all the time. User A proposes something; user B
replies with "I don't think it works in scenarios X, Y, Z"; user A
counter-replies "but Z is not a scenario we consider" and the
discussion derails about Z. Noone talks about X and Y, which instead
*must* be talked about, for the proposal to be accepted. We need
something that makes it impossible to ignore the comment about X and
Y.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Giuseppe D'Angelo]

On Tue, Sep 20, 2016 at 9:27 AM, Thiago Macieira
 wrote:
>
> Can you remember the list of C++11 features we're allowed to use? We had a
> discussion on the mailing list.

Going back to this particular point: so should this list go into the
QUIPs repository, or in qtbase? (The idea of putting it in qtbase was
to re-use the same branching scheme, so for a given branch you can
know which features you are allowed to use).

Thanks,
-- 
Giuseppe D'Angelo
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

On 10/11/16 14:21, "Development on behalf of Jędrzej Nowacki" 
 wrote:

On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote:
> the easiest would be going with the normal approval rights, but limit
> the submit button to a "QUIP owners" group which would consist of lars
> (and possibly a _few_ deputies).

Considering expected traffic there it could be only Lars :-)

Let's do it that way for now. We can always nominate additional QUIP owners 
later on if we think it's required.

Cheers,
Lars

 

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Jędrzej Nowacki]

On torsdag 10. november 2016 12.29.12 CET Oswald Buddenhagen wrote:
> the easiest would be going with the normal approval rights, but limit
> the submit button to a "QUIP owners" group which would consist of lars
> (and possibly a _few_ deputies).

Considering expected traffic there it could be only Lars :-)

Cheers,
 Jędrek
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Wed, Nov 09, 2016 at 06:49:08PM +, Edward Welbourne wrote:
> > Agree with meta/quips
> 
> +1,
> 
the repository has been created.

next point: permissions.
i don't think the regular ones are appropriate - they are way too
anarchic for a process that is supposed to reflect *actual* community
consensus.
the easiest would be going with the normal approval rights, but limit
the submit button to a "QUIP owners" group which would consist of lars
(and possibly a _few_ deputies).
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

> Agree with meta/quips

+1,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Jake Petroules]

Agree with meta/quips

> On Nov 9, 2016, at 10:11 AM, Louai Al-Khanji <louai.al-kha...@qt.io> wrote:
> 
> As far as I am concerned meta/quips will do just fine. It’s not worth a 
> bikeshed.
> 
> Cheers,
> Louai
> 
> On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" 
> <development-bounces+louai.al-khanji=qt...@qt-project.org on behalf of 
> kai.koe...@qt.io> wrote:
> 
> 
> 
>> -Original Message-
>> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
>> project.org] On Behalf Of Oswald Buddenhagen
>> Sent: Wednesday, November 09, 2016 4:01 PM
>> To: development@qt-project.org
>> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
>> 
>> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
>>> +1 for qt/quips, I don't think of it as a web site thing either.
>>> 
>> well, i don't want it in qt/ - this is not a generic namespace for stuff that
>> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git
>> (with an accurate status field), or be a submodule of an aggregated module.
>> 
>> i can offer meta/ as an alternative.
> 
>meta/quips would work for me, too. or qt-project/quips?
> 
>> or maybe qtqt/ - that one already exists, but i suspect the objections will 
>> be
>> the same as to www/.
> 
>No idea what qtqt/ should stand for :)
> 
>>> Kai Koehne wrote:
>>>> I'd slightly prefer
>>>> 
>>>> qt/quips
>>>> 
>>>> because it's not directly related to the website, even if we'll
>>>> generate an html presentation out of it. We might even consider
>>>> adding it to qt/qt5.git at one point ...
>>> 
>> that makes no sense to me at all. the scope if this is certainly wider than 
>> the
>> qt product itself.
> 
>Why do you think so? This is the repository where we want to document 
> processes
>and design decisions for Qt, the project _and_ the product. It's surely 
> more meta than
>most of the modules, but we've also projects like qt/qtqa and 
> qt/qtrepotools, which 
>do not contain a qt module, either. 
> 
>Regards
> 
>Kai
>___
>Development mailing list
>Development@qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules - jake.petrou...@qt.io
The Qt Company - Silicon Valley
Qbs build tool evangelist - qbs.io

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Louai Al-Khanji]

As far as I am concerned meta/quips will do just fine. It’s not worth a 
bikeshed.

Cheers,
Louai

On 11/9/16, 7:11 AM, "Development on behalf of Kai Koehne" 
<development-bounces+louai.al-khanji=qt...@qt-project.org on behalf of 
kai.koe...@qt.io> wrote:



> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, November 09, 2016 4:01 PM
> To: development@qt-project.org
    > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
> > +1 for qt/quips, I don't think of it as a web site thing either.
> >
> well, i don't want it in qt/ - this is not a generic namespace for stuff 
that
> doesn't fit elsewhere. everything in there *should* be aggregated by 
qt5.git
> (with an accurate status field), or be a submodule of an aggregated 
module.
> 
> i can offer meta/ as an alternative.

meta/quips would work for me, too. or qt-project/quips?

> or maybe qtqt/ - that one already exists, but i suspect the objections 
will be
> the same as to www/.

No idea what qtqt/ should stand for :)

> > Kai Koehne wrote:
> > > I'd slightly prefer
> > >
> > > qt/quips
> > >
> > > because it's not directly related to the website, even if we'll
> > > generate an html presentation out of it. We might even consider
> > > adding it to qt/qt5.git at one point ...
> >
> that makes no sense to me at all. the scope if this is certainly wider 
than the
> qt product itself.

Why do you think so? This is the repository where we want to document 
processes
and design decisions for Qt, the project _and_ the product. It's surely 
more meta than
most of the modules, but we've also projects like qt/qtqa and 
qt/qtrepotools, which 
do not contain a qt module, either. 

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Wednesday, November 09, 2016 4:01 PM
> To: development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
> > +1 for qt/quips, I don't think of it as a web site thing either.
> >
> well, i don't want it in qt/ - this is not a generic namespace for stuff that
> doesn't fit elsewhere. everything in there *should* be aggregated by qt5.git
> (with an accurate status field), or be a submodule of an aggregated module.
> 
> i can offer meta/ as an alternative.

meta/quips would work for me, too. or qt-project/quips?

> or maybe qtqt/ - that one already exists, but i suspect the objections will be
> the same as to www/.

No idea what qtqt/ should stand for :)

> > Kai Koehne wrote:
> > > I'd slightly prefer
> > >
> > > qt/quips
> > >
> > > because it's not directly related to the website, even if we'll
> > > generate an html presentation out of it. We might even consider
> > > adding it to qt/qt5.git at one point ...
> >
> that makes no sense to me at all. the scope if this is certainly wider than 
> the
> qt product itself.

Why do you think so? This is the repository where we want to document processes
and design decisions for Qt, the project _and_ the product. It's surely more 
meta than
most of the modules, but we've also projects like qt/qtqa and qt/qtrepotools, 
which 
do not contain a qt module, either. 

Regards

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Andrew Knight]

On 11/09/16 16:01, Oswald Buddenhagen wrote:
>
> i can offer meta/ as an alternative.

+1
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Tue, Nov 08, 2016 at 04:50:00PM +0100, Louai Al-Khanji wrote:
> +1 for qt/quips, I don't think of it as a web site thing either.
> 
well, i don't want it in qt/ - this is not a generic namespace for stuff
that doesn't fit elsewhere. everything in there *should* be aggregated
by qt5.git (with an accurate status field), or be a submodule of an
aggregated module.

i can offer meta/ as an alternative.
or maybe qtqt/ - that one already exists, but i suspect the objections
will be the same as to www/.

> Kai Koehne wrote:
> > I'd slightly prefer
> > 
> > qt/quips
> > 
> > because it's not directly related to the website, even if we'll generate an
> > html presentation out of it. We might even consider adding it to qt/qt5.git 
> > at
> > one point ...
> 
that makes no sense to me at all. the scope if this is certainly wider
than the qt product itself.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Louai Al-Khanji]

+1 for qt/quips, I don't think of it as a web site thing either.

-Louai

_
From: Kai Koehne <kai.koe...@qt.io<mailto:kai.koe...@qt.io>>
Sent: Tuesday, November 8, 2016 3:48 AM
Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
To: Oswald Buddenhagen 
<oswald.buddenha...@qt.io<mailto:oswald.buddenha...@qt.io>>, 
<development@qt-project.org<mailto:development@qt-project.org>>




> -Original Message-
> From: Development 
> [mailto:development-bounces+kai.koehne=qt.io<http://qt.io>@qt-
> project.org<http://project.org>] On Behalf Of Oswald Buddenhagen
> Sent: Tuesday, November 08, 2016 11:15 AM
> To: development@qt-project.org<mailto:development@qt-project.org>
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
>
> On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote:
> > Yes, let's get the repo created and this whole thing off the ground.
> >
> so, anyone has a concrete proposal for a fully qualified repository name?
> www/quips?

I'd slightly prefer

qt/quips

because it's not directly related to the website, even if we'll generate an 
html presentation out of it. We might even consider adding it to qt/qt5.git at 
one point ...

Kai
___
Development mailing list
Development@qt-project.org<mailto:Development@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Kai Koehne]

> -Original Message-
> From: Development [mailto:development-bounces+kai.koehne=qt.io@qt-
> project.org] On Behalf Of Oswald Buddenhagen
> Sent: Tuesday, November 08, 2016 11:15 AM
> To: development@qt-project.org
> Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt
> 
> On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote:
> > Yes, let’s get the repo created and this whole thing off the ground.
> >
> so, anyone has a concrete proposal for a fully qualified repository name?
> www/quips?

I'd slightly prefer

  qt/quips

because it's not directly related to the website, even if we'll generate an 
html presentation out of it. We might even consider adding it to qt/qt5.git at 
one point ...

Kai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Oswald Buddenhagen]

On Tue, Nov 08, 2016 at 09:11:23AM +, Lars Knoll wrote:
> Yes, let’s get the repo created and this whole thing off the ground. 
> 
so, anyone has a concrete proposal for a fully qualified repository
name? www/quips?

> As noted, we need a better way to document results of discussions, decisions 
> and processes. Grepping through a mailing list archive and trying to figure 
> out which opinion prevailed in the end is not that ;-)
> 
> Cheers,
> Lars
> 
> On 08/11/16 09:41, "Development on behalf of Edward Welbourne" 
>  edward.welbou...@qt.io> wrote:
> 
> Louai Al-Khanji said:
> > this is not a bureaucratization process.
> 
> It is about having a way to document the final conclusions of
> discussions we already have.  In the process, it shall also force us to
> be explicit and leave fewer dangling ambiguities, where different
> parties have subtly different interpretations, because the final QUIP
> shall be one document, rather than a scattered mess of correspondence
> spread across several months of a mailing list archive, with references
> back to earlier discussions relating to similar topics.  Newcomers shall
> only have one place to look to get up to speed.
> 
> (I should note, though, that this *is* a bureaucratization process; it's
> just that it's *the good kind* - yes, those do exist.  Bureaucracy may
> have spawned some heinous and easily-noticed messes; but it's actually a
> technology - an information technology, no less - that helped
> revolutionise the way the world was run (roughly a quarter millennium
> ago) and usher in the modern era.)
> 
> I'll third the motion that we should start a repo for QUIPs,
> 
>   Eddy.
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

Yes, let’s get the repo created and this whole thing off the ground. 

As noted, we need a better way to document results of discussions, decisions 
and processes. Grepping through a mailing list archive and trying to figure out 
which opinion prevailed in the end is not that ;-)

Cheers,
Lars

On 08/11/16 09:41, "Development on behalf of Edward Welbourne" 
 wrote:

Louai Al-Khanji said:
> this is not a bureaucratization process.

It is about having a way to document the final conclusions of
discussions we already have.  In the process, it shall also force us to
be explicit and leave fewer dangling ambiguities, where different
parties have subtly different interpretations, because the final QUIP
shall be one document, rather than a scattered mess of correspondence
spread across several months of a mailing list archive, with references
back to earlier discussions relating to similar topics.  Newcomers shall
only have one place to look to get up to speed.

(I should note, though, that this *is* a bureaucratization process; it's
just that it's *the good kind* - yes, those do exist.  Bureaucracy may
have spawned some heinous and easily-noticed messes; but it's actually a
technology - an information technology, no less - that helped
revolutionise the way the world was run (roughly a quarter millennium
ago) and usher in the modern era.)

I'll third the motion that we should start a repo for QUIPs,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

Louai Al-Khanji said:
> this is not a bureaucratization process.

It is about having a way to document the final conclusions of
discussions we already have.  In the process, it shall also force us to
be explicit and leave fewer dangling ambiguities, where different
parties have subtly different interpretations, because the final QUIP
shall be one document, rather than a scattered mess of correspondence
spread across several months of a mailing list archive, with references
back to earlier discussions relating to similar topics.  Newcomers shall
only have one place to look to get up to speed.

(I should note, though, that this *is* a bureaucratization process; it's
just that it's *the good kind* - yes, those do exist.  Bureaucracy may
have spawned some heinous and easily-noticed messes; but it's actually a
technology - an information technology, no less - that helped
revolutionise the way the world was run (roughly a quarter millennium
ago) and usher in the modern era.)

I'll third the motion that we should start a repo for QUIPs,

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Louai Al-Khanji]

Hi,

Indeed, we are. My fault, sorry.

I second the request for a git repository. I have a preliminary set of scripts 
that I used to generate the preview site. Those are ready to go, along with the 
initial QUIPs I sent out. I would like to suggest that we use that to seed the 
repository. There has been interest in writing other QUIPs already, those can 
then follow immediately.

André, to answer your question once more – this is not a bureaucratization 
process. It’s not really about new features either. Instead, the intent is to 
gather in a well-defined and maintained place information that we, the 
community of Qt contributors, have produced. For instance, this could be some 
process that we have agreed upon, or a technical study that was done before 
some large component was refactored, just to give two examples. Currently we 
often have to refer to e-mail conversations which might or might not be 
archived, aren’t discoverable, and are difficult to search for. If we’re lucky 
it’s in a wiki, but looking at the number of wikis that we’ve gone through in 
recent years, and information lost in them, it’s easy to see that it’s not a 
very stable format.

If you don’t feel that any of this applies to you, then you will likely never 
have to think about it. At least, not produce any QUIP yourself – maybe you 
will over time find some of them useful to read, however. Does that address 
your concerns? I would like to fold this question into the next revision of the 
initial QUIPs. :-)

Cheers,
Louai

On 10/26/16, 11:50 PM, "Kai Koehne" <kai.koe...@qt.io> wrote:

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@qt-
> project.org] On Behalf Of Tero Kojo
> Sent: Monday, September 26, 2016 9:01 AM
> To: Louai Al-Khanji <louai.al-kha...@qt.io>; development@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@qt-
> > project.org] On Behalf Of Louai Al-Khanji
> > Sent: tiistai 20. syyskuuta 2016 1.45
> > To: development@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 
> >
> >

Re: [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@qt-
> project.org] On Behalf Of Tero Kojo
> Sent: Monday, September 26, 2016 9:01 AM
> To: Louai Al-Khanji <louai.al-kha...@qt.io>; development@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@qt-
> > project.org] On Behalf Of Louai Al-Khanji
> > Sent: tiistai 20. syyskuuta 2016 1.45
> > To: development@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, 

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Tero Kojo]

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@qt-
> project.org] On Behalf Of Louai Al-Khanji
> Sent: tiistai 20. syyskuuta 2016 1.45
> To: development@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 

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Konstantin Tokarev]

21.09.2016, 12:34, "Friedemann Kleint" :
> Hi,
>
> technically speaking: is using the .rst format set in stone? I find this
> difficult to handle; one needs a local web server to view it AFAIK. .md
> comes to mind as alternative?

Are you implying that you need local web server to view HTML? :)

>
> Regards,
> Friedemann
>
> --
> Friedemann Kleint
> The Qt Company GmbH
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Regards,
Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On quarta-feira, 21 de setembro de 2016 11:34:02 PDT Friedemann Kleint wrote:
> Hi,
> 
> technically speaking: is using the .rst format set in stone? I find this
> difficult to handle; one needs a local web server to view it AFAIK. .md
> comes to mind as alternative?

How is that different from .md? Don't you need a tool that converts it from 
the source format to HTML?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Andrew Knight]

Hi,


On 09/21/16 12:34, Friedemann Kleint wrote:
> Hi,
>
> technically speaking: is using the .rst format set in stone? I find
> this difficult to handle; one needs a local web server to view it
> AFAIK. .md comes to mind as alternative?
>

We discussed this at QtCon and settled on ReStructured Text because it
results in a cleaner plaintext document (i.e. more document-like, less
markup-like) than markdown. It's also the format PIP uses, but note that
it doesn't necessarily matter: each QUIP can declare its MIME type in
the header.

Anyway, I don't think you need a web server to view the formatted RST
result. Docutils has examples on how to convert to HTML using Python:
http://docutils.sourceforge.net/docs/user/tools.html#rst2html-py

--
Andrew
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Friedemann Kleint]

Hi,

technically speaking: is using the .rst format set in stone? I find this 
difficult to handle; one needs a local web server to view it AFAIK. .md 
comes to mind as alternative?


Regards,
Friedemann

--
Friedemann Kleint
The Qt Company GmbH

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 22:30:56 PDT Sergio Ahumada wrote:
> which 5-year-old feature are we missing?

The new UI.

I want to see all comment, in all files, from all reviews, along with the 
review message, in one page.

The new UI also has the ability to comment on multiple lines or sections of a 
line.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Sergio Ahumada]

On 20.09.2016 21:26, Thiago Macieira wrote:

On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?


It may come as a shock to you, but the Gerrit user interface is horrible.
Reviewing discussions after they're done is very difficult, since there's no way
to dump inline comments with the 5-year-old interface we're using (the one
Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in
progress is very difficult.

Email is much easier.



which 5-year-old feature are we missing? --comments?

$ ssh codereview.qt-project.org gerrit query 171459 --patch-sets 
--comments --format JSON | python -c $'import json, sys; 
l=sys.stdin.readline();j=json.loads(l)\nfor i in j["patchSets"]:\n\tif 
"comments" in i: print i["comments"]'


this shows both inline comments in 
https://codereview.qt-project.org/#/c/171459/1/src/plugins/platforms/vnc/qvnc.cpp


--
Sergio Ahumada
sahum...@texla.cl

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Filippo Cucchetto]

I could agree, but basically you're saying that the problem is the
tool and not the idea to discuss
the details on the codereview. At the end a proposal is for sure a
document (thus a sort of source file) and so
gerrit would help matching the discussion with the actual version of
the document (imho this could be
harder by email).
Given that i'm ok in both codereview or email...maybe i'm too biased
by github :)


2016-09-20 21:26 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:
>> Really?
>> Shouldn't be better to just announce a proposal on the mailing list
>> and then shift the discussion and feedbacks
>> on the codereview?
>
> It may come as a shock to you, but the Gerrit user interface is horrible.
> Reviewing discussions after they're done is very difficult, since there's no 
> way
> to dump inline comments with the 5-year-old interface we're using (the one
> Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in
> progress is very difficult.
>
> Email is much easier.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 19:04:07 PDT Filippo Cucchetto wrote:
> Really?
> Shouldn't be better to just announce a proposal on the mailing list
> and then shift the discussion and feedbacks
> on the codereview?

It may come as a shock to you, but the Gerrit user interface is horrible. 
Reviewing discussions after they're done is very difficult, since there's no 
way 
to dump inline comments with the 5-year-old interface we're using (the one 
Gerrit added some time 3 or 4 years ago can do it). Joining a discussion in 
progress is very difficult.

Email is much easier.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

My thinking. I’m fine to have initial discussions on the mailing list, but 
agreeing on and nailing down details will be a lot easier to do on codereview.

Lars

On 20/09/16 19:04, "Development on behalf of Filippo Cucchetto" 
 wrote:

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?

2016-09-20 18:46 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
>> And it formalizes the way we can discuss and comment on things, as QUIPs
>> would be reviewed in codereview, then approved there. I believe it’ll 
lead
>> to a better workflow and better decision making in the project than
>> discussions on the mailing list that often end somewhat inconclusive.
>
> Discussions on content still happen on the mailing list for maximum
> reachability. The discussion on codereview is just the editorial workflow.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development



___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Filippo Cucchetto]

Really?
Shouldn't be better to just announce a proposal on the mailing list
and then shift the discussion and feedbacks
on the codereview?

2016-09-20 18:46 GMT+02:00 Thiago Macieira :
> On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
>> And it formalizes the way we can discuss and comment on things, as QUIPs
>> would be reviewed in codereview, then approved there. I believe it’ll lead
>> to a better workflow and better decision making in the project than
>> discussions on the mailing list that often end somewhat inconclusive.
>
> Discussions on content still happen on the mailing list for maximum
> reachability. The discussion on codereview is just the editorial workflow.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development



-- 
Filippo Cucchetto
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 08:54:05 PDT Lars Knoll wrote:
> And it formalizes the way we can discuss and comment on things, as QUIPs
> would be reviewed in codereview, then approved there. I believe it’ll lead
> to a better workflow and better decision making in the project than
> discussions on the mailing list that often end somewhat inconclusive.

Discussions on content still happen on the mailing list for maximum 
reachability. The discussion on codereview is just the editorial workflow.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Edward Welbourne]

> [*] https://wiki.qt.io/Template:QUIP
> If someone with more Wiki-template-foo could please review this, I'm
> sure it can be improved; in particular, it uses 000{{{1}}} where clearly
> some analogue of formatting {{{1}}} with %03d would be more apt.

Sorry, obviously I meant %04d ...

Eddy.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Lars Knoll]

On 20/09/16 09:27, "Development on behalf of Thiago Macieira" 
 wrote:

On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote:
> So, could you please explain, preferably without relying on all the
> acronyms, what problems this bureaucratization effort is trying to
> resolve, and how it fits the rest of our work flow (like making feature
> requests in Jira)?

Basically, QUIP extends the governance by formalising decisions. The 
governance says decisions are made by consensus and meritocracy on the 
mailing 
list. But once the discussion ends, how do we know what we agreed upon? And 
two years later, how do we find out what we had decided?

Can you remember the list of C++11 features we're allowed to use? We had a 
discussion on the mailing list.

Do you remember why we decided not to have the Standard Library in our ABI? 
That discussion happened in 2012.

The mailing list archives are searchable, but that doesn't mean it's easy 
to 
find what you're looking for.

And it formalizes the way we can discuss and comment on things, as QUIPs would 
be reviewed in codereview, then approved there. I believe it’ll lead to a 
better workflow and better decision making in the project than discussions on 
the mailing list that often end somewhat inconclusive.

Cheers,
Lars


___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[Thiago Macieira]

On terça-feira, 20 de setembro de 2016 09:02:11 PDT André Somers wrote:
> So, could you please explain, preferably without relying on all the
> acronyms, what problems this bureaucratization effort is trying to
> resolve, and how it fits the rest of our work flow (like making feature
> requests in Jira)?

Basically, QUIP extends the governance by formalising decisions. The 
governance says decisions are made by consensus and meritocracy on the mailing 
list. But once the discussion ends, how do we know what we agreed upon? And 
two years later, how do we find out what we had decided?

Can you remember the list of C++11 features we're allowed to use? We had a 
discussion on the mailing list.

Do you remember why we decided not to have the Standard Library in our ABI? 
That discussion happened in 2012.

The mailing list archives are searchable, but that doesn't mean it's easy to 
find what you're looking for.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QCS2016 Session Notes - QUIPs for Qt

[André Somers]

Hi,

Thanks for posting this, it finally cleared up a few postings by Thiago 
from just after the event.


I wrestled my way through this whole thing, trying to get through the 
self-referential nature of all the acronyms. Somewhere in the middle I 
finally found what a QUIP is supposed to be. However, nowhere did I find 
an explanation of what problem it is supposed to solve, why it solves 
it, or how it integrates with the current work flow. So far, it seems to 
me like a solution from some management sphere without a problem to solve.


So, could you please explain, preferably without relying on all the 
acronyms, what problems this bureaucratization effort is trying to 
resolve, and how it fits the rest of our work flow (like making feature 
requests in Jira)?


Thanks,

André

Op 20/09/2016 om 00:45 schreef Louai Al-Khanji:

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