date:20181026

-- 
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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 15:39:40 PDT Bernhard Lindner wrote:
> > But the only mailing list with sufficient representation of the community
> > is this one. We don't have to like discussing this, but it seems
> > necessary that we do.
> 
> Well, then let me give you my simple minded opinion on this topic, an
> engineers opinion: Do not introduce a CoC.
> 
> Resisting to have anything and everything in black and white is hard and is
> not popular and surely not zeitgeist but sometimes the better way.

Thanks Bernhard

Your opinion is noted and is no less important than anyone else's.

> Please do not make me discuss about that as well, I prefer to wrangle with
> item delegate code ;)

:-)

-- 
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] QUIP 12: Code of Conduct

2018-10-26 Thread Alexey Andreyev

Thank you for your answers, Thiago!

> If we took your argument to the extreme, then why would we need a
Constitution
> if we have judges?

As I said, I'm not against any CoC by default. I just tried to express that
professional judges is not an excuse to not work on a better constitution.
Not sure it is appropriate analogy though. Is CoC is just a light welcome
recommendations that is not going to be used by CoC board at making
desicions? Or is it definite rules that we need to follow?
If it's light enough in terms of CoC board possible actions, why bother
adding controvertial details about discrimination for example?
It's not clear about the stringency of the document for me and how to use
it for now.

> Do you trust our Security mailing list?

Yes, I do. And I'm going to trust CoC board, but I do not want to
legitimate things that could easily be misused against community members
and against CoC board too

> I would rather we not write a text ourselves, but find something we're
comfortable with. That would be an extreme effort whose resources could be
best used elsewhere.
> If the CC is such a hot topic, a magnet because of its author's actions,
let's look at others.

I agree about reusing some working CoC is good idea. Not sure that there's
one yet.

сб, 27 окт. 2018 г. в 0:35, Thiago Macieira :

> On Friday, 26 October 2018 12:28:42 PDT Alexey Andreyev wrote:
> > > I personally think those situations explain why we need a CoC in the
> >
> > first place and why the judgment on such situations is very subjective,
> > best left to humans, not to a script. And the deliberations should not be
> > in a public forum, like a GitHub issue.
> >
> > If mentioned situations best left to humans, what is current CoC for? If
> > deliberations should be limited, who could have access to it?
>
> The deliberation is left to humans, but the ground rules are written so
> that
> all participants know what is expected of them and to give them the
> reassurance that their grievances will be heard (not that there'll be
> action
> taken).
>
> If we took your argument to the extreme, then why would we need a
> Constitution
> if we have judges?
>
> As for who can have access to it or any other methods of checking their
> power,
> I don't know. Do you trust our Security mailing list? Why wouldn't you
> trust
> the CoC board? How can we add those?
>
> > > Isn't it showing that it's *working*?
> >
> > I guess not, not the current version of the CoC at least. Communities are
> > spending resources instead of working on other tasks. If discussed
> > situations be left to humans in the end with current document, we could
> > just state simple one-liner instead: "be conscious and think about future
> > consequences", -- to minimize CoC problems at least.
> >
> > As I said previously, I agree we should work together on a better
> version.
> > I guess Qt people could do it.
>
> I would rather we not write a text ourselves, but find something we're
> comfortable with. That would be an extreme effort whose resources could be
> best used elsewhere.
>
> If the CC is such a hot topic, a magnet because of its author's actions,
> let's
> look at others.
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

2018-10-26 Thread Bernhard Lindner

> But the only mailing list with sufficient representation of the community is 
> this one. We don't have to like discussing this, but it seems necessary that 
> we do.

Well, then let me give you my simple minded opinion on this topic, an engineers 
opinion:
Do not introduce a CoC.

Resisting to have anything and everything in black and white is hard and is not 
popular
and surely not zeitgeist but sometimes the better way.

Please do not make me discuss about that as well, I prefer to wrangle with item 
delegate
code ;)

-- 
Best regards, 
Bernhard Lindner

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

Re: [Development] QUIP 12: Code of Conduct

On Friday, 26 October 2018 15:02:09 PDT Bernhard Lindner wrote:
> Anyway I think engineering and politics should be separated. On any level.
> Politics is extremly harmful to engineering. CoCs are always political.

You are correct.

But the only mailing list with sufficient representation of the community is 
this one. We don't have to like discussing this, but it seems necessary that 
we do.

-- 
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] QUIP 12: Code of Conduct

2018-10-26 Thread Bernhard Lindner



> > I wish any one discussion about Qt software quality would have attracted so
> > much attention, passion and effort as this CoC topic.
> 
> There are plenty of technical threads that have had more emails sent than 
> this. Look at the ones about the buildsystem, for a recent example.

I didn't say "technical". Also I didn't say "number of e-mails".

Anyway I think engineering and politics should be separated. On any level. 
Politics is
extremly harmful to engineering. CoCs are always political.

-- 
Best Regards, 
Bernhard Lindner

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

Re: [Development] QUIP 12: Code of Conduct

On Friday, 26 October 2018 12:28:42 PDT Alexey Andreyev wrote:
> > I personally think those situations explain why we need a CoC in the
> 
> first place and why the judgment on such situations is very subjective,
> best left to humans, not to a script. And the deliberations should not be
> in a public forum, like a GitHub issue.
> 
> If mentioned situations best left to humans, what is current CoC for? If
> deliberations should be limited, who could have access to it?

The deliberation is left to humans, but the ground rules are written so that 
all participants know what is expected of them and to give them the 
reassurance that their grievances will be heard (not that there'll be action 
taken).

If we took your argument to the extreme, then why would we need a Constitution 
if we have judges?

As for who can have access to it or any other methods of checking their power, 
I don't know. Do you trust our Security mailing list? Why wouldn't you trust 
the CoC board? How can we add those?

> > Isn't it showing that it's *working*?
> 
> I guess not, not the current version of the CoC at least. Communities are
> spending resources instead of working on other tasks. If discussed
> situations be left to humans in the end with current document, we could
> just state simple one-liner instead: "be conscious and think about future
> consequences", -- to minimize CoC problems at least.
> 
> As I said previously, I agree we should work together on a better version.
> I guess Qt people could do it.

I would rather we not write a text ourselves, but find something we're 
comfortable with. That would be an extreme effort whose resources could be 
best used elsewhere.

If the CC is such a hot topic, a magnet because of its author's actions, let's 
look at others.

-- 
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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 12:25:50 PDT Jason H wrote:
> Thiago,
> 
> Here's a link that kinda puts it together:
> https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/
> (Scroll to  "The Controversy" and the "rape apologist" Sage Sharp tweet)

I know of the controversy and find Sage's tweet to be of extremely poor 
judgment, given the situation that originally caused them to find Ted Ts'o an 
apologist. I know both and I fail to see how the actions could have led to 
such an escalation. This is very unfortunate.

I agree with the tweet replies quoted in the article: the Sage's tweet was out 
of bounds and a violation of the CoC. Fortunately, they are not part of the 
kernel community anymore, so the Linux TAB does not have to do anything.

The post says:
"1. Insertion of the CoC into other projects has heralded witch hunts where 
good contributors are removed over trivial matters or even events that 
happened a long time ago."

There's a difference between triggering witch hunts and successful removal of 
contributors. The fact that the CoC and a reporting mechanism exist can lead 
to their being abused. But I stand by my argument that the final decision is 
left to existing, trusted members of the project's community and that stops 
the abuse from getting out of hand.

> I didn't realize this was a thing of "defeat". I have concerns, based on
> actual events, that I want resolved.

That's fine. I was reacting to your "my mind is made up", which it makes you 
sound like you will not change your position and no compromise is possible, 
short of not adopting a CoC at all.

> I do respectfully disagree on whether or not an author is relevant to
> considering a work. In this case the author has a track record of attacking
> members in open source projects and arguing against meritocracy. Is the
> text good? There is a lot I agree with, but there are things in it that
> cross the line for me. I think we can come to an agreement, but not with
> invoking the Covenant in its current form.

Please also note that the attack against meritocracy is more nuanced than it 
appears at first sight. I don't have more information on this -- I will go 
inform myself about it -- so until then I will not comment.

-- 
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] QUIP 12: Code of Conduct

> Let's assume for the sake of the argument that the text was written with
ill-
intent and let's ignore the taint that it would cause us just by adopting
it:
what's the worst that could happen? The interpretation of the CoC is left
to
the community that *is* part of the project, not the text's author.

Very simple.
Once someone like her tries to exploit the vulnerabilities community have
created by adopting this document,
the Qt project will likely shut them down with a simple "no, you are not
being reasonable".

But being unreasonable, this person will immediately blast Qt Community for
not adhering to code of conduct and doubts will arise both inside and
outside.
Depending on how persistent they are, it could become a full blown media
storm tarnishing the community's image.

This could all have been avoided by just not letting those people assume Qt
picked _their_ Code.
And whatever Qt Community thinks, they _will_ assume that it is their code
that has been picked and will hold Qt liable to that.



On Sat, Oct 27, 2018 at 12:13 AM Thiago Macieira 
wrote:

> On Friday, 26 October 2018 11:40:14 PDT NIkolai Marchenko wrote:
> > I have to disagree. As I see it: she has spent considerable amount of
> time
> > drafting the exact text to allow her to bully projects.
> > Have you spent as much time analyzing all of the potential pitfalls she
> may
> > or may not have inserted into this document?
>
> I have read the text assuming it was written and adopted in good faith,
> which
> is also how the people in the Linux kernel's TAB as well as whomever we
> empower in the Qt Project would. That's why the decisions are left to
> humans,
> not a script.
>
> > She's a malicious person and not second guessign her Code is a mistake.
>
> Let's assume for the sake of the argument that the text was written with
> ill-
> intent and let's ignore the taint that it would cause us just by adopting
> it:
> what's the worst that could happen? The interpretation of the CoC is left
> to
> the community that *is* part of the project, not the text's author.
>
> I believe the worst that could happen is an argument on the original
> spirit of
> the text versus our interpretation of it. But the Qt Project makes the
> decision, not the original author, so our opinion of what it is meant to
> say
> has more weight.
>
> So I don't think this is a danger.
>
> > Yes, indeed, is the text good? This has to be analyzed: in depth. And I
> > would still probably avoid using hers.
>
> And personally I'm leaning in favour of KDE's.
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

On Friday, 26 October 2018 11:40:14 PDT NIkolai Marchenko wrote:
> I have to disagree. As I see it: she has spent considerable amount of time
> drafting the exact text to allow her to bully projects.
> Have you spent as much time analyzing all of the potential pitfalls she may
> or may not have inserted into this document?

I have read the text assuming it was written and adopted in good faith, which 
is also how the people in the Linux kernel's TAB as well as whomever we 
empower in the Qt Project would. That's why the decisions are left to humans, 
not a script.

> She's a malicious person and not second guessign her Code is a mistake.

Let's assume for the sake of the argument that the text was written with ill-
intent and let's ignore the taint that it would cause us just by adopting it: 
what's the worst that could happen? The interpretation of the CoC is left to 
the community that *is* part of the project, not the text's author.

I believe the worst that could happen is an argument on the original spirit of 
the text versus our interpretation of it. But the Qt Project makes the 
decision, not the original author, so our opinion of what it is meant to say 
has more weight.

So I don't think this is a danger.

> Yes, indeed, is the text good? This has to be analyzed: in depth. And I
> would still probably avoid using hers.

And personally I'm leaning in favour of KDE's.

-- 
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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 11:39:52 PDT Jason H wrote:
> How do we prevent that scenario, what is essentially a social
> Denial-of-Service (denial of community?) attack? If we adopt a
> Conenant-based language we have to consider this attack vector. It has
> already happened in other projects - it is not a hypothetical.

We prevent this scenario by having sensible people in the CoC Committee, who 
will address the problem appropriately.

And will remind the person posting the complaint of the story of the boy who 
cried "wolf".

-- 
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] qMoveToConst helper for rvalue references to movable Qt containers?

2018-10-26 Thread Elvis Stansvik

Den sön 21 okt. 2018 kl 17:50 skrev Giuseppe D'Angelo
:
>
> Hello,
>
> Il 21/10/18 16:15, Elvis Stansvik ha scritto:
> > I couldn't find a way to contact them.
>
> The best shot would be the std-discussion mailing list, I think.
>
> > In order to try out the unsafe usage you suggested in your other mail,
> > and also another unsafe usage pointed out in an SO question
> > (https://stackoverflow.com/questions/39051460/why-does-as-const-forbid-rvalue-arguments/39051612#39051612),
> > I made the following test program.
> >
> > The output when running is:
> >
> > [estan@newton move-to-const-test]$ ./move-to-const-test
> > without moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627200
> > Foo begin 0x7fffdb627200
> > Foo end 0x7fffdb627200
> > Foo destr 0x7fffdb627200
> > FooPrivate destr
> >
> > with moveToConst:
> > FooPrivate constr from vector
> > Foo constr with arg 0x7fffdb627208
> > Foo move constr 0x7fffdb627210
> > Foo destr 0x7fffdb627208
> > Foo begin const 0x7fffdb627210
> > Foo end const 0x7fffdb627210
> > Foo destr 0x7fffdb627210
> > FooPrivate destr
> > [estan@newton move-to-const-test]$
> >
> > Which just shows it's working as intended.
>
> However the third test should be a without moveToConst, but storing in a
> temporary, i.e. the current best practice. It should output exactly like
> the first one, but of course call const begin/end.

For completely other reasons, I came across "Range-based for
statements with initializer" today:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0614r1.html

With that, the Qt best practice could become

for (const auto list = getQList(); const auto  : list) {
...
}

Which may or may not be pretty, but avoids the extra line of code and
keeps the scope clean.

Elvis

>
> And note the extra move/destruciton in the second example.
>
>
> > The two unsafe usages are commented out, because they wouldn't compile 
> > (good!).
>
>
> Whops, you're absolutely right. My bad. With your proposed implementation:
>
> > template 
> > const T moveToConst(T &)
> > {
> > return std::move(t);
> > }
>
> This won't compile when called on a non-const lvalue (the return type
> will be a lvalue reference to const, which won't bind to a non-const
> rvalue). I stand corrected.
>
> Which actually makes me think of yet another possibility of misuse, that
> is, applying moveToConst to a function returning a const object. That
> will compile, using a copy...
>
> > const QVector getVector();
> > for (auto  : moveToConst(getVector()) ~~~
>
>
> Long story short, I think it's good if we stay away from this in Qt.
> Clazy warns you if you "do it wrong", and being a Qt-specific problem,
> we better not offer too many ways that could have unpleasant drawbacks.
>
>
> My 2 c,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

2018-10-26 Thread Alexey Andreyev

> I personally think those situations explain why we need a CoC in the
first place and why the judgment on such situations is very subjective,
best left to humans, not to a script. And the deliberations should not be
in a public forum, like a GitHub issue.

If mentioned situations best left to humans, what is current CoC for? If
deliberations should be limited, who could have access to it?

> Isn't it showing that it's *working*?

I guess not, not the current version of the CoC at least. Communities are
spending resources instead of working on other tasks. If discussed
situations be left to humans in the end with current document, we could
just state simple one-liner instead: "be conscious and think about future
consequences", -- to minimize CoC problems at least.

As I said previously, I agree we should work together on a better version.
I guess Qt people could do it.

пт, 26 окт. 2018 г. в 21:35, Thiago Macieira :

> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially
> and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that
> it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor
> removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a
> claim
> > of "transphobia" based on a tweet the contributor wrote in no way
> relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
>
> First of all, the kernel adoption of CoC was not a fiasco. All the
> negative
> emails you may have seen came from people who are not contributors, often
> their first and only email to the mailing list. Despite what Eric Raymond
> has
> said, revoking the copyright licence for GPL just cannot be done -- it
> would
> be against GPL's spirit.
>
> Coraline's intentions are irrelevant. What matters is the text: is it good?
>
> But if your mind is made up, kindly refrain from trying to convince others
> to
> change their minds too. This is a two-way street and you're only welcome
> to
> argue your point if you're willing to admit defeat too.
>
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went
> out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become
> political
> > in subsequent years. People's minds also change over time.
>
> What is the kernel example? Who was forced out, or attempted to?
>
> > I urge you to read link[3] below and see if we want that kind of
> attention.
> > It summarizes what happens when the CC has been adopted by other
> projects.
> >
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3]
> https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> I have.
>
> The proponents of the removal were arguing that having such a person as a
> project leader is poisonous to the project, *regardless* of the fact that
> it
> was done in private time, because it would turn away potential new
> contributors as they didn't want to associate with such a person. This is
> an
> extreme situation, indeed, and one that the CoC committee should be able
> to
> make a judgement on: which way is the project best served?
>
> Anyway, given that the request to get the maintainer removed was not
> accepted,
> how is that a failure of the CoC? Isn't it showing that it's *working*?
>
> I personally think those situations explain why we need a CoC in the first
> place and why the judgment on such situations is very subjective, best
> left to
> humans, not to a script. And the deliberations should not be in a public
> forum, like a GitHub issue.
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

Thiago,

Here's a link that kinda puts it together: 
https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/ (Scroll 
to  "The Controversy" and the "rape apologist" Sage Sharp tweet)

I didn't realize this was a thing of "defeat". I have concerns, based on actual 
events, that I want resolved. 

I do respectfully disagree on whether or not an author is relevant to 
considering a work. In this case the author has a track record of attacking 
members in open source projects and arguing against meritocracy. Is the text 
good? There is a lot I agree with, but there are things in it that cross the 
line for me. I think we can come to an agreement, but not with invoking the 
Covenant in its current form. 


> Sent: Friday, October 26, 2018 at 2:35 PM
> From: "Thiago Macieira" 
> To: development@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a claim
> > of "transphobia" based on a tweet the contributor wrote in no way relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
> 
> First of all, the kernel adoption of CoC was not a fiasco. All the negative 
> emails you may have seen came from people who are not contributors, often 
> their first and only email to the mailing list. Despite what Eric Raymond has 
> said, revoking the copyright licence for GPL just cannot be done -- it would 
> be against GPL's spirit.
> 
> Coraline's intentions are irrelevant. What matters is the text: is it good?
> 
> But if your mind is made up, kindly refrain from trying to convince others to 
> change their minds too. This is a two-way street and you're only welcome to 
> argue your point if you're willing to admit defeat too.
> 
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> > 
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become political
> > in subsequent years. People's minds also change over time.
> 
> What is the kernel example? Who was forced out, or attempted to?
> 
> > I urge you to read link[3] below and see if we want that kind of attention.
> > It summarizes what happens when the CC has been adopted by other projects.
> > 
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
> 
> I have.
> 
> The proponents of the removal were arguing that having such a person as a 
> project leader is poisonous to the project, *regardless* of the fact that it 
> was done in private time, because it would turn away potential new 
> contributors as they didn't want to associate with such a person. This is an 
> extreme situation, indeed, and one that the CoC committee should be able to 
> make a judgement on: which way is the project best served?
> 
> Anyway, given that the request to get the maintainer removed was not 
> accepted, 
> how is that a failure of the CoC? Isn't it showing that it's *working*?
> 
> I personally think those situations explain why we need a CoC in the first 
> place and why the judgment on such situations is very subjective, best left 
> to 
> humans, not to a script. And the deliberations should not be in a public 
> forum, like a GitHub issue.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

On Friday, 26 October 2018 10:53:18 PDT Bernhard Lindner wrote:
> I wish any one discussion about Qt software quality would have attracted so
> much attention, passion and effort as this CoC topic.

There are plenty of technical threads that have had more emails sent than 
this. Look at the ones about the buildsystem, for a recent example.

-- 
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] QUIP 12: Code of Conduct

>  Coraline's intentions are irrelevant. What matters is the text: is it
good?

I have to disagree. As I see it: she has spent considerable amount of time
drafting the exact text to allow her to bully projects.
Have you spent as much time analyzing all of the potential pitfalls she may
or may not have inserted into this document?
She's a malicious person and not second guessign her Code is a mistake.

Yes, indeed, is the text good? This has to be analyzed: in depth. And I
would still probably avoid using hers.

On Fri, Oct 26, 2018 at 9:35 PM Thiago Macieira 
wrote:

> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially
> and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that
> it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor
> removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a
> claim
> > of "transphobia" based on a tweet the contributor wrote in no way
> relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
>
> First of all, the kernel adoption of CoC was not a fiasco. All the
> negative
> emails you may have seen came from people who are not contributors, often
> their first and only email to the mailing list. Despite what Eric Raymond
> has
> said, revoking the copyright licence for GPL just cannot be done -- it
> would
> be against GPL's spirit.
>
> Coraline's intentions are irrelevant. What matters is the text: is it good?
>
> But if your mind is made up, kindly refrain from trying to convince others
> to
> change their minds too. This is a two-way street and you're only welcome
> to
> argue your point if you're willing to admit defeat too.
>
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went
> out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become
> political
> > in subsequent years. People's minds also change over time.
>
> What is the kernel example? Who was forced out, or attempted to?
>
> > I urge you to read link[3] below and see if we want that kind of
> attention.
> > It summarizes what happens when the CC has been adopted by other
> projects.
> >
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3]
> https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> I have.
>
> The proponents of the removal were arguing that having such a person as a
> project leader is poisonous to the project, *regardless* of the fact that
> it
> was done in private time, because it would turn away potential new
> contributors as they didn't want to associate with such a person. This is
> an
> extreme situation, indeed, and one that the CoC committee should be able
> to
> make a judgement on: which way is the project best served?
>
> Anyway, given that the request to get the maintainer removed was not
> accepted,
> how is that a failure of the CoC? Isn't it showing that it's *working*?
>
> I personally think those situations explain why we need a CoC in the first
> place and why the judgment on such situations is very subjective, best
> left to
> humans, not to a script. And the deliberations should not be in a public
> forum, like a GitHub issue.
>
> --
> 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
>
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] QUIP 12: Code of Conduct

Putting my "red team" hat on for a moment (not a political color thing - a pen. test thing) this is how it will play out - maybe not for me personally - but someone in the community will express something that some (for lack of a better term) social justice warrior will take offense with to the degree that they are intent on really messing up the poster's life and will dox them and realize they are are a part of this community, and since the community is under the Covenant, can initiate a complaint with the Qt community that the poster, by merely being a member of this community, is harming the community, and seeks/gets the community member removed?

How do we prevent that scenario, what is essentially a social Denial-of-Service (denial of community?) attack? If we adopt a Conenant-based language we have to consider this attack vector. It has already happened in other projects - it is not a hypothetical.

Sent: Friday, October 26, 2018 at 2:17 PM
From: "NIkolai Marchenko"
To: jh...@gmx.com
Cc: "Christian Kandeler" , "Qt development mailing list"
Subject: Re: [Development] QUIP 12: Code of Conduct

And we already see the budding sentiments to that exact tune:

(quote from Edward Welbourne)

>That sometimes folk have felt so intimidated that they give up on trying
> to make a contribution; and that, were potential worse conduct to cause
> distress to a contributor, we have no process in place that could give
> them confidence that their distress will be respected and honest efforts
vwill be made to relieve it. Various variations and permutations on
> these themes may also be relevant; see Simon's mail.

Note: I understand that he means well, but Within the context of Contributor Covenant the punishability of the potential harm of people not contributing can escalate to stupid proportions.

I have nothing against KDE's code. It strives to add positivity.

I am very much against Qt's CoC being drafted from Covenant. Covenant is focused on oppression and excluding ppl.

On Fri, Oct 26, 2018 at 9:06 PM Jason H wrote:

I don't really care that their role, though that move takes gravitas.

I will never endorse a measure that encourages (and the CC does encourage) a witchhunt on the members of the community. It encourages by creating a metric of "maximum comfort" (or "least harmful") and that anything else is somehow a violation. She did it herself with these words[2]: "Is this what the other maintainers want to be reflected in the project? Will any transgender developers feel comfortable contributing?" With those words she created a metric of "maximum comfort". So now the question moves from not just having not offended someone, but to be maximally comforting to every possible person. Not that there's anything wrong with *wanting* to be maximally comfortable for everyone. It's a great goal. But now every interaction is to be judged by this metric, and anything less than the maximal comfort is somehow potentially alienating to a population and can be construed to be a cause for removal.

In the CC itself it encourages a witchhunt with these words:

"Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."

That last word, "harmful" significantly alters the statement. Don't let your eyes glaze over. Now anything that happens is potentially harmful. (Ironically C++, or its constructs is even "considered harmful". Just google "C++ considered harmful", lol). I probably would have let this whole issue slide but that last word _really_ changes the character of the covenant. I beleive that is *the* word that allows the witchhunting. It's not just direct harm but potential harm. From [2]: "As a queer person this sort of argument from a maintainer makes me feel unwelcome. The ignorance which @elia shows by claiming that transfolk are "not accepting reality" is actively harmful. I will not contribute to this project or any other project which @elia maintains." - strand

Not that strand was participating, but states that there will be no future contribution by strand. This is an appeal to percieved harm - that now strand will not ever contribute, the project is potentially harmed by missing out on a contributor. So now this issue can fall under the Covenant.

How can we avoid witchhunts?

Sent: Friday, October 26, 2018 at 1:24 PM
From: "NIkolai Marchenko"
To: jh...@gmx.com
Cc: "Christian Kandeler" , "Qt development mailing list"
Subject: Re: [Development] QUIP 12: Code of Conduct

Just to clarify: she sought to remove _maintainer_ of the project :) At that point the guy was doing most of the work.

Re: [Development] QUIP 12: Code of Conduct

On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> My fundamental problem about the Contributor Covenant[1] was initially and
> solely the fallout from the Linux Kernel fiasco. But then I learned that it
> was drafted by Coraline Ada Ehmke, who sought to have a contributor removed
> [2] from a project preemptively. The contributor did nothing wrong with
> respect to the project or the project's community.  She constructed a claim
> of "transphobia" based on a tweet the contributor wrote in no way relating
> to the project at hand, and slandered the project for not expunging them.
> My mind is made up: the Contributor Covenant is a tool of oppression.

First of all, the kernel adoption of CoC was not a fiasco. All the negative 
emails you may have seen came from people who are not contributors, often 
their first and only email to the mailing list. Despite what Eric Raymond has 
said, revoking the copyright licence for GPL just cannot be done -- it would 
be against GPL's spirit.

Coraline's intentions are irrelevant. What matters is the text: is it good?

But if your mind is made up, kindly refrain from trying to convince others to 
change their minds too. This is a two-way street and you're only welcome to 
argue your point if you're willing to admit defeat too.

> The specific sentence in the Covenant is:
> "This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community."
> 
> However, despite being the author of the Covenant (2014), she found it
> appropriate to attack someone who was clearly not operating in a project
> space or representing the project community (2015). We now have two
> examples - the linux Kernel and Opal project, that after CC was enacted
> that calls for removal of members based on past unrelated tweets went out.
> One of the problems its politics and political climates change over time.
> Expressing what is not political at one point in time may become political
> in subsequent years. People's minds also change over time.

What is the kernel example? Who was forced out, or attempted to?

> I urge you to read link[3] below and see if we want that kind of attention.
> It summarizes what happens when the CC has been adopted by other projects.
> 
> [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> [2] https://github.com/opal/opal/issues/941
> [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

I have.

The proponents of the removal were arguing that having such a person as a 
project leader is poisonous to the project, *regardless* of the fact that it 
was done in private time, because it would turn away potential new 
contributors as they didn't want to associate with such a person. This is an 
extreme situation, indeed, and one that the CoC committee should be able to 
make a judgement on: which way is the project best served?

Anyway, given that the request to get the maintainer removed was not accepted, 
how is that a failure of the CoC? Isn't it showing that it's *working*?

I personally think those situations explain why we need a CoC in the first 
place and why the judgment on such situations is very subjective, best left to 
humans, not to a script. And the deliberations should not be in a public 
forum, like a GitHub issue.

-- 
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] QUIP 12: Code of Conduct

And we already see the budding sentiments to that exact tune:

(quote from Edward Welbourne)
>That sometimes folk have felt so intimidated that they give up on trying
>  to make a contribution; and that, were potential worse conduct to cause
>  distress to a contributor, we have no process in place that could give
>  them confidence that their distress will be respected and honest efforts
vwill be made to relieve it.  Various variations and permutations on
>  these themes may also be relevant; see Simon's mail.

Note: I understand that he means well, but Within the context of
Contributor Covenant the punishability of the potential harm of people not
contributing can escalate to stupid proportions.
I have nothing against KDE's code. It strives to add positivity.
I am very much against Qt's CoC being drafted from Covenant. Covenant is
focused on oppression and excluding ppl.

On Fri, Oct 26, 2018 at 9:06 PM Jason H  wrote:

> I don't really care that their role, though that move takes gravitas.
>
> I will never endorse a measure that encourages (and the CC does
> encourage) a witchhunt on the members of the community. It encourages by
> creating a metric of "maximum comfort" (or "least harmful") and that
> anything else is somehow a violation. She did it herself with these
> words[2]: "Is this what the other maintainers want to be reflected in the
> project? Will any transgender developers feel comfortable contributing?"
> With those words she created a metric of "maximum comfort". So now the
> question moves from not just having not offended someone, but to be
> maximally comforting to every possible person. Not that there's anything
> wrong with *wanting* to be maximally comfortable for everyone. It's a great
> goal. But now every interaction is to be judged by this metric, and
> anything less than the maximal comfort is somehow potentially alienating to
> a population and can be construed to be a cause for removal.
>
> In the CC itself it encourages a witchhunt with these words:
> "Project maintainers have the right and responsibility to remove, edit,
> or reject comments, commits, code, wiki edits, issues, and other
> contributions that are not aligned to this Code of Conduct, or to ban
> temporarily or permanently any contributor for other behaviors that they
> deem inappropriate, threatening, offensive, or harmful."
>
> That last word, "harmful" significantly alters the statement. Don't let
> your eyes glaze over. Now anything that happens is potentially harmful.
> (Ironically C++, or its constructs is even "considered harmful". Just
> google "C++ considered harmful", lol). I probably would have let this whole
> issue slide but that last word _really_ changes the character of the
> covenant. I beleive that is *the* word that allows the witchhunting. It's
> not just direct harm but potential harm. From [2]: "As a queer person
> this sort of argument from a maintainer makes me feel unwelcome. The
> ignorance which @elia  shows by claiming that
> transfolk are "not accepting reality" is actively harmful. I will not
> contribute to this project or any other project which @elia
>  maintains." - strand
>
> Not that strand was participating, but states that there will be no future
> contribution by strand.  This is an appeal to percieved harm - that now
> strand will not ever contribute, the project is potentially harmed by
> missing out on a contributor. So now this issue can fall under the
> Covenant.
>
>
> How can we avoid witchhunts?
>
> *Sent:* Friday, October 26, 2018 at 1:24 PM
> *From:* "NIkolai Marchenko" 
> *To:* jh...@gmx.com
> *Cc:* "Christian Kandeler" , "Qt development
> mailing list" 
> *Subject:* Re: [Development] QUIP 12: Code of Conduct
> Just to clarify: she sought to remove _maintainer_ of the project :) At
> that point the guy was doing most of the work.
>
> On Fri, Oct 26, 2018 at 7:48 PM Jason H  wrote:
>
>> My fundamental problem about the Contributor Covenant[1] was initially
>> and solely the fallout from the Linux Kernel fiasco. But then I learned
>> that it was drafted by Coraline Ada Ehmke, who sought to have a contributor
>> removed [2] from a project preemptively. The contributor did nothing wrong
>> with respect to the project or the project's community.  She constructed a
>> claim of "transphobia" based on a tweet the contributor wrote in no way
>> relating to the project at hand, and slandered the project for not
>> expunging them. My mind is made up: the Contributor Covenant is a tool of
>> oppression.
>>
>> The specific sentence in the Covenant is:
>> "This Code of Conduct applies both within project spaces and in public
>> spaces when an individual is representing the project or its community."
>>
>> However, despite being the author of the Covenant (2014), she found it
>> appropriate to attack someone who was clearly not operating in a project
>> space or representing the project community (2015). We now have two
>>

Re: [Development] QUIP 12: Code of Conduct

I don't really care that their role, though that move takes gravitas.

I will never endorse a measure that encourages (and the CC does encourage) a witchhunt on the members of the community. It encourages by creating a metric of "maximum comfort" (or "least harmful") and that anything else is somehow a violation. She did it herself with these words[2]: "Is this what the other maintainers want to be reflected in the project? Will any transgender developers feel comfortable contributing?" With those words she created a metric of "maximum comfort". So now the question moves from not just having not offended someone, but to be maximally comforting to every possible person. Not that there's anything wrong with *wanting* to be maximally comfortable for everyone. It's a great goal. But now every interaction is to be judged by this metric, and anything less than the maximal comfort is somehow potentially alienating to a population and can be construed to be a cause for removal. 

In the CC itself it encourages a witchhunt with these words:

"Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful."

That last word, "harmful" significantly alters the statement. Don't let your eyes glaze over. Now anything that happens is potentially harmful. (Ironically C++, or its constructs is even "considered harmful". Just google "C++ considered harmful", lol). I probably would have let this whole issue slide but that last word _really_ changes the character of the covenant. I beleive that is *the* word that allows the witchhunting. It's not just direct harm but potential harm. From [2]: "As a queer person this sort of argument from a maintainer makes me feel unwelcome. The ignorance which @elia shows by claiming that transfolk are "not accepting reality" is actively harmful. I will not contribute to this project or any other project which @elia maintains." - strand

Not that strand was participating, but states that there will be no future contribution by strand.  This is an appeal to percieved harm - that now strand will not ever contribute, the project is potentially harmed by missing out on a contributor. So now this issue can fall under the Covenant. 

How can we avoid witchhunts?

Sent: Friday, October 26, 2018 at 1:24 PM
From: "NIkolai Marchenko" 
To: jh...@gmx.com
Cc: "Christian Kandeler" , "Qt development mailing list" 
Subject: Re: [Development] QUIP 12: Code of Conduct

Just to clarify: she sought to remove _maintainer_ of the project :) At that point the guy was doing most of the work.

On Fri, Oct 26, 2018 at 7:48 PM Jason H  wrote:

My fundamental problem about the Contributor Covenant[1] was initially and solely the fallout from the Linux Kernel fiasco. But then I learned that it was drafted by Coraline Ada Ehmke, who sought to have a contributor removed [2] from a project preemptively. The contributor did nothing wrong with respect to the project or the project's community.  She constructed a claim of "transphobia" based on a tweet the contributor wrote in no way relating to the project at hand, and slandered the project for not expunging them. My mind is made up: the Contributor Covenant is a tool of oppression.

The specific sentence in the Covenant is:
"This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community."

However, despite being the author of the Covenant (2014), she found it appropriate to attack someone who was clearly not operating in a project space or representing the project community (2015). We now have two examples - the linux Kernel and Opal project, that after CC was enacted that calls for removal of members based on past unrelated tweets went out. One of the problems its politics and political climates change over time. Expressing what is not political at one point in time may become political in subsequent years. People's minds also change over time.

I urge you to read link[3] below and see if we want that kind of attention. It summarizes what happens when the CC has been adopted by other projects.

[1] https://en.wikipedia.org/wiki/Contributor_Covenant
[2] https://github.com/opal/opal/issues/941
[3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

> Sent: Friday, October 26, 2018 at 3:50 AM
> From: "Christian Kandeler" 
> To: "development@qt-project.org" 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Thu, 25 Oct 2018 19:39:45 +0200
> André Pönitz  wrote:
>
> > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
> > > We do have a Code of Conduct at KDE

Re: [Development] QUIP 12: Code of Conduct

2018-10-26 Thread Bernhard Lindner

I wish any one discussion about Qt software quality would have attracted so much
attention, passion and effort as this CoC topic.

-- 
Best Regards,
Bernhard Lindner

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

Re: [Development] QUIP 12: Code of Conduct

Just to clarify: she sought to remove _maintainer_ of the project :) At
that point the guy was doing most of the work.

On Fri, Oct 26, 2018 at 7:48 PM Jason H  wrote:

> My fundamental problem about the Contributor Covenant[1] was initially and
> solely the fallout from the Linux Kernel fiasco. But then I learned that it
> was drafted by Coraline Ada Ehmke, who sought to have a contributor removed
> [2] from a project preemptively. The contributor did nothing wrong with
> respect to the project or the project's community.  She constructed a claim
> of "transphobia" based on a tweet the contributor wrote in no way relating
> to the project at hand, and slandered the project for not expunging them.
> My mind is made up: the Contributor Covenant is a tool of oppression.
>
> The specific sentence in the Covenant is:
> "This Code of Conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community."
>
> However, despite being the author of the Covenant (2014), she found it
> appropriate to attack someone who was clearly not operating in a project
> space or representing the project community (2015). We now have two
> examples - the linux Kernel and Opal project, that after CC was enacted
> that calls for removal of members based on past unrelated tweets went out.
> One of the problems its politics and political climates change over time.
> Expressing what is not political at one point in time may become political
> in subsequent years. People's minds also change over time.
>
> I urge you to read link[3] below and see if we want that kind of
> attention. It summarizes what happens when the CC has been adopted by other
> projects.
>
> [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> [2] https://github.com/opal/opal/issues/941
> [3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> > Sent: Friday, October 26, 2018 at 3:50 AM
> > From: "Christian Kandeler" 
> > To: "development@qt-project.org" 
> > Subject: Re: [Development] QUIP 12: Code of Conduct
> >
> > On Thu, 25 Oct 2018 19:39:45 +0200
> > André Pönitz  wrote:
> >
> > > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via
> Development wrote:
> > > > We do have a Code of Conduct at KDE for about 10 years now, and this
> hasn't
> > > > led to abuse of power, suppression of free speech, racism against
> white people
> > > > or whatever other nonsense people seem to attribute to CoCs
> nowadays.
> > >
> > > The KDE CoC is *friendly*. It contains words like "considerate",
> "pragmatic",
> > > "support". It doesn't push someone's personal political agenda.
> >
> > I agree. It reads as if it was written with the intention of creating a
> constructive environment, lacks the inquisition-y vibe and is free of
> jargon and weirdly over-specific lists.
> >
> >
> > Christian
> > ___
> > 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] QUIP 12: Code of Conduct

My fundamental problem about the Contributor Covenant[1] was initially and 
solely the fallout from the Linux Kernel fiasco. But then I learned that it was 
drafted by Coraline Ada Ehmke, who sought to have a contributor removed [2] 
from a project preemptively. The contributor did nothing wrong with respect to 
the project or the project's community.  She constructed a claim of 
"transphobia" based on a tweet the contributor wrote in no way relating to the 
project at hand, and slandered the project for not expunging them. My mind is 
made up: the Contributor Covenant is a tool of oppression.

The specific sentence in the Covenant is:
"This Code of Conduct applies both within project spaces and in public spaces 
when an individual is representing the project or its community." 

However, despite being the author of the Covenant (2014), she found it 
appropriate to attack someone who was clearly not operating in a project space 
or representing the project community (2015). We now have two examples - the 
linux Kernel and Opal project, that after CC was enacted that calls for removal 
of members based on past unrelated tweets went out. One of the problems its 
politics and political climates change over time. Expressing what is not 
political at one point in time may become political in subsequent years. 
People's minds also change over time.

I urge you to read link[3] below and see if we want that kind of attention. It 
summarizes what happens when the CC has been adopted by other projects.

[1] https://en.wikipedia.org/wiki/Contributor_Covenant
[2] https://github.com/opal/opal/issues/941
[3] https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/

> Sent: Friday, October 26, 2018 at 3:50 AM
> From: "Christian Kandeler" 
> To: "development@qt-project.org" 
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Thu, 25 Oct 2018 19:39:45 +0200
> André Pönitz  wrote:
> 
> > On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development 
> > wrote:
> > > We do have a Code of Conduct at KDE for about 10 years now, and this 
> > > hasn't 
> > > led to abuse of power, suppression of free speech, racism against white 
> > > people 
> > > or whatever other nonsense people seem to attribute to CoCs nowadays.  
> > 
> > The KDE CoC is *friendly*. It contains words like "considerate", 
> > "pragmatic",
> > "support". It doesn't push someone's personal political agenda.  
> 
> I agree. It reads as if it was written with the intention of creating a 
> constructive environment, lacks the inquisition-y vibe and is free of jargon 
> and weirdly over-specific lists.
> 
> 
> Christian
> ___
> 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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 01:12:35 PDT Andy Nichols wrote:
> The way trust works in the Qt project so far is through the meritocracy so
> maybe a solution to any trust issues with enforcement can be solved in a
> similar way?

And on this point: yes, but not the code decision-making structure. I agree 
that we can meritocratically select the CoC Board/Panel/Committee, but the 
merit qualifications necessarily imply it's a separate structure.

Lars is our Chief Maintainer, which means he's good at coding and knows Qt 
inside and out. That does not follow he's good at resolving CoC violations or 
that he has the time for it. (He probably is good, since he's also been a 
perople manager for 15+ years [was my manager even!], but that's not a logical 
conclusion from the original statements)

A better example is me: I am maintainer for QtCore, but I am not qualified to 
judge and address CoC violations.

-- 
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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 01:12:35 PDT Andy Nichols wrote:
> The details of this are tricky though because it depends a lot on trust
> (similarly the security list).  Much of the concern with this proposal has
> to do with the potential for abuse, and rightly so.  I'm not super happy
> with the idea of a Conduct Cabal who has to the power to banish people from
> the community either.

One idea I've seen recently is to populate the panel members at random, on a 
need basis, much like jury duty. I don't know of project adopting this 
solution and whether they've been successful at it. Would be nice to research.

-- 
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] QUIP 12: Code of Conduct

On Friday, 26 October 2018 00:44:57 PDT Alexey Andreyev wrote:
> I want to contribute: to accept that, we have to define "private time"
> meaning in a such public place as the web. Is personal blog page posting a
> private time?

The Mozilla text explains what it considers to be "Mozilla spaces", which 
defines by exclusion everything that is not.

Blogs are a good example: your blog is your own private time. You can write 
whatever you want, even in your own native language which most others can't 
read. But if you choose to aggregate it into Planet Qt, then all the content 
that gets shown there is now contribution to the Qt Community and under the 
CoC, just like the requirement to write in English.

-- 
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] QUIP 12: Code of Conduct

On Thursday, 25 October 2018 23:55:09 PDT Elvis Stansvik wrote:
> Absolutely. And one thing I've when doing code reviews at work is that it's
> _very_ effective to not only point out problem areas of where things should
> be done differently, but also point out parts that are particularly good,
> as encouragement. The reviewee will feel better, and be more productive,
> producing even better code.
> 
> Humans are quite simple in that sense 

Ooh, that's a nice idea. I've only pointed out when it was a very clever 
solution (just short of a hack) to a problem, but I'm thinking I should pay 
attention to more regular things that are well-done.

-- 
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] QUIP 12: Code of Conduct

2018-10-26 Thread Robert Loehning

Am 25.10.2018 um 19:39 schrieb André Pönitz:
> On Thu, Oct 25, 2018 at 09:51:00AM +0200, Volker Krause via Development wrote:
>> We do have a Code of Conduct at KDE for about 10 years now, and this hasn't
>> led to abuse of power, suppression of free speech, racism against white 
>> people
>> or whatever other nonsense people seem to attribute to CoCs nowadays.
> 
> The KDE CoC is *friendly*. It contains words like "considerate", "pragmatic",
> "support". It doesn't push someone's personal political agenda.  This is a
> completely different beast than the Contributor Covenant that's about
> "enforcing", "reporting", "banning".
> 
> I think we'd see much less heat in the discussion if the proposed Qt CoC had
> been based on the KDE CoC.
> 
> Andre'

+1
for the KDE CoC.

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

Re: [Development] QUIP 12: Code of Conduct

2018-10-26 Thread Paul Wicking

Some time lurker, first time poster. I'm an employee of the Qt Company, 
Oslo office, since January 2018. I'm not an approver and as such do not 
have voting rights. However, my favorite Austrian philosopher once said 
"give back and change the world", so this is my way of giving back. 
Let's see if we can't get to the part about changing the world together.

I was surprised when I learned earlier this year that there isn't any 
CoC for the Qt project. I agree wholeheartedly that we shouldn't need 
one. I also agree completely that we do need one. Therefore, I would 
like to thank the volunteers involved in creating these first drafts - 
judging by the amounts of comments in gerrit, it has been quite the task 
already. You people are awesome!

However, I'm sorry to say I find I do not agree with the current 
proposal. As I see it, a code of conduct serves two equally important 
purposes:
   - It serves as a reminder to ourselves to always strive for excellence.
   - It shows that we expect excellence from each other.

In that spirit, I must say I find Simon's suggestion of "kindness 
guidelines" much more appropriate than codifying the bad behavior and 
nasty things we don't want to see. As a new member of _any_ community, I 
would much rather see the one-liner as referenced by Andy, or an 
adaptation of KDE's CoC, than some legalese "formal line in the sand 
about what is unacceptable".

Tell me how I can participate in a productive and fruitful way. Tell me 
what I can expect from the community I am about to take part in. Listing 
what isn't good, tells me that the community is riddled with poisonous 
behavior to such an extent that it is more important to focus on the bad 
than on the good. That doesn't sound like a community I want to be a 
part of. More importantly, that doesn't sound like Qt. Not to me, anyway.

I appreciate how there's room for disagreement on the mailing lists, 
forum, IRC, and gerrit. I have yet to experience something negative - in 
fact, I am in awe at the amount of help and encouragement I get from 
both the community and my fellow TQtC employees, from all corners of the 
world. You help me deliver excellence, and I can only hope to do the 
same for my peers. And I firmly believe a CoC, or kindness guidelines, 
will increase the likelihood of others having a similar experience with 
the Qt community. I wish that for each of you.

Live long and prosper.

--
Paul Wicking
Documentation Engineer
The Qt Company

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

Re: [Development] Qt library link errors under Windows