[Development] QUIP 12: Code of Conduct

[Ulf Hermann]

Hi,

regarding our earlier discussions on a possible Code of Conduct, here as
well as at the Contributors' Summit 2017, I've pushed a QUIP with the
necessary rules and definitions:

https://codereview.qt-project.org/243623

Please review it.

regards,
Ulf

[黄其泽]

I think the committee should reserve a seat for women. It must be a woman
or a woman's dresser to be appointed. This must be written into Code Of
Conduct.

Ulf Hermann <***@qt.io> 于2018幎10月24日呚䞉 䞋午3:17写道

> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623
>
> Please review it.
>
> regards,
> Ulf
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>


--
Python及Qt盞关Bloghttp://hgoldfish.com/

[Ulf Hermann]

On 10/24/18 3:51 PM, 黄其泽 wrote:
> I think the committee should reserve a seat for women. It must be a
> woman or a woman's dresser to be appointed. This must be written into
> Code Of Conduct.

This should not be codified in the QUIP. It would make the respective
language much more complicated and possibly open loopholes that we can't
foresee. The barrier of having one woman on the Committee is very low
already. All it takes (following the current proposal) is two Approvers
to second an initial proposal. So, if only 3 Approvers feel the way you
do, we will have a woman on the Committee.

Ulf

[Jason H]

I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.

Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...

Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".

If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
- How do assure that white people are adequately protected against reverse racism?
-- Do we even agree that reverse racism [is possible to] exist(s)
If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
- Are stances against illegal immigration "racist"?
- Is "Sceintific racism" actual racism or just statistics?
-- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?

NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.

In case it needs to be said-
I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
I am FOR inclusion. I want everyone to feel welcome here. Everyone.

We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.

I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).

I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?



> Sent: Wednesday, October 24, 2018 at 3:17 AM
> From: "Ulf Hermann" <***@qt.io>
> To: "***@qt-project.org" <***@qt-project.org>
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623
>
> Please review it.
>
> regards,
> Ulf
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Aleix Pol]

On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
>
> I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.
>
> Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...
>
> Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".
>
> If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
> If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
> - How do assure that white people are adequately protected against reverse racism?
> -- Do we even agree that reverse racism [is possible to] exist(s)
> If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
> - Are stances against illegal immigration "racist"?
> - Is "Sceintific racism" actual racism or just statistics?
> -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?
>
> NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.
>
> In case it needs to be said-
> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
> I am FOR inclusion. I want everyone to feel welcome here. Everyone.
>
> We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.
>
> I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).
>
> I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?
>
>
>
> > Sent: Wednesday, October 24, 2018 at 3:17 AM
> > From: "Ulf Hermann" <***@qt.io>
> > To: "***@qt-project.org" <***@qt-project.org>
> > Subject: [Development] QUIP 12: Code of Conduct
> >
> > Hi,
> >
> > regarding our earlier discussions on a possible Code of Conduct, here as
> > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > necessary rules and definitions:
> >
> > https://codereview.qt-project.org/243623
> >
> > Please review it.
> >
> > regards,
> > Ulf

Dear Jason,
I fail to see how you can feel entitled to give your opinion when
you've done nothing to earn that right (I can't find any significant
contribution by you), especially when it comes to oppose something
that was agreed together with the rest of the contributors.

I don't think you have even read the proposal. If you want to play
with the grown-ups, act like one first.

Aleix

[Jason H]

Under the Code of Conduct, Can Aleix Pol receive discipline for his/her/their message?


> Sent: Wednesday, October 24, 2018 at 11:42 AM
> From: "Aleix Pol" <***@kde.org>
> To: development <***@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
> >
> > I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.
> >
> > Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...
> >
> > Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".
> >
> > If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
> > If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
> > - How do assure that white people are adequately protected against reverse racism?
> > -- Do we even agree that reverse racism [is possible to] exist(s)
> > If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
> > - Are stances against illegal immigration "racist"?
> > - Is "Sceintific racism" actual racism or just statistics?
> > -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?
> >
> > NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.
> >
> > In case it needs to be said-
> > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
> > I am FOR inclusion. I want everyone to feel welcome here. Everyone.
> >
> > We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.
> >
> > I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).
> >
> > I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?
> >
> >
> >
> > > Sent: Wednesday, October 24, 2018 at 3:17 AM
> > > From: "Ulf Hermann" <***@qt.io>
> > > To: "***@qt-project.org" <***@qt-project.org>
> > > Subject: [Development] QUIP 12: Code of Conduct
> > >
> > > Hi,
> > >
> > > regarding our earlier discussions on a possible Code of Conduct, here as
> > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > necessary rules and definitions:
> > >
> > > https://codereview.qt-project.org/243623
> > >
> > > Please review it.
> > >
> > > regards,
> > > Ulf
>
> Dear Jason,
> I fail to see how you can feel entitled to give your opinion when
> you've done nothing to earn that right (I can't find any significant
> contribution by you), especially when it comes to oppose something
> that was agreed together with the rest of the contributors.
>
> I don't think you have even read the proposal. If you want to play
> with the grown-ups, act like one first.
>
> Aleix
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Jason H]

1. The code of conduct or invitation to contribute says nothing about "earning a right"
2. What are considered qualifying "contributions"? I've been using Qt since 2004. I assure you I've had some influence, be it bug reports, participating in the mailing lists (like now.)
3. How many of these contributions do I need? How are they measured?
4. I was given the opportunity to contribute at this time by a open invite. I have accounts on the various services to be able to contribute. So I did.
5. I wonder if you have even read the proposal yourself. You seem very entitled to have an opinion, so I assume you would, but why then would you write a message that clearly is in violation of acceptable behavior? Lines 52, 53, 56.

Examples of unacceptable behavior by participants include: 49
50
* The use of sexualized language or imagery and unwelcome sexual attention or advances 51
* Trolling, insulting/derogatory comments, and personal or political attacks 52
* Public or private harassment 53
* Publishing others’ private information, such as a physical or electronic address, without explicit 54
permission 55
* Other conduct which could reasonably be considered inappropriate in a professional setting 56

Your email raises several questions, and both of my eyebrows.
1. You seem to think that there is an "entitlement" mechanic at work. If so, we need to define that?
2. You seem to have a metric for "contributions" we need to define that?
3. How does your message contribute to a "positive environment"?
Examples of behavior that contributes to creating a positive environment include: 41
42
* Using welcoming and inclusive language 43
* Being respectful of differing viewpoints and experiences 44
* Gracefully accepting constructive criticism 45
* Focusing on what is best for the community 46
* Showing empathy towards other community members

I didn't expect everyone to agree with me. But I did not expect your message to be the way it was.


> Sent: Wednesday, October 24, 2018 at 11:42 AM
> From: "Aleix Pol" <***@kde.org>
> To: development <***@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
> >
> > I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.
> >
> > Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...
> >
> > Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".
> >
> > If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
> > If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
> > - How do assure that white people are adequately protected against reverse racism?
> > -- Do we even agree that reverse racism [is possible to] exist(s)
> > If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
> > - Are stances against illegal immigration "racist"?
> > - Is "Sceintific racism" actual racism or just statistics?
> > -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?
> >
> > NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.
> >
> > In case it needs to be said-
> > I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
> > I am FOR inclusion. I want everyone to feel welcome here. Everyone.
> >
> > We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.
> >
> > I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).
> >
> > I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?
> >
> >
> >
> > > Sent: Wednesday, October 24, 2018 at 3:17 AM
> > > From: "Ulf Hermann" <***@qt.io>
> > > To: "***@qt-project.org" <***@qt-project.org>
> > > Subject: [Development] QUIP 12: Code of Conduct
> > >
> > > Hi,
> > >
> > > regarding our earlier discussions on a possible Code of Conduct, here as
> > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > necessary rules and definitions:
> > >
> > > https://codereview.qt-project.org/243623
> > >
> > > Please review it.
> > >
> > > regards,
> > > Ulf
>
> Dear Jason,
> I fail to see how you can feel entitled to give your opinion when
> you've done nothing to earn that right (I can't find any significant
> contribution by you), especially when it comes to oppose something
> that was agreed together with the rest of the contributors.
>
> I don't think you have even read the proposal. If you want to play
> with the grown-ups, act like one first.
>
> Aleix
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Ulf Hermann]

> 1. The code of conduct or invitation to contribute says nothing about "earning a right"

The QUIP process follows the lazy consensus mechanism. See QUIP 2 and
QUIP 3. Jason Hihn is not an Approver.

Ulf

[Thiago Macieira]

On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote:
> The QUIP process follows the lazy consensus mechanism. See QUIP 2 and
> QUIP 3. Jason Hihn is not an Approver.

Approvership or maintainership are not required to state opinions.

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

[Ulf Hermann]

> On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote:
>> The QUIP process follows the lazy consensus mechanism. See QUIP 2 and
>> QUIP 3. Jason Hihn is not an Approver.
>
> Approvership or maintainership are not required to state opinions.

Correct. However, someone who is not an Approver can neither give a -2
nor a +2 for a change on gerrit. Therefore the invitation to review the
QUIP does implicitly say something about "earning a right".

Ulf

[Thiago Macieira]

On Wednesday, 24 October 2018 23:17:52 PDT Ulf Hermann wrote:
> > On Wednesday, 24 October 2018 22:52:20 PDT Ulf Hermann wrote:
> >> The QUIP process follows the lazy consensus mechanism. See QUIP 2 and
> >> QUIP 3. Jason Hihn is not an Approver.
> >
> > Approvership or maintainership are not required to state opinions.
>
> Correct. However, someone who is not an Approver can neither give a -2
> nor a +2 for a change on gerrit. Therefore the invitation to review the
> QUIP does implicitly say something about "earning a right".

What you state is correct, but also besides the point.

QUIPs are the writing down of community decisions. They were created to
summarise conclusions from the mailing list discussions. Approvership is not
required to participate in those. The Gerrit review system is later used to
perfect the language of the text, but not to change its essence. And you don't
need to be an approver to post comments there, or give +1 and -1 for that
matter.

I don't know of any contributions of code that Jason H may have made,
nonetheless his email deserves to be read and answered.

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

[Alexander Nassian]

Arrogant mails like this from you are the reason why CoD are popping even up. Talking about the right of „playing with the grown ups“ but writing so much BS that would already violate the proposed CoD.


> Am 24.10.2018 um 17:42 schrieb Aleix Pol <***@kde.org>:
>
> On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
>>
>> I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.
>>
>> Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...
>>
>> Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".
>>
>> If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
>> If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
>> - How do assure that white people are adequately protected against reverse racism?
>> -- Do we even agree that reverse racism [is possible to] exist(s)
>> If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
>> - Are stances against illegal immigration "racist"?
>> - Is "Sceintific racism" actual racism or just statistics?
>> -- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?
>>
>> NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.
>>
>> In case it needs to be said-
>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
>> I am FOR inclusion. I want everyone to feel welcome here. Everyone.
>>
>> We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.
>>
>> I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).
>>
>> I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?
>>
>>
>>
>>> Sent: Wednesday, October 24, 2018 at 3:17 AM
>>> From: "Ulf Hermann" <***@qt.io>
>>> To: "***@qt-project.org" <***@qt-project.org>
>>> Subject: [Development] QUIP 12: Code of Conduct
>>>
>>> Hi,
>>>
>>> regarding our earlier discussions on a possible Code of Conduct, here as
>>> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
>>> necessary rules and definitions:
>>>
>>> https://codereview.qt-project.org/243623
>>>
>>> Please review it.
>>>
>>> regards,
>>> Ulf
>
> Dear Jason,
> I fail to see how you can feel entitled to give your opinion when
> you've done nothing to earn that right (I can't find any significant
> contribution by you), especially when it comes to oppose something
> that was agreed together with the rest of the contributors.
>
> I don't think you have even read the proposal. If you want to play
> with the grown-ups, act like one first.
>
> Aleix
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


--













—


bitshift dynamics GmbH
Neudorfer Str. 1, 79541 Lörrach

Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747

GeschÀftsfÌhrer: Alexander Nassian, Markus Pfaffinger



http://www.bitshift-dynamics.de <http://www.bitshift-dynamics.de/>


Zentrale: [phone] - 0
Fax: [phone] - 90


Allgemeine Anfragen:
***@bitshift-dynamics.com <mailto:***@bitshift-dynamics.com>
Technischer
Support: ***@bitshift-dynamics.com
<mailto:***@bitshift-dynamics.com>
Buchhaltung:
***@bitshift-dynamics.com <mailto:***@bitshift-dynamics.com>

[André Pönitz]

On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote:
> On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
> >
> > I am whole-heartedly against a Code of Conduct. [...]
> > >
> > > Hi,
> > >
> > > regarding our earlier discussions on a possible Code of Conduct, here as
> > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > necessary rules and definitions:
> > >
> > > https://codereview.qt-project.org/243623
> > >
> > > Please review it.
> > >
> > > regards, Ulf
>
> Dear Jason, I fail to see how you can feel entitled to give your opinion when
> you've done nothing to earn that right

The Governance Model states that

"The Qt Project is a meritocratic, consensus-based community interested in Qt.

"Anyone who shares that interest can join the community, participate in its
decision making processes, and contribute to Qt's development. "

Jason has shown his interest in Qt multiple times. According to this definition
he is clearly a member of the community, he is under the current rules fully
entitled to take part in the decision making process and state his opinion.

Andre'

PS:

> (I can't find any significant contribution by you), especially when it comes
> to oppose something that was agreed together with the rest of the contributors.
>
> I don't think you have even read the proposal. If you want to play with the
> grown-ups, act like one first.

I refrain from commenting this further.

[NIkolai Marchenko]

Looking from outside: Qt has always seemed the community that just dpesn't
need something like that to regulate itself.
Explicit Code seems like an alien entity and ppl already trying to enforce
"at least one female" rise all kinds of warning flags in my eyes.

Personally, I only see the potential to strangle creativity and turning ppl
off from joining in enforcing such a code without any benefit other than
"to look civilized"


On Wed, Oct 24, 2018 at 9:32 PM André Pönitz <***@t-online.de> wrote:

> On Wed, Oct 24, 2018 at 05:42:59PM +0200, Aleix Pol wrote:
> > On Wed, Oct 24, 2018 at 5:10 PM Jason H <***@gmx.com> wrote:
> > >
> > > I am whole-heartedly against a Code of Conduct. [...]
> > > >
> > > > Hi,
> > > >
> > > > regarding our earlier discussions on a possible Code of Conduct,
> here as
> > > > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > > > necessary rules and definitions:
> > > >
> > > > https://codereview.qt-project.org/243623
> > > >
> > > > Please review it.
> > > >
> > > > regards, Ulf
> >
> > Dear Jason, I fail to see how you can feel entitled to give your opinion
> when
> > you've done nothing to earn that right
>
> The Governance Model states that
>
> "The Qt Project is a meritocratic, consensus-based community interested
> in Qt.
>
> "Anyone who shares that interest can join the community, participate in
> its
> decision making processes, and contribute to Qt's development. "
>
> Jason has shown his interest in Qt multiple times. According to this
> definition
> he is clearly a member of the community, he is under the current rules
> fully
> entitled to take part in the decision making process and state his opinion.
>
> Andre'
>
> PS:
>
> > (I can't find any significant contribution by you), especially when it
> comes
> > to oppose something that was agreed together with the rest of the
> contributors.
> >
> > I don't think you have even read the proposal. If you want to play with
> the
> > grown-ups, act like one first.
>
> I refrain from commenting this further.
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Marco Bubke]

Hallo Jason


> It was purely about lines of code. It was elegant and beautiful, and brutally simple.


This is aesthetics and if you would reflect about it with other you could find out that is very context sensitive.


My experience in this area is that their are many people who prefer interaction with computer to interaction with different people. 😉 Many people use a platonic language all the time without any reflection about the problems of that language. And this is creating friction, much friction, and not the kind of productive friction. Is it not nice to understand if other people have a different aesthetic view of how code should look?


It's my experience which is shaping my context. And I believe it's the same for you. So I think that our context is different. So if we work together should we not respect different contexts and try to understand them. Use that difference to create something better. Is that not better than connect our work with our self and let discussion easily get highly emotional? What do you think is the outcome of this culture? I don't believe that this highly emotional, sometimes rude, culture is creating the best source code! I think it is driving many talented people away.


Best, Marco

________________________________
From: Development <development-bounces+marco.bubke=***@qt-project.org> on behalf of Jason H <***@gmx.com>
Sent: Wednesday, October 24, 2018 5:09:58 PM
To: Ulf Hermann
Cc: ***@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

I am whole-heartedly against a Code of Conduct. While well-intentioned, anyone following the shit-show that is the Linux kernel code of conduct fiasco, I also think would be against the code of conduct as well.

Immediately after imposing the Code of Conduct, past tweets by contributors and the accusations started flying and it devolved from there. In addition to several authorities on Open Source weighed in that yes, contributors can revoke the copyright of their prior contributions, which was threatened by those accused. Which would leave any software in a lurch. Now, it looks like those contributors might go to BSD...

Having been interested in software from a very young age, and later specifically Open Source, one thing that appealed to me was that it was a meritocracy. The best code survives, your code contributions are limited only by your code being the best. Now we're saying it's not just your code, but also your behavior. We had an ideal, we had THE ideal - a place where only our ideas mattered. A place where nothing else mattered - not your gentatilia, your sexual identity, not your partner preference, not your political party - none of it. It was purely about lines of code. It was elegant and beautiful, and brutally simple. And now the social justice warriors are contaminating that perfection with code+conduct. So it goes from "this is the best code that could be written" to "this is the best code that could be written from an individual whose political ideals match our own".

If we adopt this, does that mean there is a [git commit hook| gerrit review] installed that evaluates the contributor's social media to find controversial posts?
If we adopt this, how do we assure we don't wind up in a Sarah Jeong situation (She's racist against white people, but the New York Times says that's "ok")?
- How do assure that white people are adequately protected against reverse racism?
-- Do we even agree that reverse racism [is possible to] exist(s)
If we adopt this, what exactly are the political ideas a Qt contributor must espouse?
- Are stances against illegal immigration "racist"?
- Is "Sceintific racism" actual racism or just statistics?
-- In a matter closer to home, where are we on James Damore situation? Would he be banned from this community?

NONE of those questions should need to be contemplated by an Open Source software project. Open Source is about the Source. Not the source of the Source.

In case it needs to be said-
I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
I am FOR inclusion. I want everyone to feel welcome here. Everyone.

We might identify as a "community" as we are people, but really we're an open source project, and at the end of the day what matters the most is what is in git.

I oppose any Code of Conduct. And demand the answers be provided to the above questions PRIOR to passage (if it happens).

I really want to know where we are with James Damore because I thought his paper was well-researched with a scientific basis?



> Sent: Wednesday, October 24, 2018 at 3:17 AM
> From: "Ulf Hermann" <***@qt.io>
> To: "***@qt-project.org" <***@qt-project.org>
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623
>
> Please review it.
>
> regards,
> Ulf
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
***@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Jason H]

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

[Edward Welbourne]

Jason H (24 October 2018 17:09)
> - Is "Sceintific racism" actual racism or just statistics?

If it's racism, it's racism, however qualified.
Extrapolation from populations to individuals misuses statistics.
It isn't scientific, it just abuses tools lifted out of science.

> I really want to know where we are with James Damore because I thought
> his paper was well-researched with a scientific basis?

I had to look that name up.
While no source is unbiased, I'll take [0] as a tolerable source.
They do, at least, have a fairly solid understanding of what science is
(and isn't).

* [0] https://rationalwiki.org/wiki/James_Damore

Apparently he fails to understand the difference between very minor
statistical differences between broad populations and the details of
individuals.

Specifically: though the proportion of women who are good at certain
tech jobs might be marginally smaller than the proportion of men who
are, a recruiter who has the economic power of Google and commits to
recruiting equally should be able to do so, without compromising its
recruitment standards, provided there aren't *other factors* at play
that prevent it from doing so. The crucial detail here is that Google
employs a tiny proportion of the population from which it could draw
recruits. So half of Google's relevant technical staff - which is how
many women Google would need to hire to meet the given goal - fits well
within the available pool of suitably-skilled women.

Google would (in this hypothetical world) have to work a little harder
and pay a little more (but it's only a little, since the statistical
effect is quite small in fact) to find the women than to find the men,
but it's not short of applicants and Google, in particular, has
expertise in the field of selecting the best few from a plethora of
candidates - at least when it comes to pointing one at web pages. The
fact that Google doesn't manage to hire equally many good women as men
in various tech positions *is* evidence that there are other factors at
play, aside from the scientific evidence of very minor differences in
aptitude (mostly stemming from differences in interest).

It is, furthermore, patently clear that the world does have other
factors that contribute to the gender divide in various jobs. When
boards are dominated by men, it is no great surprise that women aren't
as widely represented in upper management, from the ranks of which most
boards are drawn, to take just one example.
But this is something of a digression.

> Having been interested in software from a very young age, and later
> specifically Open Source, one thing that appealed to me was that it
> was a meritocracy.

Well, many software practitioners at least aim to make software projects
meritocratic. However, their ability to do so may be compromised by
social dynamics (and economics) in various ways.

> The best code survives, your code contributions are limited only by
> your code being the best.

If those evaluating how good something is are, unwittingly, operating in
an environment that some folk find hostile, those folk get driven off
and the evaluators fail to see how good their contributions would have
been, if they'd only felt at ease. The aim of a code of conduct is to
avoid that.

I endure rudery from others moderately calmly, partly because I come
from a highly-privileged background that gives me the confidence to not
worry that the rudery will actually cause problems I can't handle. I
prefer, and usually manage, to work in environments in which I and those
around me don't need to endure such rudery - partly because, while I can
endure it, I don't like it; but also because I don't want others to be
driven away, whose contributions I might welcome.

There may be bad codes of conduct out there; please don't let that put
you off trying to think about what a good code of conduct would look
like. In particular, note that there are some "entrenched interests"
that don't seem to like codes of conduct; and they've taken pains to
talk up the misadventures of groups struggling to make them work. Other
groups, garnering far less publicity, have bumbled along quite happily
for years with codes of conduct that seem to work fine.

So please don't just write off the code of conduct as a bad plan; try to
help us make a good code of conduct and a good process around it.
In particular, please at least read it before criticising it,

Eddy.

[Jason H]

Thank you Edward.

I am doing that, but "out loud" if you will, on this group. I am asking questions and getting answers (you're the first to actually answer any of my questions).

I am committed to having a free and inclusive community, but with Linux Kernel just having gone through this, and the fall-out still on going, I personally would have us wait to see how that turns out before proceeding with our own. I would like to learn from their mistakes.

So far (but after your email was written) I replied with concerns about
1) the Committee,
-- the allocation of seats to specific birth demographics
-- the politics of said committee
---- members having to embrace the politics of the said committee.
-- the personal weight of members being affected by their contributions, in terms of testimony or punishment.
2) having received a message from someone who was pro-CoC, but whose message clearly in violation of the CoC.
-- If that is acceptable, then why have a CoC at all?

I'm asking a lot of questions and reading all the answers. I appreciate your substantive reply.

Here's an operable suggestion: Choose the committee members at random, per each incident, from the list active users at random. Keep choosing until 3 users have indicated they would participate. That would be the best way to avoid most of the concerns I questioned about.


> Sent: Wednesday, October 24, 2018 at 1:21 PM
> From: "Edward Welbourne" <***@qt.io>
> To: "Jason H" <***@gmx.com>
> Cc: "***@qt-project.org" <***@qt-project.org>, "Ulf Hermann" <***@qt.io>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Jason H (24 October 2018 17:09)
> > - Is "Sceintific racism" actual racism or just statistics?
>
> If it's racism, it's racism, however qualified.
> Extrapolation from populations to individuals misuses statistics.
> It isn't scientific, it just abuses tools lifted out of science.
>
> > I really want to know where we are with James Damore because I thought
> > his paper was well-researched with a scientific basis?
>
> I had to look that name up.
> While no source is unbiased, I'll take [0] as a tolerable source.
> They do, at least, have a fairly solid understanding of what science is
> (and isn't).
>
> * [0] https://rationalwiki.org/wiki/James_Damore
>
> Apparently he fails to understand the difference between very minor
> statistical differences between broad populations and the details of
> individuals.
>
> Specifically: though the proportion of women who are good at certain
> tech jobs might be marginally smaller than the proportion of men who
> are, a recruiter who has the economic power of Google and commits to
> recruiting equally should be able to do so, without compromising its
> recruitment standards, provided there aren't *other factors* at play
> that prevent it from doing so. The crucial detail here is that Google
> employs a tiny proportion of the population from which it could draw
> recruits. So half of Google's relevant technical staff - which is how
> many women Google would need to hire to meet the given goal - fits well
> within the available pool of suitably-skilled women.
>
> Google would (in this hypothetical world) have to work a little harder
> and pay a little more (but it's only a little, since the statistical
> effect is quite small in fact) to find the women than to find the men,
> but it's not short of applicants and Google, in particular, has
> expertise in the field of selecting the best few from a plethora of
> candidates - at least when it comes to pointing one at web pages. The
> fact that Google doesn't manage to hire equally many good women as men
> in various tech positions *is* evidence that there are other factors at
> play, aside from the scientific evidence of very minor differences in
> aptitude (mostly stemming from differences in interest).
>
> It is, furthermore, patently clear that the world does have other
> factors that contribute to the gender divide in various jobs. When
> boards are dominated by men, it is no great surprise that women aren't
> as widely represented in upper management, from the ranks of which most
> boards are drawn, to take just one example.
> But this is something of a digression.
>
> > Having been interested in software from a very young age, and later
> > specifically Open Source, one thing that appealed to me was that it
> > was a meritocracy.
>
> Well, many software practitioners at least aim to make software projects
> meritocratic. However, their ability to do so may be compromised by
> social dynamics (and economics) in various ways.
>
> > The best code survives, your code contributions are limited only by
> > your code being the best.
>
> If those evaluating how good something is are, unwittingly, operating in
> an environment that some folk find hostile, those folk get driven off
> and the evaluators fail to see how good their contributions would have
> been, if they'd only felt at ease. The aim of a code of conduct is to
> avoid that.
>
> I endure rudery from others moderately calmly, partly because I come
> from a highly-privileged background that gives me the confidence to not
> worry that the rudery will actually cause problems I can't handle. I
> prefer, and usually manage, to work in environments in which I and those
> around me don't need to endure such rudery - partly because, while I can
> endure it, I don't like it; but also because I don't want others to be
> driven away, whose contributions I might welcome.
>
> There may be bad codes of conduct out there; please don't let that put
> you off trying to think about what a good code of conduct would look
> like. In particular, note that there are some "entrenched interests"
> that don't seem to like codes of conduct; and they've taken pains to
> talk up the misadventures of groups struggling to make them work. Other
> groups, garnering far less publicity, have bumbled along quite happily
> for years with codes of conduct that seem to work fine.
>
> So please don't just write off the code of conduct as a bad plan; try to
> help us make a good code of conduct and a good process around it.
> In particular, please at least read it before criticising it,
>
> Eddy.
>

[Shawn Rutledge]

> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com> wrote:
>
> In case it needs to be said-
> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
> I am FOR inclusion. I want everyone to feel welcome here. Everyone.

I agree. It seems to be about fixing something that isn’t broken, or as in that story in the Bible where the people came to a consensus that every other country around them had a king, so they should have a king too. Nothing good came out of it in any cases where we have seen this kind of illogic applied. “Most other big corporations have a deep hierarchy of management, with too much power concentrated at the top, and we want to be a big corporation, so we need to replicate that.” “The other lemmings are running away so maybe we’d better follow.” It’s not the open source way, which seemed to be working well enough already.

If you give power to a committee of 3 people, they will probably abuse it eventually, misjudge, cause bitterness, create factions, and some developers will end up walking away. Seems predictable, doesn’t it?

[Simon Hausmann]

Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>
>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com> wrote:
>>
>> In case it needs to be said-
>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary things. But I am also against people judging other people's code for factors that have nothing to do with the code itself. I find that adding a value judgement of conduct to code to be intolerant. We had the ideal.
>> I am FOR inclusion. I want everyone to feel welcome here. Everyone.
> I agree. It seems to be about fixing something that isn’t broken, or as in that story in the Bible where the people came to a consensus that every other country around them had a king, so they should have a king too. Nothing good came out of it in any cases where we have seen this kind of illogic applied. “Most other big corporations have a deep hierarchy of management, with too much power concentrated at the top, and we want to be a big corporation, so we need to replicate that.” “The other lemmings are running away so maybe we’d better follow.” It’s not the open source way, which seemed to be working well enough already.
>
> If you give power to a committee of 3 people, they will probably abuse it eventually, misjudge, cause bitterness, create factions, and some developers will end up walking away. Seems predictable, doesn’t it?
>

You claim that this is about fixing something that isn't broken. Your
statement that a committee will predictably and eventually abuse their
powers and misjudge is, I feel, a

statement that is spreading fear, doubt and uncertainty, without any
evidence within the scope of this community.


On the other hand I am aware of at least one concrete case where the
behavior of a reviewer has caused a contributor (with a track record of
accepted patches, btw) to

turn away from the project and even resulted in an email of complaint
sent to the community manager. The lack of tools, written understanding
and common agreement

on what is good behavior resulted in that nothing happened at all and
the contributor in question has stayed away from the project since then.


I do think that this is the exception, but it is crucial that we have
the right tools and mechanisms in place when unlikely exceptions happen,
in order to deal with them

instead of ignoring them. After having seen this with my own eyes, I am
convinced of that.


Whether it is a code of conduct or kindness guidelines - anything like
that is something that I welcome as an improvement.


Simon

[Lars Knoll]

On 25 Oct 2018, at 09:51, Volker Krause via Development <***@qt-project.org<mailto:***@qt-project.org>> wrote:

On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
Am 25.10.18 um 08:31 schrieb Shawn Rutledge:



On 24 Oct 2018, at 17:09, Jason H <***@gmx.com<mailto:***@gmx.com>> wrote:



In case it needs to be said-
I am AGAINST racism, sexism, bigotry, and all the other exclusionary
things. But I am also against people judging other people's code for
factors that have nothing to do with the code itself. I find that adding
a value judgement of conduct to code to be intolerant. We had the
ideal.
I am FOR inclusion. I want everyone to feel welcome here.
Everyone.>
I agree. It seems to be about fixing something that isn’t broken, or as
in that story in the Bible where the people came to a consensus that
every other country around them had a king, so they should have a king
too. Nothing good came out of it in any cases where we have seen this
kind of illogic applied. “Most other big corporations have a deep
hierarchy of management, with too much power concentrated at the top, and
we want to be a big corporation, so we need to replicate that.” “The
other lemmings are running away so maybe we’d better follow.” It’s not
the open source way, which seemed to be working well enough already.



If you give power to a committee of 3 people, they will probably abuse it
eventually, misjudge, cause bitterness, create factions, and some
developers will end up walking away. Seems predictable, doesn’t it?




You claim that this is about fixing something that isn't broken. Your
statement that a committee will predictably and eventually abuse their
powers and misjudge is, I feel, a

statement that is spreading fear, doubt and uncertainty, without any
evidence within the scope of this community.


On the other hand I am aware of at least one concrete case where the
behavior of a reviewer has caused a contributor (with a track record of
accepted patches, btw) to

turn away from the project and even resulted in an email of complaint
sent to the community manager. The lack of tools, written understanding
and common agreement

on what is good behavior resulted in that nothing happened at all and
the contributor in question has stayed away from the project since then.


I do think that this is the exception, but it is crucial that we have
the right tools and mechanisms in place when unlikely exceptions happen,
in order to deal with them

instead of ignoring them. After having seen this with my own eyes, I am
convinced of that.


Whether it is a code of conduct or kindness guidelines - anything like
that is something that I welcome as an improvement.


Simon

+1

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.

On the contrary, it gave us a solid foundation to act against the (very few,
fortunately) cases of abusive behavior to protect our contributors. As Simon I
have seen the damage such behavior can do, and therefore would also welcome
tools/rules to be in place to deal with such situations.

Regards,
Volker

I fully agree.

And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit, and explicitly agreed that a group of people will work on creating it. I’m happy we now have a first version, that we can use as a basis for further discussions.

Cheers,
Lars

[Rafael Roquetto]

I understand this has already been set in stone, and I am not here in
the hopes this will change. However, I do feel like I should voice my
own humble opinion - perhaps it can be useful, or maybe not...

I would like to start by saying I fully agree with Shawn: what exactly
are we trying to fix? That is not to say problems never happened, but
these things have side effects - sometimes the most unintended ones. As
C++ programmers, we should know well that unintended side-effects
steaming from well-intentioned constructs are no exception (pun intended).

So I will go back to my question: what is it we are trying to solve? Or
rather, what is it that happened, that we are trying to prevent from
happening again? There will always be lunatics, and a CoC won't stop
them. Perhaps it will improve things... but... perhaps it will do more
harm than good. Or is it proven technology?

Which brings to my second point, a very personal one: more or less in
line with what Jason said, programming *to me* has always been about
bits and bytes, about the code, about computers, about being able to
make things appear on the screen and to control the machine. Free
Software has been about.... free software and that's it. I find it
extremely off-putting to see that the Qt project is embarking in this
sort of politics - again, if things were broken and a CoC could fix
them, I would be more than happy to join the train, but that doesn't
seem to be the case. At least from my humble perspective.

During all these years contributing to Qt I have encountered many times
strong criticism in gerrit - some people were very harsh or *seemingly*
rude - or that was what I thought, until I realized that: 1) it was just
their modus operandi; 2) at the end of the day, their comments made
sense and improved my code; 3) they were not butt hurt when roles were
reversed.

Communication/criticism just like this is unambiguously straightforward
and I *personally* prefer it this way. Unfortunately I could not make it
to the QtCS, but had I been there, I would have voted against the CoC,
for sure. I hate to see politics tainting the project. But, that is my
view, and in spite of that, I do hope that in the end I am wrong and
that the CoC is another step on the right direction. Let's remain
positive and hope it won't even be necessary to invoke it after all, and
that respect and common-sense shall prevail.


- Rafael

PS: if you have read this far (sorry!), you may also be interested in
donating a tad more of your time and help with reviewing this

https://codereview.qt-project.org/#/c/241598/

;)


On 10/25/18 5:58 PM, Lars Knoll wrote:
>> On 25 Oct 2018, at 09:51, Volker Krause via Development
>> <***@qt-project.org <mailto:***@qt-project.org>> wrote:
>>
>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>>>
>>>>
>>>>
>>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com
>>>>> <mailto:***@gmx.com>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> In case it needs to be said-
>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
>>>>> things. But I am also against people judging other people's code for
>>>>> factors that have nothing to do with the code itself. I find that
>>>>> adding
>>>>> a value judgement of conduct to code to be intolerant. We had the
>>>>> ideal.
>> I am FOR inclusion. I want everyone to feel welcome here.
>>>>> Everyone.> 
>>>> I agree.  It seems to be about fixing something that isn’t broken, or as
>>>> in that story in the Bible where the people came to a consensus that
>>>> every other country around them had a king, so they should have a king
>>>> too.  Nothing good came out of it in any cases where we have seen this
>>>> kind of illogic applied.  “Most other big corporations have a deep
>>>> hierarchy of management, with too much power concentrated at the
>>>> top, and
>>>> we want to be a big corporation, so we need to replicate that.”  “The
>>>> other lemmings are running away so maybe we’d better follow.”  It’s not
>>>> the open source way, which seemed to be working well enough already.
>>>
>>>>
>>>>
>>>> If you give power to a committee of 3 people, they will probably
>>>> abuse it
>>>> eventually, misjudge, cause bitterness, create factions, and some
>>>> developers will end up walking away.  Seems predictable, doesn’t it?
>>>
>>>>
>>>
>>>
>>> You claim that this is about fixing something that isn't broken. Your 
>>> statement that a committee will predictably and eventually abuse their 
>>> powers and misjudge is, I feel, a
>>>
>>> statement that is spreading fear, doubt and uncertainty, without any 
>>> evidence within the scope of this community.
>>>
>>>
>>> On the other hand I am aware of at least one concrete case where the 
>>> behavior of a reviewer has caused a contributor (with a track record of 
>>> accepted patches, btw) to
>>>
>>> turn away from the project and even resulted in an email of complaint 
>>> sent to the community manager. The lack of tools, written understanding 
>>> and common agreement
>>>
>>> on what is good behavior resulted in that nothing happened at all and 
>>> the contributor in question has stayed away from the project since then.
>>>
>>>
>>> I do think that this is the exception, but it is crucial that we have 
>>> the right tools and mechanisms in place when unlikely exceptions happen, 
>>> in order to deal with them
>>>
>>> instead of ignoring them. After having seen this with my own eyes, I am 
>>> convinced of that.
>>>
>>>
>>> Whether it is a code of conduct or kindness guidelines - anything like 
>>> that is something that I welcome as an improvement.
>>>
>>>
>>> Simon
>>
>> +1
>>
>> 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.
>>
>> On the contrary, it gave us a solid foundation to act against the
>> (very few, 
>> fortunately) cases of abusive behavior to protect our contributors. As
>> Simon I 
>> have seen the damage such behavior can do, and therefore would also
>> welcome 
>> tools/rules to be in place to deal with such situations.
>>
>> Regards,
>> Volker
>
> I fully agree.
>
> And btw, we have had a clear majority in favour of adding a CoC at the
> Contributor Summit, and explicitly agreed that a group of people will
> work on creating it. I’m happy we now have a first version, that we can
> use as a basis for further discussions.
>
> Cheers,
> Lars
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[NIkolai Marchenko]

> And btw, we have had a clear majority in favour of adding a CoC at the
Contributor Summit

It seems very wrong to make such decisions at conventions where only a
small part of the contributors can participate.
Especially for something as big and divisive

On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto <***@roquetto.com>
wrote:

> I understand this has already been set in stone, and I am not here in
> the hopes this will change. However, I do feel like I should voice my
> own humble opinion - perhaps it can be useful, or maybe not...
>
> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix? That is not to say problems never happened, but
> these things have side effects - sometimes the most unintended ones. As
> C++ programmers, we should know well that unintended side-effects
> steaming from well-intentioned constructs are no exception (pun intended).
>
> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?
>
> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.
>
> During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made
> sense and improved my code; 3) they were not butt hurt when roles were
> reversed.
>
> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project. But, that is my
> view, and in spite of that, I do hope that in the end I am wrong and
> that the CoC is another step on the right direction. Let's remain
> positive and hope it won't even be necessary to invoke it after all, and
> that respect and common-sense shall prevail.
>
>
> - Rafael
>
> PS: if you have read this far (sorry!), you may also be interested in
> donating a tad more of your time and help with reviewing this
>
> https://codereview.qt-project.org/#/c/241598/
>
> ;)
>
>
> On 10/25/18 5:58 PM, Lars Knoll wrote:
> >> On 25 Oct 2018, at 09:51, Volker Krause via Development
> >> <***@qt-project.org <mailto:***@qt-project.org>> wrote:
> >>
> >> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
> >>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
> >>>
> >>>>
> >>>>
> >>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com
> >>>>> <mailto:***@gmx.com>> wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>> In case it needs to be said-
> >>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
> >>>>> things. But I am also against people judging other people's code for
> >>>>> factors that have nothing to do with the code itself. I find that
> >>>>> adding
> >>>>> a value judgement of conduct to code to be intolerant. We had the
> >>>>> ideal.
> >> I am FOR inclusion. I want everyone to feel welcome here.
> >>>>> Everyone.>
> >>>> I agree. It seems to be about fixing something that isn’t broken, or
> as
> >>>> in that story in the Bible where the people came to a consensus that
> >>>> every other country around them had a king, so they should have a king
> >>>> too. Nothing good came out of it in any cases where we have seen this
> >>>> kind of illogic applied. “Most other big corporations have a deep
> >>>> hierarchy of management, with too much power concentrated at the
> >>>> top, and
> >>>> we want to be a big corporation, so we need to replicate that.” “The
> >>>> other lemmings are running away so maybe we’d better follow.” It’s
> not
> >>>> the open source way, which seemed to be working well enough already.
> >>>
> >>>>
> >>>>
> >>>> If you give power to a committee of 3 people, they will probably
> >>>> abuse it
> >>>> eventually, misjudge, cause bitterness, create factions, and some
> >>>> developers will end up walking away. Seems predictable, doesn’t it?
> >>>
> >>>>
> >>>
> >>>
> >>> You claim that this is about fixing something that isn't broken. Your
> >>> statement that a committee will predictably and eventually abuse their
> >>> powers and misjudge is, I feel, a
> >>>
> >>> statement that is spreading fear, doubt and uncertainty, without any
> >>> evidence within the scope of this community.
> >>>
> >>>
> >>> On the other hand I am aware of at least one concrete case where the
> >>> behavior of a reviewer has caused a contributor (with a track record
> of
> >>> accepted patches, btw) to
> >>>
> >>> turn away from the project and even resulted in an email of complaint
> >>> sent to the community manager. The lack of tools, written
> understanding
> >>> and common agreement
> >>>
> >>> on what is good behavior resulted in that nothing happened at all and
> >>> the contributor in question has stayed away from the project since
> then.
> >>>
> >>>
> >>> I do think that this is the exception, but it is crucial that we have
> >>> the right tools and mechanisms in place when unlikely exceptions
> happen,
> >>> in order to deal with them
> >>>
> >>> instead of ignoring them. After having seen this with my own eyes, I
> am
> >>> convinced of that.
> >>>
> >>>
> >>> Whether it is a code of conduct or kindness guidelines - anything like
> >>> that is something that I welcome as an improvement.
> >>>
> >>>
> >>> Simon
> >>
> >> +1
> >>
> >> 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.
> >>
> >> On the contrary, it gave us a solid foundation to act against the
> >> (very few,
> >> fortunately) cases of abusive behavior to protect our contributors. As
> >> Simon I
> >> have seen the damage such behavior can do, and therefore would also
> >> welcome
> >> tools/rules to be in place to deal with such situations.
> >>
> >> Regards,
> >> Volker
> >
> > I fully agree.
> >
> > And btw, we have had a clear majority in favour of adding a CoC at the
> > Contributor Summit, and explicitly agreed that a group of people will
> > work on creating it. I’m happy we now have a first version, that we can
> > use as a basis for further discussions.
> >
> > Cheers,
> > Lars
> >
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Konstantin Tokarev]

25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com>:
>> And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit
>
> It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate.
> Especially for something as big and divisive

+1

-- 
Regards,
Konstantin

[NIkolai Marchenko]

I would also like to point out an extreme case:
https://github.com/opal/opal/issues/941
Now, I am not saying the Code is going to transform into a shitstorm like
this. But it's something to be aware of.
Some clear boundaries must be set if Code is ever enforced.

Also: a question needs to be answered: say, there's a contributor that does
a lot.
He's a rude ass, but he is a _productive_ rude ass and mostly everyone
agrees that his contributions outweigh his particular quirk.
What are you going to do under such a code of conduct? Remove his access to
the project? This sounds ridiculous tbh.

On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru>
wrote:

>
>
> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com>:
> >> And btw, we have had a clear majority in favour of adding a CoC at the
> Contributor Summit
> >
> > It seems very wrong to make such decisions at conventions where only a
> small part of the contributors can participate.
> > Especially for something as big and divisive
>
> +1
>
> --
> Regards,
> Konstantin
>

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces+mitch.curtis=***@qt-
> project.org> On Behalf Of NIkolai Marchenko
> Sent: Thursday, 25 October 2018 12:13 PM
> To: Konstantin Tokarev <***@yandex.ru>
> Cc: Qt development mailing list <***@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> I would also like to point out an extreme case:
> https://github.com/opal/opal/issues/941
> Now, I am not saying the Code is going to transform into a shitstorm like this.
> But it's something to be aware of.
> Some clear boundaries must be set if Code is ever enforced.
>
>
> Also: a question needs to be answered: say, there's a contributor that does a
> lot.
> He's a rude ass, but he is a _productive_ rude ass and mostly everyone
> agrees that his contributions outweigh his particular quirk.
> What are you going to do under such a code of conduct? Remove his access
> to the project? This sounds ridiculous tbh.

It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour.

To answer your question: in my experience, nothing happens. They continue being a rude arse because:

1) That is who they are and they aren't interested in changing.
2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting.
3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors?

Rafael said:

"During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed."

To me it seems like you guys are saying:

"I don't care if this person treats me like crap because they sure can code."

I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out.

What you're also saying is:

"You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code."

Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on:

"People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions."

- https://www.contributor-covenant.org/

Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true.

Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening.

I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid.

> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru
> <mailto:***@yandex.ru> > wrote:
>
>
>
>
> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
> <mailto:***@gmail.com> >:
> >> And btw, we have had a clear majority in favour of adding a CoC at
> the Contributor Summit
> >
> > It seems very wrong to make such decisions at conventions where
> only a small part of the contributors can participate.
> > Especially for something as big and divisive
>
> +1
>
> --
> Regards,
> Konstantin
>

[Tor Arne Vestbø]

I 100% stand behind Mitch’s summary below. This is a real problem in this project that not only makes it a less than great place to work, but is also indirectly affecting the quality of the code, for those that care only about that part.

Tor Arne

> On 25 Oct 2018, at 13:22, Mitch Curtis <***@qt.io> wrote:
>
> It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour.
>
> To answer your question: in my experience, nothing happens. They continue being a rude arse because:
>
> 1) That is who they are and they aren't interested in changing.
> 2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting.
> 3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors?
>
> Rafael said:
>
> "During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed."
>
> To me it seems like you guys are saying:
>
> "I don't care if this person treats me like crap because they sure can code."
>
> I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out.
>
> What you're also saying is:
>
> "You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code."
>
> Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on:
>
> "People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions."
>
> - https://www.contributor-covenant.org/
>
> Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true.
>
> Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening.
>
> I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid.
>
>> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru
>> <mailto:***@yandex.ru> > wrote:
>>
>>
>>
>>
>> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
>> <mailto:***@gmail.com> >:
>> >> And btw, we have had a clear majority in favour of adding a CoC at
>> the Contributor Summit
>> >
>> > It seems very wrong to make such decisions at conventions where
>> only a small part of the contributors can participate.
>> > Especially for something as big and divisive
>>
>> +1
>>
>> --
>> Regards,
>> Konstantin
>>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[NIkolai Marchenko]

> To answer your question: in my experience, nothing happens. They
continue being a rude arse because:
And that's my problem with this code of conduct.
If it's unenforceable then this should not be Code but Guidelines.
If it's enforceable it should first be decided what is going to happen in
the case I described.

> This is a real problem in this project that not only makes it a less than
great place to work, but is also indirectly affecting the quality of the
code
Multiple people have alrady asked for examples of what the code is trying
to solve.
If you have those, we'd like to hear about these exact cases.




On Thu, Oct 25, 2018 at 2:32 PM Tor Arne VestbÞ <***@qt.io>
wrote:

> I 100% stand behind Mitch’s summary below. This is a real problem in this
> project that not only makes it a less than great place to work, but is also
> indirectly affecting the quality of the code, for those that care only
> about that part.
>
> Tor Arne
>
> > On 25 Oct 2018, at 13:22, Mitch Curtis <***@qt.io> wrote:
> >
> > It's a bit of a loaded question. First you call asocial behaviour a
> "quirk", as if someone who treats other people like crap is "quirky" - I
> prefer your phrase "rude arse". Should a code of conduct aim to stop
> "quirky" behaviour amongst contributors? No, of course not. That's what
> makes people interesting. A code of conduct should draw the line between
> quirky behaviour and "rude arse" behaviour.
> >
> > To answer your question: in my experience, nothing happens. They
> continue being a rude arse because:
> >
> > 1) That is who they are and they aren't interested in changing.
> > 2) People have already decided that this person's technical
> contributions are worth enough that they can step on anyone, regardless of
> the fact that it's supposed to be a professional setting.
> > 3) They're "actually a nice person in real life"... as if this excuses
> it. So if I write "You're a dumbarse" on a piece of paper and send it
> through the post, but a week later invite you over to my house for a
> home-cooked meal, it's OK? Are we really encouraging keyboard warriors?
> >
> > Rafael said:
> >
> > "During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made sense
> and improved my code; 3) they were not butt hurt when roles were reversed."
> >
> > To me it seems like you guys are saying:
> >
> > "I don't care if this person treats me like crap because they sure can
> code."
> >
> > I'm happy for you if you've gotten this far in life and decided that you
> like being insulted in exchange for someone reviewing your code (or even
> just asking a question on IRC), but personally I do not like it. I'm more
> than capable of standing up for myself, but other people who feel the same
> way may not feel comfortable speaking out.
> >
> > What you're also saying is:
> >
> > "You (the Qt Project) aren't going to do anything about their behaviour
> because they contribute good code."
> >
> > Which sadly is true. Really, your question seems almost rhetorical given
> this. It's even explicitly acknowledged on the home page of the thing that
> we're basing our code of conduct on:
> >
> > "People with “merit” are often excused for their bad behavior in public
> spaces based on the value of their technical contributions."
> >
> > - https://www.contributor-covenant.org/
> >
> > Disregarding all of the other factors (racism, sexual identity, age,
> etc.) and just keeping it purely about treating other people with respect:
> the statement above is absolutely true.
> >
> > Honestly I have my doubts whether this code of conduct will actually
> achieve its most basic goal, given that many people have apparently tried
> to intervene with the people who treat others poorly and nothing has come
> of it (although people will tell you it's gotten better). I hope it does,
> but I've been in the community and around these people long enough to know
> that it probably won't. Reading through these replies, it's also clear that
> a large amount of the people responding are quite happy with the status
> quo, which, although not surprising to me, is always disheartening.
> >
> > I haven't seen any racism, discrimination, etc., but there are
> definitely people within the community whose behaviour is such that other
> developers will avoid interacting with them, even if it would have likely
> improved the quality of their work or got that work done faster. I doubt
> you'll hear from those people though, because they just want to get their
> job done -- which is perfectly understandable, but does not excuse the
> behaviour of the people they try to avoid.
> >
> >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru
> >> <mailto:***@yandex.ru> > wrote:
> >>
> >>
> >>
> >>
> >> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
> >> <mailto:***@gmail.com> >:
> >> >> And btw, we have had a clear majority in favour of adding a CoC
> at
> >> the Contributor Summit
> >> >
> >> > It seems very wrong to make such decisions at conventions where
> >> only a small part of the contributors can participate.
> >> > Especially for something as big and divisive
> >>
> >> +1
> >>
> >> --
> >> Regards,
> >> Konstantin
> >>
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>
>

[Tor Arne Vestbø]

> On 25 Oct 2018, at 14:21, NIkolai Marchenko <***@gmail.com> wrote:
>
> Multiple people have alrady asked for examples of what the code is trying to solve.
> If you have those, we'd like to hear about these exact cases.

Mitch’s email describes this in a good way. I’m obviously not going to go into details about concrete cases. If the project/community can’t trust that these are real concerns coming from long standing contributors, without airing dirty laundry in the process, then we’re worse off than I thought.

Tor Arne

>
>
>
>
> On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø <***@qt.io> wrote:
> I 100% stand behind Mitch’s summary below. This is a real problem in this project that not only makes it a less than great place to work, but is also indirectly affecting the quality of the code, for those that care only about that part.
>
> Tor Arne
>
> > On 25 Oct 2018, at 13:22, Mitch Curtis <***@qt.io> wrote:
> >
> > It's a bit of a loaded question. First you call asocial behaviour a "quirk", as if someone who treats other people like crap is "quirky" - I prefer your phrase "rude arse". Should a code of conduct aim to stop "quirky" behaviour amongst contributors? No, of course not. That's what makes people interesting. A code of conduct should draw the line between quirky behaviour and "rude arse" behaviour.
> >
> > To answer your question: in my experience, nothing happens. They continue being a rude arse because:
> >
> > 1) That is who they are and they aren't interested in changing.
> > 2) People have already decided that this person's technical contributions are worth enough that they can step on anyone, regardless of the fact that it's supposed to be a professional setting.
> > 3) They're "actually a nice person in real life"... as if this excuses it. So if I write "You're a dumbarse" on a piece of paper and send it through the post, but a week later invite you over to my house for a home-cooked meal, it's OK? Are we really encouraging keyboard warriors?
> >
> > Rafael said:
> >
> > "During all these years contributing to Qt I have encountered many times strong criticism in gerrit - some people were very harsh or *seemingly* rude - or that was what I thought, until I realized that: 1) it was just their modus operandi; 2) at the end of the day, their comments made sense and improved my code; 3) they were not butt hurt when roles were reversed."
> >
> > To me it seems like you guys are saying:
> >
> > "I don't care if this person treats me like crap because they sure can code."
> >
> > I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out.
> >
> > What you're also saying is:
> >
> > "You (the Qt Project) aren't going to do anything about their behaviour because they contribute good code."
> >
> > Which sadly is true. Really, your question seems almost rhetorical given this. It's even explicitly acknowledged on the home page of the thing that we're basing our code of conduct on:
> >
> > "People with “merit” are often excused for their bad behavior in public spaces based on the value of their technical contributions."
> >
> > - https://www.contributor-covenant.org/
> >
> > Disregarding all of the other factors (racism, sexual identity, age, etc.) and just keeping it purely about treating other people with respect: the statement above is absolutely true.
> >
> > Honestly I have my doubts whether this code of conduct will actually achieve its most basic goal, given that many people have apparently tried to intervene with the people who treat others poorly and nothing has come of it (although people will tell you it's gotten better). I hope it does, but I've been in the community and around these people long enough to know that it probably won't. Reading through these replies, it's also clear that a large amount of the people responding are quite happy with the status quo, which, although not surprising to me, is always disheartening.
> >
> > I haven't seen any racism, discrimination, etc., but there are definitely people within the community whose behaviour is such that other developers will avoid interacting with them, even if it would have likely improved the quality of their work or got that work done faster. I doubt you'll hear from those people though, because they just want to get their job done -- which is perfectly understandable, but does not excuse the behaviour of the people they try to avoid.
> >
> >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru
> >> <mailto:***@yandex.ru> > wrote:
> >>
> >>
> >>
> >>
> >> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
> >> <mailto:***@gmail.com> >:
> >> >> And btw, we have had a clear majority in favour of adding a CoC at
> >> the Contributor Summit
> >> >
> >> > It seems very wrong to make such decisions at conventions where
> >> only a small part of the contributors can participate.
> >> > Especially for something as big and divisive
> >>
> >> +1
> >>
> >> --
> >> Regards,
> >> Konstantin
> >>
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
>

[Alexey Andreyev]

I guess NIkolai point was not about the trust and some personal details.
I guess everyone could agree that conflicts are possible.

The question was is proposed CoC helping to solve them, or is it making
things worse? Are there any objective metrics?

P.S.: as I said, I personally not against any CoC/guidelines by default,
but have problems with proposed implementation and want to help

чт, 25 Пкт. 2018 г. в 15:30, Tor Arne VestbÞ <***@qt.io>:

>
> > On 25 Oct 2018, at 14:21, NIkolai Marchenko <***@gmail.com>
> wrote:
> >
> > Multiple people have alrady asked for examples of what the code is
> trying to solve.
> > If you have those, we'd like to hear about these exact cases.
>
> Mitch’s email describes this in a good way. I’m obviously not going to go
> into details about concrete cases. If the project/community can’t trust
> that these are real concerns coming from long standing contributors,
> without airing dirty laundry in the process, then we’re worse off than I
> thought.
>
> Tor Arne
>
> >
> >
> >
> >
> > On Thu, Oct 25, 2018 at 2:32 PM Tor Arne VestbÞ <***@qt.io>
> wrote:
> > I 100% stand behind Mitch’s summary below. This is a real problem in
> this project that not only makes it a less than great place to work, but is
> also indirectly affecting the quality of the code, for those that care only
> about that part.
> >
> > Tor Arne
> >
> > > On 25 Oct 2018, at 13:22, Mitch Curtis <***@qt.io> wrote:
> > >
> > > It's a bit of a loaded question. First you call asocial behaviour a
> "quirk", as if someone who treats other people like crap is "quirky" - I
> prefer your phrase "rude arse". Should a code of conduct aim to stop
> "quirky" behaviour amongst contributors? No, of course not. That's what
> makes people interesting. A code of conduct should draw the line between
> quirky behaviour and "rude arse" behaviour.
> > >
> > > To answer your question: in my experience, nothing happens. They
> continue being a rude arse because:
> > >
> > > 1) That is who they are and they aren't interested in changing.
> > > 2) People have already decided that this person's technical
> contributions are worth enough that they can step on anyone, regardless of
> the fact that it's supposed to be a professional setting.
> > > 3) They're "actually a nice person in real life"... as if this excuses
> it. So if I write "You're a dumbarse" on a piece of paper and send it
> through the post, but a week later invite you over to my house for a
> home-cooked meal, it's OK? Are we really encouraging keyboard warriors?
> > >
> > > Rafael said:
> > >
> > > "During all these years contributing to Qt I have encountered many
> times strong criticism in gerrit - some people were very harsh or
> *seemingly* rude - or that was what I thought, until I realized that: 1) it
> was just their modus operandi; 2) at the end of the day, their comments
> made sense and improved my code; 3) they were not butt hurt when roles were
> reversed."
> > >
> > > To me it seems like you guys are saying:
> > >
> > > "I don't care if this person treats me like crap because they sure can
> code."
> > >
> > > I'm happy for you if you've gotten this far in life and decided that
> you like being insulted in exchange for someone reviewing your code (or
> even just asking a question on IRC), but personally I do not like it. I'm
> more than capable of standing up for myself, but other people who feel the
> same way may not feel comfortable speaking out.
> > >
> > > What you're also saying is:
> > >
> > > "You (the Qt Project) aren't going to do anything about their
> behaviour because they contribute good code."
> > >
> > > Which sadly is true. Really, your question seems almost rhetorical
> given this. It's even explicitly acknowledged on the home page of the thing
> that we're basing our code of conduct on:
> > >
> > > "People with “merit” are often excused for their bad behavior in
> public spaces based on the value of their technical contributions."
> > >
> > > - https://www.contributor-covenant.org/
> > >
> > > Disregarding all of the other factors (racism, sexual identity, age,
> etc.) and just keeping it purely about treating other people with respect:
> the statement above is absolutely true.
> > >
> > > Honestly I have my doubts whether this code of conduct will actually
> achieve its most basic goal, given that many people have apparently tried
> to intervene with the people who treat others poorly and nothing has come
> of it (although people will tell you it's gotten better). I hope it does,
> but I've been in the community and around these people long enough to know
> that it probably won't. Reading through these replies, it's also clear that
> a large amount of the people responding are quite happy with the status
> quo, which, although not surprising to me, is always disheartening.
> > >
> > > I haven't seen any racism, discrimination, etc., but there are
> definitely people within the community whose behaviour is such that other
> developers will avoid interacting with them, even if it would have likely
> improved the quality of their work or got that work done faster. I doubt
> you'll hear from those people though, because they just want to get their
> job done -- which is perfectly understandable, but does not excuse the
> behaviour of the people they try to avoid.
> > >
> > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev <***@yandex.ru
> > >> <mailto:***@yandex.ru> > wrote:
> > >>
> > >>
> > >>
> > >>
> > >> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
> > >> <mailto:***@gmail.com> >:
> > >> >> And btw, we have had a clear majority in favour of adding a
> CoC at
> > >> the Contributor Summit
> > >> >
> > >> > It seems very wrong to make such decisions at conventions where
> > >> only a small part of the contributors can participate.
> > >> > Especially for something as big and divisive
> > >>
> > >> +1
> > >>
> > >> --
> > >> Regards,
> > >> Konstantin
> > >>
> > >
> > > _______________________________________________
> > > Development mailing list
> > > ***@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> >
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Mitch Curtis]

> -----Original Message-----
> From: NIkolai Marchenko <***@gmail.com>
> Sent: Thursday, 25 October 2018 2:21 PM
> To: Tor Arne Vestbø <***@qt.io>
> Cc: Mitch Curtis <***@qt.io>; Konstantin Tokarev
> <***@yandex.ru>; Qt development mailing list <***@qt-
> project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > To answer your question: in my experience, nothing happens. They
> continue being a rude arse because:
> And that's my problem with this code of conduct.
> If it's unenforceable then this should not be Code but Guidelines.
> If it's enforceable it should first be decided what is going to happen in the
> case I described.

Call it whatever you like. If it were up to me I'd call it "Things Your Parents Should Have Taught You", just so that people can't attack it based on the boilerplate text that was copied in from that website.

> > This is a real problem in this project that not only makes it a less than great
> place to work, but is also indirectly affecting the quality of the code
> Multiple people have alrady asked for examples of what the code is trying to
> solve.
> If you have those, we'd like to hear about these exact cases.

- If someone asks a question, don't call their question stupid. This makes them far less likely to ask questions. Hopefully I don't need to tell you how important asking questions is for learning. If you care about code quality, you *want* people asking questions.
- If someone pushes a patch, don't call their patch stupid. The person wrote that patch because they're trying to make Qt better, so even if you're "just" attacking the patch itself and not the person directly, you're still going to make them feel like crap. Review a patch by offering constructive feedback. You don't have to be super polite if that's not who you are, but you also don't need to be rude. If you really care about what you're doing, then why not focus that awf--delightful quirky attitude into objective feedback? I left a comment on the Gerrit patch if you care to see what this kind of communication looks like in practice.

All of this is basically just "don't be a snarky arse". It's sad that it has to be mentioned at all, but... here we are. Also, yes, I realise that I'm being snarky, but as someone else mentioned, I'm sure everyone who this is meant for can take it as well as they dish it out.

>
>
> On Thu, Oct 25, 2018 at 2:32 PM Tor Arne Vestbø <***@qt.io
> <mailto:***@qt.io> > wrote:
>
>
> I 100% stand behind Mitch’s summary below. This is a real problem in
> this project that not only makes it a less than great place to work, but is also
> indirectly affecting the quality of the code, for those that care only about that
> part.
>
> Tor Arne
>
> > On 25 Oct 2018, at 13:22, Mitch Curtis <***@qt.io
> <mailto:***@qt.io> > wrote:
> >
> > It's a bit of a loaded question. First you call asocial behaviour a
> "quirk", as if someone who treats other people like crap is "quirky" - I prefer
> your phrase "rude arse". Should a code of conduct aim to stop "quirky"
> behaviour amongst contributors? No, of course not. That's what makes
> people interesting. A code of conduct should draw the line between quirky
> behaviour and "rude arse" behaviour.
> >
> > To answer your question: in my experience, nothing happens. They
> continue being a rude arse because:
> >
> > 1) That is who they are and they aren't interested in changing.
> > 2) People have already decided that this person's technical
> contributions are worth enough that they can step on anyone, regardless of
> the fact that it's supposed to be a professional setting.
> > 3) They're "actually a nice person in real life"... as if this excuses it.
> So if I write "You're a dumbarse" on a piece of paper and send it through the
> post, but a week later invite you over to my house for a home-cooked meal,
> it's OK? Are we really encouraging keyboard warriors?
> >
> > Rafael said:
> >
> > "During all these years contributing to Qt I have encountered many
> times strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just their
> modus operandi; 2) at the end of the day, their comments made sense and
> improved my code; 3) they were not butt hurt when roles were reversed."
> >
> > To me it seems like you guys are saying:
> >
> > "I don't care if this person treats me like crap because they sure can
> code."
> >
> > I'm happy for you if you've gotten this far in life and decided that
> you like being insulted in exchange for someone reviewing your code (or
> even just asking a question on IRC), but personally I do not like it. I'm more
> than capable of standing up for myself, but other people who feel the same
> way may not feel comfortable speaking out.
> >
> > What you're also saying is:
> >
> > "You (the Qt Project) aren't going to do anything about their
> behaviour because they contribute good code."
> >
> > Which sadly is true. Really, your question seems almost rhetorical
> given this. It's even explicitly acknowledged on the home page of the thing
> that we're basing our code of conduct on:
> >
> > "People with “merit” are often excused for their bad behavior in
> public spaces based on the value of their technical contributions."
> >
> > - https://www.contributor-covenant.org/
> >
> > Disregarding all of the other factors (racism, sexual identity, age,
> etc.) and just keeping it purely about treating other people with respect: the
> statement above is absolutely true.
> >
> > Honestly I have my doubts whether this code of conduct will
> actually achieve its most basic goal, given that many people have apparently
> tried to intervene with the people who treat others poorly and nothing has
> come of it (although people will tell you it's gotten better). I hope it does, but
> I've been in the community and around these people long enough to know
> that it probably won't. Reading through these replies, it's also clear that a
> large amount of the people responding are quite happy with the status quo,
> which, although not surprising to me, is always disheartening.
> >
> > I haven't seen any racism, discrimination, etc., but there are
> definitely people within the community whose behaviour is such that other
> developers will avoid interacting with them, even if it would have likely
> improved the quality of their work or got that work done faster. I doubt you'll
> hear from those people though, because they just want to get their job done
> -- which is perfectly understandable, but does not excuse the behaviour of
> the people they try to avoid.
> >
> >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev
> <***@yandex.ru <mailto:***@yandex.ru>
> >> <mailto:***@yandex.ru <mailto:***@yandex.ru> > >
> wrote:
> >>
> >>
> >>
> >>
> >> 25.10.2018, 13:01, "NIkolai Marchenko"
> <***@gmail.com <mailto:***@gmail.com>
> >> <mailto:***@gmail.com
> <mailto:***@gmail.com> > >:
> >> >> And btw, we have had a clear majority in favour of adding a
> CoC at
> >> the Contributor Summit
> >> >
> >> > It seems very wrong to make such decisions at conventions
> where
> >> only a small part of the contributors can participate.
> >> > Especially for something as big and divisive
> >>
> >> +1
> >>
> >> --
> >> Regards,
> >> Konstantin
> >>
> >
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org <mailto:***@qt-
> project.org>
> > http://lists.qt-project.org/mailman/listinfo/development
>
>

[Mitch Curtis]

Just realised that you replied privately; let's take it back to the list.

> -----Original Message-----
> From: Mitch Curtis
> Sent: Thursday, 25 October 2018 3:31 PM
> To: Rafael Roquetto <***@roquetto.com>
> Subject: RE: [Development] QUIP 12: Code of Conduct
>
> > -----Original Message-----
> > From: Rafael Roquetto <***@roquetto.com>
> > Sent: Thursday, 25 October 2018 2:42 PM
> > To: Mitch Curtis <***@qt.io>
> > Subject: Re: [Development] QUIP 12: Code of Conduct
> >
> >
> >
> > On 10/25/18 9:22 PM, Mitch Curtis wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Development <development-bounces+mitch.curtis=***@qt-
> > >> project.org> On Behalf Of NIkolai Marchenko
> > >> Sent: Thursday, 25 October 2018 12:13 PM
> > >> To: Konstantin Tokarev <***@yandex.ru>
> > >> Cc: Qt development mailing list <***@qt-project.org>
> > >> Subject: Re: [Development] QUIP 12: Code of Conduct
> > <snip>
> > > Rafael said:
> > >
> > > "During all these years contributing to Qt I have encountered many
> > > times
> > strong criticism in gerrit - some people were very harsh or
> > *seemingly* rude
> > - or that was what I thought, until I realized that: 1) it was just
> > their modus operandi; 2) at the end of the day, their comments made
> > sense and improved my code; 3) they were not butt hurt when roles were
> reversed."
> > >
> > > To me it seems like you guys are saying:
> > >
> > > "I don't care if this person treats me like crap because they sure can
> code."
> >
> > Exactly, I don't care as long as certain boundaries, such as name
> > calling, are not crossed.
>
> Great!
>
> > And even if, it really depends on the context:
>
> Wait, what?
>
> > I would rather communicate with Linus Torvalds than having to on ice
> > with someone else for the sake of politeness. And just to be clear, I
> > am extrapolating here.
>
> That's a really odd analogy to choose.
>
> If you are reviewing a patch or communicating with someone within this
> community, you're doing so by choice: either because you're being paid to or
> you're here on your own free time. Both are choices. The point of this code
> of conduct is not to limit *who* you communicate with, but *how* you treat
> those people who you communicate with in the course of contributing. It's to
> help people who are getting treated like crap by the "expert" developers
> feel more safe in the community by making it clear what will not be accepted.
>
> > >
> > > I'm happy for you if you've gotten this far in life and decided that
> > > you like
> > being insulted in exchange for someone reviewing your code (or even
> > just asking a question on IRC), but personally I do not like it. I'm
> > more than capable of standing up for myself, but other people who feel
> > the same way may not feel comfortable speaking out.
> > >
> > > What you're also saying is:
> > >
> > > "You (the Qt Project) aren't going to do anything about their
> > > behaviour
> > because they contribute good code."
> >
> > I never said that. See my answer to Simon. Alas, this is something I
> > vehemently oppose. Also, to be clear: I am not suggesting we suck it
> > up and do not take action. I was just suggesting that maybe a CoC is
> > not the way to go.
>
> It was meant for Nikolai, just bad quoting on my behalf.
>
> > >
> > > Which sadly is true. Really, your question seems almost rhetorical
> > > given
> > this. It's even explicitly acknowledged on the home page of the thing
> > that we're basing our code of conduct on:
> > >
> > > "People with “merit” are often excused for their bad behavior in
> > > public
> > spaces based on the value of their technical contributions."
> >
> > And they shouldn't be excused. But this goes both ways. There are a
> > lot of people who like to turn everything into a speech problem. This
> > is when we have to be tolerant and respectful. Sadly, indeed, in the
> > real world things don't work quite like that.
>
> Yes, so: finding a balance. I agree. I just want to get my job done and improve
> as a developer. I don't think anyone wants to force people to be overly
> polite, they just don't want to be attacked. Constructive criticism without
> snarkiness is personally all I'm asking for.
>
> > >
> > > - https://www.contributor-covenant.org/
> > >
> > > Disregarding all of the other factors (racism, sexual identity, age,
> > > etc.) and
> > just keeping it purely about treating other people with respect: the
> > statement above is absolutely true.
> > >
> > > Honestly I have my doubts whether this code of conduct will actually
> > achieve its most basic goal, given that many people have apparently
> > tried to intervene with the people who treat others poorly and nothing
> > has come of it (although people will tell you it's gotten better). I
> > hope it does, but I've been in the community and around these people
> > long enough to know that it probably won't. Reading through these
> > replies, it's also clear that a large amount of the people responding
> > are quite happy with the status quo, which, although not surprising to me,
> is always disheartening.
> > >
> > > I haven't seen any racism, discrimination, etc., but there are
> > > definitely
> > people within the community whose behaviour is such that other
> > developers will avoid interacting with them, even if it would have
> > likely improved the quality of their work or got that work done
> > faster. I doubt you'll hear from those people though, because they
> > just want to get their job done -- which is perfectly understandable,
> > but does not excuse the behaviour of the people they try to avoid.
> > >
> > >> On Thu, Oct 25, 2018 at 1:06 PM Konstantin Tokarev
> > >> <***@yandex.ru <mailto:***@yandex.ru> > wrote:
> > >>
> > >>
> > >>
> > >>
> > >> 25.10.2018, 13:01, "NIkolai Marchenko" <***@gmail.com
> > >> <mailto:***@gmail.com> >:
> > >> >> And btw, we have had a clear majority in favour of adding a CoC
> > >> at the Contributor Summit
> > >> >
> > >> > It seems very wrong to make such decisions at conventions where
> > >> only a small part of the contributors can participate.
> > >> > Especially for something as big and divisive
> > >>
> > >> +1
> > >>
> > >> --
> > >> Regards,
> > >> Konstantin
> > >>
> > >
> > > _______________________________________________
> > > Development mailing list
> > > ***@qt-project.org
> > > http://lists.qt-project.org/mailman/listinfo/development
> > >

[Jason H]

Consolidated reply to multiple threads:

Mitch, you wrote:
> To me it seems like you guys are saying:
>> "I don't care if this person treats me like crap because they sure can code."
> I'm happy for you if you've gotten this far in life and decided that you like being insulted in exchange for someone reviewing your code (or even just asking a question on IRC), but personally I do not like it. I'm more than capable of standing up for myself, but other people who feel the same way may not feel comfortable speaking out.

I do not want to contemplate the emotional state of being of the author when reviewing and leaving comments on gerrit. Many times when I an giving technical feedback, I have been told "[I] sound harsh." I'm just being factual. I never call into the matter anything about the person, but some people still do get butt-hurt when you talk about their code negatively because it is their art. They then can project that criticism of the code onto themself. This is nothing I want to be in the position of being responsible for. As long as my comments are accurate and not unduly harsh, they are (or at least should be deemed) appropriate.



Next, we have the notion that the CoC was somehow agreed to at the Contributors summit. This is not a just action, as the summit was for the privileged few who had:
1) funding and
2) the allowable time away from work and life to attend
3) to the location of the event. Not everyone has a passport and is able to obtain a visa.

As a member who wanted to attend but was not able to, I find the legitimacy of the vote questionable. I call for a vote (use gerrit?) on a measure to adopt a Code of Conduct, then if that passes, we can go on to debate what should be in it.



Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable. So far in this thread I've used the terms "shit-show" (I contemplated more severe terms, but decided against it) and "butt-hurt". These terms were appropriate to convey the meaning intended. Similarly, I have been following the idea of Political Correctness and if it is even effective. We've had 20 years and it looks like it does not work, and overall isn't appreciated. Even if we could agree on what is offensive it would vary across populations and people would still be offended unless the most neutered language was used.



Volker,
You say your KDE CoC has "worked", but your KDE fellow demonstrated that in fact, it has not.

[Edward Welbourne]

Jason H (25 October 2018 16:43) contributed:

Mitch, you wrote:
>> To me it seems like you guys are saying:

>>> "I don't care if this person treats me like crap because they sure
>>> can code."

>> I'm happy for you if you've gotten this far in life and decided that
>> you like being insulted in exchange for someone reviewing your code
>> (or even just asking a question on IRC), but personally I do not like
>> it. I'm more than capable of standing up for myself, but other people
>> who feel the same way may not feel comfortable speaking out.

> I do not want to contemplate the emotional state of being of the
> author when reviewing and leaving comments on gerrit.

I do want to encourage you to think about how you phrase your criticisms
of others' code; in particular, by "contemplating the emotional state
of" an author being so criticised (this is what empathy is about).

> Many times when I an giving technical feedback, I have been told "[I]
> sound harsh." I'm just being factual.

Two ways of saying the same thing may have identical information content
(i.e. they're both "just being factual"), yet have different emotional
content. One does not have to bend over backwards to treat folk gently:
it is enough to just think about the ways of phrasing your feed-back
that respectfully invite them to notice their error rather than just
telling them they're wrong. With practice, it comes quite naturally to
think in terms of "what can I say that will give this person the same
understanding I have" rather than just proving that you know better than
them.

> I never call into the matter anything about the person,

There are more ways to wind people up than direct ad hominem attacks.
Phrasing may hint that you think no-one but an idiot would fail to
notice the thing you happen to know, that they don't. You might not
even intend that hint, but it may yet come across. In particular, if
you *do* think that only an idiot would fail to see what you're pointing
out, please pause to remember that contributors to Qt seldom actually
are idiots and think about what might lead a perfectly reasonable and
smart person to be unaware of the thing you are so familiar with that
you take it for granted.

> but some people still do get butt-hurt when you talk about their code
> negatively because it is their art. They then can project that
> criticism of the code onto themself. This is nothing I want to be in
> the position of being responsible for. As long as my comments are
> accurate and not unduly harsh, they are (or at least should be deemed)
> appropriate.

Leaving aside whether this should or shouldn't be covered by a code of
conduct, that is an attitude I feel I have a duty to challenge. I am
quite capable of forgetting that others can't keep up with some of what
comes easily to me; and I have had decades of colleagues calmly pointing
out to me that perhaps what's obvious to me might not be known by
everyone else. Eventually I learned to stop and think about whether
what was obvious to me was, in fact, obvious to everyone else. It turns
out that, with the vast breadth and complexity of the world of software,
that there are many of us who are used to taking for granted things that
others don't know about; and, unless we stop to remind ourselves that
those we're talking to might be less familiar with the matter, we end up
being quite rude without even thinking about it. It is, indeed, the not
thinking about it that *is* rude.

I was annoyingly pedantic until I learned that, in fact, communication
is at least as much (and, when done competently, more) about the other
person's understanding than mine.

> Next, we have the notion that the CoC was somehow agreed to at the
> Contributors summit.

Well, those at that meeting in the CS agreed to move forward with it.
Ulf has, quite properly, done their bidding. He has also, quite properly,
publicised this on the list *precisely* so that those who can't make it
to Contributors summits, or at least missed that one, or were in one of
the other parallel sessions at the time, have the chance to express their
views on the matter. If nothing else, those who chose to attend that
particular session, even among those at the CS, shall have been to some
degree self-selecting as a group more likely to favour a CoC.

So please don't interpret this as a steam-rolling of a CoC regardless of
what folk want: it's the next step in a process started by some folk who
did call for it; at this step, we get to see how the rest of the
community feels about it,

Eddy.

[Jason H]

> Sent: Thursday, October 25, 2018 at 11:13 AM
> From: "Edward Welbourne" <***@qt.io>
> To: "Jason H" <***@gmx.com>, "Mitch Curtis" <***@qt.io>
> Cc: "Qt development mailing list" <***@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Jason H (25 October 2018 16:43) contributed:
>
> Mitch, you wrote:
> >> To me it seems like you guys are saying:
>
> >>> "I don't care if this person treats me like crap because they sure
> >>> can code."
>
> >> I'm happy for you if you've gotten this far in life and decided that
> >> you like being insulted in exchange for someone reviewing your code
> >> (or even just asking a question on IRC), but personally I do not like
> >> it. I'm more than capable of standing up for myself, but other people
> >> who feel the same way may not feel comfortable speaking out.
>
> > I do not want to contemplate the emotional state of being of the
> > author when reviewing and leaving comments on gerrit.
>
> I do want to encourage you to think about how you phrase your criticisms
> of others' code; in particular, by "contemplating the emotional state
> of" an author being so criticised (this is what empathy is about).
>
> > Many times when I an giving technical feedback, I have been told "[I]
> > sound harsh." I'm just being factual.
>
> Two ways of saying the same thing may have identical information content
> (i.e. they're both "just being factual"), yet have different emotional
> content. One does not have to bend over backwards to treat folk gently:
> it is enough to just think about the ways of phrasing your feed-back
> that respectfully invite them to notice their error rather than just
> telling them they're wrong. With practice, it comes quite naturally to
> think in terms of "what can I say that will give this person the same
> understanding I have" rather than just proving that you know better than
> them.
>
> > I never call into the matter anything about the person,
>
> There are more ways to wind people up than direct ad hominem attacks.
> Phrasing may hint that you think no-one but an idiot would fail to
> notice the thing you happen to know, that they don't. You might not
> even intend that hint, but it may yet come across. In particular, if
> you *do* think that only an idiot would fail to see what you're pointing
> out, please pause to remember that contributors to Qt seldom actually
> are idiots and think about what might lead a perfectly reasonable and
> smart person to be unaware of the thing you are so familiar with that
> you take it for granted.

As a personal strategy I completely agree with you. However I've been at this for 20 years and it's not anything I've made significant progress on. I do not want to offend anyone, though I'm sure I have, inadvertently. I give you my word that I'm not going to verbally abuse anyone. I am continually humbled by the people in this community. They are brilliant. I often learn from being wrong on this and the other Qt lists, so I recognise this community has people of all different levels of ability. I still do however take issue with the idea that I am somehow responsible for someone's reaction to a factual observation or suggestion. It creates a slippery slope of judgement, and it creates a concern that maybe I'll be approached and be told to use kinder words, even when no unkind or inaccurate terms were used. I do however recognize that oser-use of violent profanity could turn people away. I do not know how to strike a balance. This is why I prefer to keep it all about the cod
e.

> > but some people still do get butt-hurt when you talk about their code
> > negatively because it is their art. They then can project that
> > criticism of the code onto themself. This is nothing I want to be in
> > the position of being responsible for. As long as my comments are
> > accurate and not unduly harsh, they are (or at least should be deemed)
> > appropriate.
>
> Leaving aside whether this should or shouldn't be covered by a code of
> conduct, that is an attitude I feel I have a duty to challenge. I am
> quite capable of forgetting that others can't keep up with some of what
> comes easily to me; and I have had decades of colleagues calmly pointing
> out to me that perhaps what's obvious to me might not be known by
> everyone else. Eventually I learned to stop and think about whether
> what was obvious to me was, in fact, obvious to everyone else. It turns
> out that, with the vast breadth and complexity of the world of software,
> that there are many of us who are used to taking for granted things that
> others don't know about; and, unless we stop to remind ourselves that
> those we're talking to might be less familiar with the matter, we end up
> being quite rude without even thinking about it. It is, indeed, the not
> thinking about it that *is* rude.
>
> I was annoyingly pedantic until I learned that, in fact, communication
> is at least as much (and, when done competently, more) about the other
> person's understanding than mine.

I would argue that taking criticism about code is a skill that *MUST* be learned for every developer. Giving effective criticism is also a skill to be learned by every developer, and is just a good life skill in general. How do we split the difference? Or, how we determine who is inappropriately offended? Likely when such situations occur it'll be split blame, because the reviewer *could* have used better language. But then you're effectively condoning the lack of skill in taking criticism. Can criticism be too harsh, surely. But it gets us onto a slippery slope and I prefer 1s and 0s.

> > Next, we have the notion that the CoC was somehow agreed to at the
> > Contributors summit.
>
> Well, those at that meeting in the CS agreed to move forward with it.
> Ulf has, quite properly, done their bidding. He has also, quite properly,
> publicised this on the list *precisely* so that those who can't make it
> to Contributors summits, or at least missed that one, or were in one of
> the other parallel sessions at the time, have the chance to express their
> views on the matter. If nothing else, those who chose to attend that
> particular session, even among those at the CS, shall have been to some
> degree self-selecting as a group more likely to favour a CoC.
>
> So please don't interpret this as a steam-rolling of a CoC regardless of
> what folk want: it's the next step in a process started by some folk who
> did call for it; at this step, we get to see how the rest of the
> community feels about it,

I have no beef with Ulf, or anyone who wants a CoC. Clearly, he doing his duty. I do feel steam rolled as this was never put to the community at large and those in attendance were not duly elected representatives. It feels steamroller-ish because it seems like it's a foregone conclusion that we'll have one. Until you mentioned it just now I thought that ship had sailed. Why work on wording of it's not even a thing to happen? The cart is before the horse. The process should go[/have gone] like this:
1. At Summit, take a vote if this is something to be raised to the larger community.
2. Have the larger community vote on it using general terms as to what the goal would be, what it would contain.
3. If that passes move to specific phrasing.

I am not against adopting measures to ensure that people who are abusive can be removed. As a matter of fact last night I was looking at stuff on community engagement that having a moderation is a good thing, but not entirely effective. In fact to break it down: rumination is .43** correlated with withdraw, moderator intervention is -.13** correlated with withdraw; ** p < .005. Here, rumination is 3 times more likely to produce withdraw than having a moderator. But still, I think it's good thing to document what abuses, if any, will get you removed from the community and how that process works. Such agreements would have to be shown as a click-through when joining a Qt property (mailing list, jira, gerrit, etc.) I'm still against it in general because it introduces slippery slopes and politics. In order for me to consider endorsing any such community conduct standards, it would have to have the following features:
1. No consideration given for off-Qt property actions. (social media sites, email, etc)
2. A non-standing Committee that exists for specific incidents, who
2a. members are chosen at random for each incident
2b. can somehow guarantee the confidentiality of evidence and proceedings, to protect the accuser and accused.
3. Limits slippery slope aspects the fewest possible aspects, and when on a slippery slope aspect, constrains them to their most boolean limits, construed in favor of the accused.

Anything more will itself be a vehicle for abuse.

I really, really hate that we've brought politics into this community. Likely, your opinions of me have changed. I just wanted my presence here to be about Qt. But now I've had to reveal my politics which will open me to judgements not related to my technological contributions.

I realize the initial vote occured before that whole Linux ordeal started, I hope we can learn from what is currently playing out with Linux and avoid that.

[Volker Hilsheimer]

> On 25 Oct 2018, at 16:43, Jason H <***@gmx.com> wrote:
> Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable.


Oh dear.

With your "right to free speech" you probably refer to the first amendment of the United States Constitution.

"Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."

The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities.

A community of people can not only decide not to listen, it can also easily restrict your freedom of speech.

Volker

[Jason H]

> Sent: Thursday, October 25, 2018 at 11:38 AM
> From: "Volker Hilsheimer" <***@qt.io>
> To: "Jason H" <***@gmx.com>, "Qt development mailing list" <***@qt-project.org>
> Cc: "Mitch Curtis" <***@qt.io>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > On 25 Oct 2018, at 16:43, Jason H <***@gmx.com> wrote:
> > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable.
>
>
> Oh dear.
>
> With your "right to free speech" you probably refer to the first amendment of the United States Constitution.
>
> "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
>
> The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities.
>
> A community of people can not only decide not to listen, it can also easily restrict your freedom of speech.

Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either
1) Do not consider it, or
2) Define in excruciating detail, as to remove the "slippery" from the slope.

[Martin Smith]

>There are two ways to resolve this: either
>1) Do not consider it, or
>2) Define in excruciating detail, as to remove the "slippery" from the slope.

There is a 3rd way:
3) Don't define it because you already know what it is. Just explain the comp[laint process and create the committee to deal with each complaint on a case by case basis.

________________________________________
From: Development <development-bounces+martin.smith=***@qt-project.org> on behalf of Jason H <***@gmx.com>
Sent: Thursday, October 25, 2018 7:12:00 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct



> Sent: Thursday, October 25, 2018 at 11:38 AM
> From: "Volker Hilsheimer" <***@qt.io>
> To: "Jason H" <***@gmx.com>, "Qt development mailing list" <***@qt-project.org>
> Cc: "Mitch Curtis" <***@qt.io>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > On 25 Oct 2018, at 16:43, Jason H <***@gmx.com> wrote:
> > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable.
>
>
> Oh dear.
>
> With your "right to free speech" you probably refer to the first amendment of the United States Constitution.
>
> "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
>
> The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities.
>
> A community of people can not only decide not to listen, it can also easily restrict your freedom of speech.

Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either
1) Do not consider it, or
2) Define in excruciating detail, as to remove the "slippery" from the slope.

[Alexey Andreyev]

> Don't define it because you already know what it is. Just explain the
complaint process and create the committee to deal with each complaint on a
case by case basis.
It could make sense, but then we should made a plan how the committee could
work and how many resources could it take.
Should it be the committee from professional developers? How many hours are
they ready to spend for complaints comparing to other tasks?

чт, 25 Пкт. 2018 г. в 20:19, Martin Smith <***@qt.io>:

> >There are two ways to resolve this: either
> >1) Do not consider it, or
> >2) Define in excruciating detail, as to remove the "slippery" from the
> slope.
>
> There is a 3rd way:
> 3) Don't define it because you already know what it is. Just explain the
> comp[laint process and create the committee to deal with each complaint on
> a case by case basis.
>
> ________________________________________
> From: Development <development-bounces+martin.smith=***@qt-project.org>
> on behalf of Jason H <***@gmx.com>
> Sent: Thursday, October 25, 2018 7:12:00 PM
> To: Volker Hilsheimer
> Cc: Qt development mailing list
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
>
>
> > Sent: Thursday, October 25, 2018 at 11:38 AM
> > From: "Volker Hilsheimer" <***@qt.io>
> > To: "Jason H" <***@gmx.com>, "Qt development mailing list" <
> ***@qt-project.org>
> > Cc: "Mitch Curtis" <***@qt.io>
> > Subject: Re: [Development] QUIP 12: Code of Conduct
> >
> > > On 25 Oct 2018, at 16:43, Jason H <***@gmx.com> wrote:
> > > Next there is a notion of the CoC being applied to profanity. I am
> also against this. This would violate my right to free speech, and it would
> be so vague to be unenforceable.
> >
> >
> > Oh dear.
> >
> > With your "right to free speech" you probably refer to the first
> amendment of the United States Constitution.
> >
> > "Congress shall make no law respecting an establishment of religion, or
> prohibiting the free exercise thereof; or abridging the freedom of speech,
> or of the press; or the right of the people peaceably to assemble, and to
> petition the Government for a redress of grievances."
> >
> > The Qt Community is not the US Congress (sadly, perhaps) or some
> instituation legimized by the US Congress. We can therefore not “violate
> your right to free speech”. Also, the right to free speech does not imply
> an obligation for any- or everyone to listen to your speech, no matter the
> opinions or density of profanities.
> >
> > A community of people can not only decide not to listen, it can also
> easily restrict your freedom of speech.
>
> Well, you have people of various legal jurisdictions that have differing
> ideas on what they are allowed to say. Even the US constitution does not
> grant the right to yell "Fire!" in a crowded theater. However being of such
> a jurisdiction I am accustomed to having responsible speech being
> permitted. You are correct that no one has to listen, but I have the right
> to express it. The concern that I have is if certain measures are enacted,
> I will lose my ability to "speak" because someone was offended. It's a
> slippery slope I'd rather not contend with. There are two ways to resolve
> this: either
> 1) Do not consider it, or
> 2) Define in excruciating detail, as to remove the "slippery" from the
> slope.
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Alexey Andreyev]

I want to thank everyone who's spending their time trying to solve the
raised questions.

One more point I want to mention since we are collecting community feedback.

Feel free to call me stupid and skip until the end. I'm pondering about
ideas that controvertial CoC is appeared as some regular result of fight
for profit, power and expantion between successful open communities and
regular companies. And it's not about some specific persons or their
characteristics at all. It looks like an attack on open communities and
their values. I'm not talking about some conspiracy here, I'm talking that
it's probably natural proccess, similar to non-IT historical situations
around the world. Since open IT communities right now are successful enough
to compete with regular "closed" communities, we are observing injecting
some opposite ideas via CoC to "seduce" open communities and destroy them
from inside and then outside.

Like, yes, of cource we have conflicts! People are not social angels. But
we had a much less of them right now comparing to some bad examples of
ineffective companies (with similar size of tasks) with fancy rules and
smiles imitation. Who said that there's any chances to minimize conflicts
more with CoC? Where is professional scientific research that Qt community
or Linux or KDE is slowly dying without CoC? I'm afraid that research could
probably show the opposite.

чт, 25 Пкт. 2018 г. в 20:48, Alexey Andreyev <***@gmail.com>:

> > Don't define it because you already know what it is. Just explain the
> complaint process and create the committee to deal with each complaint on a
> case by case basis.
> It could make sense, but then we should made a plan how the committee
> could work and how many resources could it take.
> Should it be the committee from professional developers? How many hours
> are they ready to spend for complaints comparing to other tasks?
>
> чт, 25 Пкт. 2018 г. в 20:19, Martin Smith <***@qt.io>:
>
>> >There are two ways to resolve this: either
>> >1) Do not consider it, or
>> >2) Define in excruciating detail, as to remove the "slippery" from the
>> slope.
>>
>> There is a 3rd way:
>> 3) Don't define it because you already know what it is. Just explain the
>> comp[laint process and create the committee to deal with each complaint on
>> a case by case basis.
>>
>> ________________________________________
>> From: Development <development-bounces+martin.smith=***@qt-project.org>
>> on behalf of Jason H <***@gmx.com>
>> Sent: Thursday, October 25, 2018 7:12:00 PM
>> To: Volker Hilsheimer
>> Cc: Qt development mailing list
>> Subject: Re: [Development] QUIP 12: Code of Conduct
>>
>>
>>
>> > Sent: Thursday, October 25, 2018 at 11:38 AM
>> > From: "Volker Hilsheimer" <***@qt.io>
>> > To: "Jason H" <***@gmx.com>, "Qt development mailing list" <
>> ***@qt-project.org>
>> > Cc: "Mitch Curtis" <***@qt.io>
>> > Subject: Re: [Development] QUIP 12: Code of Conduct
>> >
>> > > On 25 Oct 2018, at 16:43, Jason H <***@gmx.com> wrote:
>> > > Next there is a notion of the CoC being applied to profanity. I am
>> also against this. This would violate my right to free speech, and it would
>> be so vague to be unenforceable.
>> >
>> >
>> > Oh dear.
>> >
>> > With your "right to free speech" you probably refer to the first
>> amendment of the United States Constitution.
>> >
>> > "Congress shall make no law respecting an establishment of religion, or
>> prohibiting the free exercise thereof; or abridging the freedom of speech,
>> or of the press; or the right of the people peaceably to assemble, and to
>> petition the Government for a redress of grievances."
>> >
>> > The Qt Community is not the US Congress (sadly, perhaps) or some
>> instituation legimized by the US Congress. We can therefore not “violate
>> your right to free speech”. Also, the right to free speech does not imply
>> an obligation for any- or everyone to listen to your speech, no matter the
>> opinions or density of profanities.
>> >
>> > A community of people can not only decide not to listen, it can also
>> easily restrict your freedom of speech.
>>
>> Well, you have people of various legal jurisdictions that have differing
>> ideas on what they are allowed to say. Even the US constitution does not
>> grant the right to yell "Fire!" in a crowded theater. However being of such
>> a jurisdiction I am accustomed to having responsible speech being
>> permitted. You are correct that no one has to listen, but I have the right
>> to express it. The concern that I have is if certain measures are enacted,
>> I will lose my ability to "speak" because someone was offended. It's a
>> slippery slope I'd rather not contend with. There are two ways to resolve
>> this: either
>> 1) Do not consider it, or
>> 2) Define in excruciating detail, as to remove the "slippery" from the
>> slope.
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
>

[Martin Smith]

>Should it be the committee from professional developers?

Volunteers

>How many hours are they ready to spend for complaints comparing to other tasks?

I don't think there will be many complaints. That's the main point of having a CoC. It reminds posters to be civil. When there is a complaint, it is sent to each member of the committee. They read it and agree whether it requires a response. If so, post a reminder of the CoC in the location where the alleged offense occurred.

________________________________________
From: Alexey Andreyev <***@gmail.com>
Sent: Thursday, October 25, 2018 7:48:19 PM
To: Martin Smith
Cc: ***@gmx.com; Volker Hilsheimer; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

> Don't define it because you already know what it is. Just explain the complaint process and create the committee to deal with each complaint on a case by case basis.
It could make sense, but then we should made a plan how the committee could work and how many resources could it take.
Should it be the committee from professional developers? How many hours are they ready to spend for complaints comparing to other tasks?

чт, 25 окт. 2018 г. в 20:19, Martin Smith <***@qt.io<mailto:***@qt.io>>:
>There are two ways to resolve this: either
>1) Do not consider it, or
>2) Define in excruciating detail, as to remove the "slippery" from the slope.

There is a 3rd way:
3) Don't define it because you already know what it is. Just explain the comp[laint process and create the committee to deal with each complaint on a case by case basis.

________________________________________
From: Development <development-bounces+martin.smith=***@qt-project.org<mailto:***@qt-project.org>> on behalf of Jason H <***@gmx.com<mailto:***@gmx.com>>
Sent: Thursday, October 25, 2018 7:12:00 PM
To: Volker Hilsheimer
Cc: Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct



> Sent: Thursday, October 25, 2018 at 11:38 AM
> From: "Volker Hilsheimer" <***@qt.io<mailto:***@qt.io>>
> To: "Jason H" <***@gmx.com<mailto:***@gmx.com>>, "Qt development mailing list" <***@qt-project.org<mailto:***@qt-project.org>>
> Cc: "Mitch Curtis" <***@qt.io<mailto:***@qt.io>>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > On 25 Oct 2018, at 16:43, Jason H <***@gmx.com<mailto:***@gmx.com>> wrote:
> > Next there is a notion of the CoC being applied to profanity. I am also against this. This would violate my right to free speech, and it would be so vague to be unenforceable.
>
>
> Oh dear.
>
> With your "right to free speech" you probably refer to the first amendment of the United States Constitution.
>
> "Congress shall make no law respecting an establishment of religion, or prohibiting the free exercise thereof; or abridging the freedom of speech, or of the press; or the right of the people peaceably to assemble, and to petition the Government for a redress of grievances."
>
> The Qt Community is not the US Congress (sadly, perhaps) or some instituation legimized by the US Congress. We can therefore not “violate your right to free speech”. Also, the right to free speech does not imply an obligation for any- or everyone to listen to your speech, no matter the opinions or density of profanities.
>
> A community of people can not only decide not to listen, it can also easily restrict your freedom of speech.

Well, you have people of various legal jurisdictions that have differing ideas on what they are allowed to say. Even the US constitution does not grant the right to yell "Fire!" in a crowded theater. However being of such a jurisdiction I am accustomed to having responsible speech being permitted. You are correct that no one has to listen, but I have the right to express it. The concern that I have is if certain measures are enacted, I will lose my ability to "speak" because someone was offended. It's a slippery slope I'd rather not contend with. There are two ways to resolve this: either
1) Do not consider it, or
2) Define in excruciating detail, as to remove the "slippery" from the slope.

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

[Thiago Macieira]

On Thursday, 25 October 2018 10:12:00 PDT Jason H wrote:
> Well, you have people of various legal jurisdictions that have differing
> ideas on what they are allowed to say. Even the US constitution does not
> grant the right to yell "Fire!" in a crowded theater. However being of such
> a jurisdiction I am accustomed to having responsible speech being
> permitted. You are correct that no one has to listen, but I have the right
> to express it.

You have the right to express it, but that does not imply the Qt Project has
the obligation to convey it.

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

[Martin Smith]

>It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate.
>Especially for something as big and divisive

It isn't wrong if the adoption process allows everyone to vote on whether to adopt the eventual CoC. What seems wrong is to continue arguing about whether we should develop a CoC after the decision to develop a CoC has been taken. Let's focus on developing an acceptable CoC. You can't seriously claim no CoC can ever be acceptable.

But maybe we won't arrive at an acceptable one. We won't know until we spend some time trying. Other groups seems to have succeeded.

martin
________________________________________
From: Development <development-bounces+martin.smith=***@qt-project.org> on behalf of NIkolai Marchenko <***@gmail.com>
Sent: Thursday, October 25, 2018 12:00:44 PM
To: ***@roquetto.com
Cc: Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

> And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit

It seems very wrong to make such decisions at conventions where only a small part of the contributors can participate.
Especially for something as big and divisive

On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto <***@roquetto.com<mailto:***@roquetto.com>> wrote:
I understand this has already been set in stone, and I am not here in
the hopes this will change. However, I do feel like I should voice my
own humble opinion - perhaps it can be useful, or maybe not...

I would like to start by saying I fully agree with Shawn: what exactly
are we trying to fix? That is not to say problems never happened, but
these things have side effects - sometimes the most unintended ones. As
C++ programmers, we should know well that unintended side-effects
steaming from well-intentioned constructs are no exception (pun intended).

So I will go back to my question: what is it we are trying to solve? Or
rather, what is it that happened, that we are trying to prevent from
happening again? There will always be lunatics, and a CoC won't stop
them. Perhaps it will improve things... but... perhaps it will do more
harm than good. Or is it proven technology?

Which brings to my second point, a very personal one: more or less in
line with what Jason said, programming *to me* has always been about
bits and bytes, about the code, about computers, about being able to
make things appear on the screen and to control the machine. Free
Software has been about.... free software and that's it. I find it
extremely off-putting to see that the Qt project is embarking in this
sort of politics - again, if things were broken and a CoC could fix
them, I would be more than happy to join the train, but that doesn't
seem to be the case. At least from my humble perspective.

During all these years contributing to Qt I have encountered many times
strong criticism in gerrit - some people were very harsh or *seemingly*
rude - or that was what I thought, until I realized that: 1) it was just
their modus operandi; 2) at the end of the day, their comments made
sense and improved my code; 3) they were not butt hurt when roles were
reversed.

Communication/criticism just like this is unambiguously straightforward
and I *personally* prefer it this way. Unfortunately I could not make it
to the QtCS, but had I been there, I would have voted against the CoC,
for sure. I hate to see politics tainting the project. But, that is my
view, and in spite of that, I do hope that in the end I am wrong and
that the CoC is another step on the right direction. Let's remain
positive and hope it won't even be necessary to invoke it after all, and
that respect and common-sense shall prevail.


- Rafael

PS: if you have read this far (sorry!), you may also be interested in
donating a tad more of your time and help with reviewing this

https://codereview.qt-project.org/#/c/241598/

;)


On 10/25/18 5:58 PM, Lars Knoll wrote:
>> On 25 Oct 2018, at 09:51, Volker Krause via Development
>> <***@qt-project.org<mailto:***@qt-project.org> <mailto:***@qt-project.org<mailto:***@qt-project.org>>> wrote:
>>
>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>>>
>>>>
>>>>
>>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com<mailto:***@gmx.com>
>>>>> <mailto:***@gmx.com<mailto:***@gmx.com>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> In case it needs to be said-
>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
>>>>> things. But I am also against people judging other people's code for
>>>>> factors that have nothing to do with the code itself. I find that
>>>>> adding
>>>>> a value judgement of conduct to code to be intolerant. We had the
>>>>> ideal.
>> I am FOR inclusion. I want everyone to feel welcome here.
>>>>> Everyone.>
>>>> I agree. It seems to be about fixing something that isn’t broken, or as
>>>> in that story in the Bible where the people came to a consensus that
>>>> every other country around them had a king, so they should have a king
>>>> too. Nothing good came out of it in any cases where we have seen this
>>>> kind of illogic applied. “Most other big corporations have a deep
>>>> hierarchy of management, with too much power concentrated at the
>>>> top, and
>>>> we want to be a big corporation, so we need to replicate that.” “The
>>>> other lemmings are running away so maybe we’d better follow.” It’s not
>>>> the open source way, which seemed to be working well enough already.
>>>
>>>>
>>>>
>>>> If you give power to a committee of 3 people, they will probably
>>>> abuse it
>>>> eventually, misjudge, cause bitterness, create factions, and some
>>>> developers will end up walking away. Seems predictable, doesn’t it?
>>>
>>>>
>>>
>>>
>>> You claim that this is about fixing something that isn't broken. Your
>>> statement that a committee will predictably and eventually abuse their
>>> powers and misjudge is, I feel, a
>>>
>>> statement that is spreading fear, doubt and uncertainty, without any
>>> evidence within the scope of this community.
>>>
>>>
>>> On the other hand I am aware of at least one concrete case where the
>>> behavior of a reviewer has caused a contributor (with a track record of
>>> accepted patches, btw) to
>>>
>>> turn away from the project and even resulted in an email of complaint
>>> sent to the community manager. The lack of tools, written understanding
>>> and common agreement
>>>
>>> on what is good behavior resulted in that nothing happened at all and
>>> the contributor in question has stayed away from the project since then.
>>>
>>>
>>> I do think that this is the exception, but it is crucial that we have
>>> the right tools and mechanisms in place when unlikely exceptions happen,
>>> in order to deal with them
>>>
>>> instead of ignoring them. After having seen this with my own eyes, I am
>>> convinced of that.
>>>
>>>
>>> Whether it is a code of conduct or kindness guidelines - anything like
>>> that is something that I welcome as an improvement.
>>>
>>>
>>> Simon
>>
>> +1
>>
>> 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.
>>
>> On the contrary, it gave us a solid foundation to act against the
>> (very few,
>> fortunately) cases of abusive behavior to protect our contributors. As
>> Simon I
>> have seen the damage such behavior can do, and therefore would also
>> welcome
>> tools/rules to be in place to deal with such situations.
>>
>> Regards,
>> Volker
>
> I fully agree.
>
> And btw, we have had a clear majority in favour of adding a CoC at the
> Contributor Summit, and explicitly agreed that a group of people will
> work on creating it. I’m happy we now have a first version, that we can
> use as a basis for further discussions.
>
> Cheers,
> Lars
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org<mailto:***@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

On Thursday, 25 October 2018 03:00:44 PDT NIkolai Marchenko wrote:
> > And btw, we have had a clear majority in favour of adding a CoC at the
>
> Contributor Summit
>
> It seems very wrong to make such decisions at conventions where only a
> small part of the contributors can participate.
> Especially for something as big and divisive

That's why the QtCS consensus are not decisions of the Qt Project. The
decision is left to the mailing list. It is a good indication of support,
however.

The instruction that came out of it was to write the text so the decision
could be made.

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

[Volker Hilsheimer]

> On 25 Oct 2018, at 11:50, Rafael Roquetto <***@roquetto.com> wrote:
> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?


Because not all of us have *observed* issues doesn’t mean that there have not been any issues. This community would not be the first from which people that feel assaulted or disrespected would rather quietly disappear than to raise the concern.


> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.


Having clear communication about what we as a community care about, and what we don’t care about, creates clarity and sets expectations. What you are suggesting is a code of conduct, actually:

“We only care about the quality of your code. You can behave in whichever way you want, and don’t have to fear that the community will sanction you for being yourself.”

That’s a CoC, and if that’s the CoC we want, then we should write it down so that people know what to expect.


> During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made
> sense and improved my code; 3) they were not butt hurt when roles were
> reversed.


So, programming for you has always only been about code, but you wrote a paragraph about how it is about people and their interactions anyway :)

Especially in an Open Source project, coding is a social interaction, and not at all just about bits and bytes. You make pull requests that you want people to review and comment on. You have ideas that you want people to embrace and join. You write code that you want others to use. You want co-contributors that take ownership and responsibility when their changes happen to break your feature. Perhaps you even want to write software that is based on thorough insights into what people struggle with, This requires observing, communicating, and empathizing with your users, before you start hacking.


> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project. But, that is my
> view, and in spite of that, I do hope that in the end I am wrong and
> that the CoC is another step on the right direction. Let's remain
> positive and hope it won't even be necessary to invoke it after all, and
> that respect and common-sense shall prevail.


Common sense is unfortunately not very common.


Cheers,
Volker



> On 10/25/18 5:58 PM, Lars Knoll wrote:
>>> On 25 Oct 2018, at 09:51, Volker Krause via Development
>>> <***@qt-project.org <mailto:***@qt-project.org>> wrote:
>>>
>>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
>>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>>>>
>>>>>
>>>>>
>>>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com
>>>>>> <mailto:***@gmx.com>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In case it needs to be said-
>>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
>>>>>> things. But I am also against people judging other people's code for
>>>>>> factors that have nothing to do with the code itself. I find that
>>>>>> adding
>>>>>> a value judgement of conduct to code to be intolerant. We had the
>>>>>> ideal.
>>> I am FOR inclusion. I want everyone to feel welcome here.
>>>>>> Everyone.>
>>>>> I agree. It seems to be about fixing something that isn’t broken, or as
>>>>> in that story in the Bible where the people came to a consensus that
>>>>> every other country around them had a king, so they should have a king
>>>>> too. Nothing good came out of it in any cases where we have seen this
>>>>> kind of illogic applied. “Most other big corporations have a deep
>>>>> hierarchy of management, with too much power concentrated at the
>>>>> top, and
>>>>> we want to be a big corporation, so we need to replicate that.” “The
>>>>> other lemmings are running away so maybe we’d better follow.” It’s not
>>>>> the open source way, which seemed to be working well enough already.
>>>>
>>>>>
>>>>>
>>>>> If you give power to a committee of 3 people, they will probably
>>>>> abuse it
>>>>> eventually, misjudge, cause bitterness, create factions, and some
>>>>> developers will end up walking away. Seems predictable, doesn’t it?
>>>>
>>>>>
>>>>
>>>>
>>>> You claim that this is about fixing something that isn't broken. Your
>>>> statement that a committee will predictably and eventually abuse their
>>>> powers and misjudge is, I feel, a
>>>>
>>>> statement that is spreading fear, doubt and uncertainty, without any
>>>> evidence within the scope of this community.
>>>>
>>>>
>>>> On the other hand I am aware of at least one concrete case where the
>>>> behavior of a reviewer has caused a contributor (with a track record of
>>>> accepted patches, btw) to
>>>>
>>>> turn away from the project and even resulted in an email of complaint
>>>> sent to the community manager. The lack of tools, written understanding
>>>> and common agreement
>>>>
>>>> on what is good behavior resulted in that nothing happened at all and
>>>> the contributor in question has stayed away from the project since then.
>>>>
>>>>
>>>> I do think that this is the exception, but it is crucial that we have
>>>> the right tools and mechanisms in place when unlikely exceptions happen,
>>>> in order to deal with them
>>>>
>>>> instead of ignoring them. After having seen this with my own eyes, I am
>>>> convinced of that.
>>>>
>>>>
>>>> Whether it is a code of conduct or kindness guidelines - anything like
>>>> that is something that I welcome as an improvement.
>>>>
>>>>
>>>> Simon
>>>
>>> +1
>>>
>>> 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.
>>>
>>> On the contrary, it gave us a solid foundation to act against the
>>> (very few,
>>> fortunately) cases of abusive behavior to protect our contributors. As
>>> Simon I
>>> have seen the damage such behavior can do, and therefore would also
>>> welcome
>>> tools/rules to be in place to deal with such situations.
>>>
>>> Regards,
>>> Volker
>>
>> I fully agree.
>>
>> And btw, we have had a clear majority in favour of adding a CoC at the
>> Contributor Summit, and explicitly agreed that a group of people will
>> work on creating it. I’m happy we now have a first version, that we can
>> use as a basis for further discussions.
>>
>> Cheers,
>> Lars
>>
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Robin Burchell]

On Thu, Oct 25, 2018, at 11:50 AM, Rafael Roquetto wrote:
> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?

The problem with that question is that by the time you need to _solve_ something, or prevent it from happening _again_, it has already happened. The point of a code of conduct as I understand it is that it is supposed to help prevent situations from arising/escalating out of control in the first place, and if that ever does happen, provide a process to resolve it in a well defined (and ideally, minimally damaging) way.

[ As an aside, I've seen communities go very bad - with or without a code of conduct - so the "code" alone won't save you- at the end of the day, it's all down to you, me, and everyone here to do the right thing and make this place a good one. ]

> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.

I will first acknowledge that I am in a privileged position - I've never been on the bad end of any sort of discrimination - and for those that have been, or worse, are systematically in that position, it is much harder for them to effect any real change to that without the clear capability to show that this sort of thing is not OK.

With that having been said: my own personal stance is that I would _like_ it to be possible for this stuff to not be needed. I would _like_ people to be smart enough to understand that they should do, or not do, certain things in order to cooperate and "get on". But everyone is different, after all, and a common sense of "correct" is not necessarily as common as we might think, or hope.

So while I don't personally find it necessary, I do try put myself in the shoes of someone less "fortunate" than myself while considering it.

What do you do if you are certain that your contributions are being ignored not because of technical merits, but because of [ your own ] personal characteristics? Without a clear guideline of how that sort of a situation is approached, the only real answer is, simply, "you stop contributing". Which is a losing proposition: the community loses a potentially valuable contributor, at the cost of a toxic environment that is not at all based around technical merit - the exact opposite of what we want to happen, I'd say.

> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project.

I tried to spell this out, but I think it needs repeating. In my view, a code of conduct is not a political tool, nor a legal document (if it is done well). It is a codified form of what is acceptable to the project, which at the purest form might be: contributions good from all comers of all types, and if bad things happen, here's how they are resolved.

--
Robin Burchell
***@crimson.no

[Simon Hausmann]

Am 25.10.18 um 11:50 schrieb Rafael Roquetto:
> I understand this has already been set in stone, and I am not here in
> the hopes this will change. However, I do feel like I should voice my
> own humble opinion - perhaps it can be useful, or maybe not...


Your feedback is most certainly useful. (at least in my humble opinion ;-)


> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix? That is not to say problems never happened, but
> these things have side effects - sometimes the most unintended ones. As
> C++ programmers, we should know well that unintended side-effects
> steaming from well-intentioned constructs are no exception (pun intended).


You're right, there can be side-effects. We have to be careful about those,

as much as we have to be careful to address the situation of uncaught

exceptions. Those terminating the process of contribution and potentially

causing further side-effects is what this is trying to "fix" or at least
attempt

to improve.


I think the best way to minimize the side effects you may be concerned about

is to ensure that the wording emphasizes the desire for a positive
environment

(for the purpose of reasoning) and also frames the part of handling
violations

as a last resort, as something that should be the exception.


If, on the other hand, a CoC is not used as a last resort but at the
beginning of

every slight misunderstanding, then we would perhaps have failed.


This is where input from other projects that have had a CoC, such as KDE, is

beneficial in assessing the risks.


> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?


As I also said in my earlier email, I'm aware of at least one case

where terrible behavior resulted in a contributor with track record

of patches being turned away and no consequence for the person

responsible for it. That is unjust and I think doing _something_ about it

is better than us - the community - keeping quiet and sweeping these

exceptions under the carpet. The sweeping under the carpet, _that_ is

what we must prevent from happening again.


What are your thoughts about that?


>
> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.


I think it should be like that, at the heart of it.


On the other hand much has happened in the world since the early

days of free software projects. A much larger part of the population

on the planet has access to the internet and education that makes it

possible for them to join our community. I think that is a fantastic

opportunity. It means that people different backgrounds, different cultures

and different upbrinings are able to join. We must assume good faith,

but we should be prepared to be able to explain what we would perhaps

consider "common sense" in terms of behavior. A well worded document

may be of tremendous help.


This is one aspect I really like about the GNU Kind Communications
Guidelines

as an alternative. It's _something_ more than what we have today.


> During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made
> sense and improved my code; 3) they were not butt hurt when roles were
> reversed.
>
> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project. But, that is my
> view, and in spite of that, I do hope that in the end I am wrong and
> that the CoC is another step on the right direction. Let's remain
> positive and hope it won't even be necessary to invoke it after all, and
> that respect and common-sense shall prevail.
>

Calm and well formulated emails like yours help big time to maintain

a positive attitude in this discussion and increase chances of a good

result for the project - thank you :)



Simon


> - Rafael
>
> PS: if you have read this far (sorry!), you may also be interested in
> donating a tad more of your time and help with reviewing this
>
> https://codereview.qt-project.org/#/c/241598/
>
> ;)
>
>
> On 10/25/18 5:58 PM, Lars Knoll wrote:
>>> On 25 Oct 2018, at 09:51, Volker Krause via Development
>>> <***@qt-project.org <mailto:***@qt-project.org>> wrote:
>>>
>>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
>>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>>>>
>>>>>
>>>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com
>>>>>> <mailto:***@gmx.com>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In case it needs to be said-
>>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
>>>>>> things. But I am also against people judging other people's code for
>>>>>> factors that have nothing to do with the code itself. I find that
>>>>>> adding
>>>>>> a value judgement of conduct to code to be intolerant. We had the
>>>>>> ideal.
>>> I am FOR inclusion. I want everyone to feel welcome here.
>>>>>> Everyone.>
>>>>> I agree.  It seems to be about fixing something that isn’t broken, or as
>>>>> in that story in the Bible where the people came to a consensus that
>>>>> every other country around them had a king, so they should have a king
>>>>> too.  Nothing good came out of it in any cases where we have seen this
>>>>> kind of illogic applied.  “Most other big corporations have a deep
>>>>> hierarchy of management, with too much power concentrated at the
>>>>> top, and
>>>>> we want to be a big corporation, so we need to replicate that.”  “The
>>>>> other lemmings are running away so maybe we’d better follow.”  It’s not
>>>>> the open source way, which seemed to be working well enough already.
>>>>>
>>>>> If you give power to a committee of 3 people, they will probably
>>>>> abuse it
>>>>> eventually, misjudge, cause bitterness, create factions, and some
>>>>> developers will end up walking away.  Seems predictable, doesn’t it?
>>>>
>>>> You claim that this is about fixing something that isn't broken. Your
>>>> statement that a committee will predictably and eventually abuse their
>>>> powers and misjudge is, I feel, a
>>>>
>>>> statement that is spreading fear, doubt and uncertainty, without any
>>>> evidence within the scope of this community.
>>>>
>>>>
>>>> On the other hand I am aware of at least one concrete case where the
>>>> behavior of a reviewer has caused a contributor (with a track record of
>>>> accepted patches, btw) to
>>>>
>>>> turn away from the project and even resulted in an email of complaint
>>>> sent to the community manager. The lack of tools, written understanding
>>>> and common agreement
>>>>
>>>> on what is good behavior resulted in that nothing happened at all and
>>>> the contributor in question has stayed away from the project since then.
>>>>
>>>>
>>>> I do think that this is the exception, but it is crucial that we have
>>>> the right tools and mechanisms in place when unlikely exceptions happen,
>>>> in order to deal with them
>>>>
>>>> instead of ignoring them. After having seen this with my own eyes, I am
>>>> convinced of that.
>>>>
>>>>
>>>> Whether it is a code of conduct or kindness guidelines - anything like
>>>> that is something that I welcome as an improvement.
>>>>
>>>>
>>>> Simon
>>> +1
>>>
>>> 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.
>>>
>>> On the contrary, it gave us a solid foundation to act against the
>>> (very few,
>>> fortunately) cases of abusive behavior to protect our contributors. As
>>> Simon I
>>> have seen the damage such behavior can do, and therefore would also
>>> welcome
>>> tools/rules to be in place to deal with such situations.
>>>
>>> Regards,
>>> Volker
>> I fully agree.
>>
>> And btw, we have had a clear majority in favour of adding a CoC at the
>> Contributor Summit, and explicitly agreed that a group of people will
>> work on creating it. I’m happy we now have a first version, that we can
>> use as a basis for further discussions.
>>
>> Cheers,
>> Lars
>>
>>
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[NIkolai Marchenko]

> This community would not be the first from which people that feel
assaulted or disrespected would rather quietly disappear than to raise the
concern.

Innocent until proved guilty. This statement is hearsay in the context of
this particular project, whereas there were already accounts of people
saying a certain amount of "rudeness" never was a problem for them.
I could also try to argue the case that thesame amount of ppl will leave
quitely because their style of communication is explicitly prohibited by
the code and they don't want to change it.

On Thu, Oct 25, 2018 at 1:33 PM Simon Hausmann <***@qt.io> wrote:

>
> Am 25.10.18 um 11:50 schrieb Rafael Roquetto:
> > I understand this has already been set in stone, and I am not here in
> > the hopes this will change. However, I do feel like I should voice my
> > own humble opinion - perhaps it can be useful, or maybe not...
>
>
> Your feedback is most certainly useful. (at least in my humble opinion ;-)
>
>
> > I would like to start by saying I fully agree with Shawn: what exactly
> > are we trying to fix? That is not to say problems never happened, but
> > these things have side effects - sometimes the most unintended ones. As
> > C++ programmers, we should know well that unintended side-effects
> > steaming from well-intentioned constructs are no exception (pun
> intended).
>
>
> You're right, there can be side-effects. We have to be careful about those,
>
> as much as we have to be careful to address the situation of uncaught
>
> exceptions. Those terminating the process of contribution and potentially
>
> causing further side-effects is what this is trying to "fix" or at least
> attempt
>
> to improve.
>
>
> I think the best way to minimize the side effects you may be concerned
> about
>
> is to ensure that the wording emphasizes the desire for a positive
> environment
>
> (for the purpose of reasoning) and also frames the part of handling
> violations
>
> as a last resort, as something that should be the exception.
>
>
> If, on the other hand, a CoC is not used as a last resort but at the
> beginning of
>
> every slight misunderstanding, then we would perhaps have failed.
>
>
> This is where input from other projects that have had a CoC, such as KDE,
> is
>
> beneficial in assessing the risks.
>
>
> > So I will go back to my question: what is it we are trying to solve? Or
> > rather, what is it that happened, that we are trying to prevent from
> > happening again? There will always be lunatics, and a CoC won't stop
> > them. Perhaps it will improve things... but... perhaps it will do more
> > harm than good. Or is it proven technology?
>
>
> As I also said in my earlier email, I'm aware of at least one case
>
> where terrible behavior resulted in a contributor with track record
>
> of patches being turned away and no consequence for the person
>
> responsible for it. That is unjust and I think doing _something_ about it
>
> is better than us - the community - keeping quiet and sweeping these
>
> exceptions under the carpet. The sweeping under the carpet, _that_ is
>
> what we must prevent from happening again.
>
>
> What are your thoughts about that?
>
>
> >
> > Which brings to my second point, a very personal one: more or less in
> > line with what Jason said, programming *to me* has always been about
> > bits and bytes, about the code, about computers, about being able to
> > make things appear on the screen and to control the machine. Free
> > Software has been about.... free software and that's it. I find it
> > extremely off-putting to see that the Qt project is embarking in this
> > sort of politics - again, if things were broken and a CoC could fix
> > them, I would be more than happy to join the train, but that doesn't
> > seem to be the case. At least from my humble perspective.
>
>
> I think it should be like that, at the heart of it.
>
>
> On the other hand much has happened in the world since the early
>
> days of free software projects. A much larger part of the population
>
> on the planet has access to the internet and education that makes it
>
> possible for them to join our community. I think that is a fantastic
>
> opportunity. It means that people different backgrounds, different cultures
>
> and different upbrinings are able to join. We must assume good faith,
>
> but we should be prepared to be able to explain what we would perhaps
>
> consider "common sense" in terms of behavior. A well worded document
>
> may be of tremendous help.
>
>
> This is one aspect I really like about the GNU Kind Communications
> Guidelines
>
> as an alternative. It's _something_ more than what we have today.
>
>
> > During all these years contributing to Qt I have encountered many times
> > strong criticism in gerrit - some people were very harsh or *seemingly*
> > rude - or that was what I thought, until I realized that: 1) it was just
> > their modus operandi; 2) at the end of the day, their comments made
> > sense and improved my code; 3) they were not butt hurt when roles were
> > reversed.
> >
> > Communication/criticism just like this is unambiguously straightforward
> > and I *personally* prefer it this way. Unfortunately I could not make it
> > to the QtCS, but had I been there, I would have voted against the CoC,
> > for sure. I hate to see politics tainting the project. But, that is my
> > view, and in spite of that, I do hope that in the end I am wrong and
> > that the CoC is another step on the right direction. Let's remain
> > positive and hope it won't even be necessary to invoke it after all, and
> > that respect and common-sense shall prevail.
> >
>
> Calm and well formulated emails like yours help big time to maintain
>
> a positive attitude in this discussion and increase chances of a good
>
> result for the project - thank you :)
>
>
>
> Simon
>
>
> > - Rafael
> >
> > PS: if you have read this far (sorry!), you may also be interested in
> > donating a tad more of your time and help with reviewing this
> >
> > https://codereview.qt-project.org/#/c/241598/
> >
> > ;)
> >
> >
> > On 10/25/18 5:58 PM, Lars Knoll wrote:
> >>> On 25 Oct 2018, at 09:51, Volker Krause via Development
> >>> <***@qt-project.org <mailto:***@qt-project.org>>
> wrote:
> >>>
> >>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
> >>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
> >>>>
> >>>>>
> >>>>>> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com
> >>>>>> <mailto:***@gmx.com>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> In case it needs to be said-
> >>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
> >>>>>> things. But I am also against people judging other people's code for
> >>>>>> factors that have nothing to do with the code itself. I find that
> >>>>>> adding
> >>>>>> a value judgement of conduct to code to be intolerant. We had the
> >>>>>> ideal.
> >>> I am FOR inclusion. I want everyone to feel welcome here.
> >>>>>> Everyone.>
> >>>>> I agree. It seems to be about fixing something that isn’t broken,
> or as
> >>>>> in that story in the Bible where the people came to a consensus that
> >>>>> every other country around them had a king, so they should have a
> king
> >>>>> too. Nothing good came out of it in any cases where we have seen
> this
> >>>>> kind of illogic applied. “Most other big corporations have a deep
> >>>>> hierarchy of management, with too much power concentrated at the
> >>>>> top, and
> >>>>> we want to be a big corporation, so we need to replicate that.” “The
> >>>>> other lemmings are running away so maybe we’d better follow.” It’s
> not
> >>>>> the open source way, which seemed to be working well enough already.
> >>>>>
> >>>>> If you give power to a committee of 3 people, they will probably
> >>>>> abuse it
> >>>>> eventually, misjudge, cause bitterness, create factions, and some
> >>>>> developers will end up walking away. Seems predictable, doesn’t it?
> >>>>
> >>>> You claim that this is about fixing something that isn't broken. Your
> >>>> statement that a committee will predictably and eventually abuse their
> >>>> powers and misjudge is, I feel, a
> >>>>
> >>>> statement that is spreading fear, doubt and uncertainty, without any
> >>>> evidence within the scope of this community.
> >>>>
> >>>>
> >>>> On the other hand I am aware of at least one concrete case where the
> >>>> behavior of a reviewer has caused a contributor (with a track record
> of
> >>>> accepted patches, btw) to
> >>>>
> >>>> turn away from the project and even resulted in an email of complaint
> >>>> sent to the community manager. The lack of tools, written
> understanding
> >>>> and common agreement
> >>>>
> >>>> on what is good behavior resulted in that nothing happened at all and
> >>>> the contributor in question has stayed away from the project since
> then.
> >>>>
> >>>>
> >>>> I do think that this is the exception, but it is crucial that we have
> >>>> the right tools and mechanisms in place when unlikely exceptions
> happen,
> >>>> in order to deal with them
> >>>>
> >>>> instead of ignoring them. After having seen this with my own eyes, I
> am
> >>>> convinced of that.
> >>>>
> >>>>
> >>>> Whether it is a code of conduct or kindness guidelines - anything like
> >>>> that is something that I welcome as an improvement.
> >>>>
> >>>>
> >>>> Simon
> >>> +1
> >>>
> >>> 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.
> >>>
> >>> On the contrary, it gave us a solid foundation to act against the
> >>> (very few,
> >>> fortunately) cases of abusive behavior to protect our contributors. As
> >>> Simon I
> >>> have seen the damage such behavior can do, and therefore would also
> >>> welcome
> >>> tools/rules to be in place to deal with such situations.
> >>>
> >>> Regards,
> >>> Volker
> >> I fully agree.
> >>
> >> And btw, we have had a clear majority in favour of adding a CoC at the
> >> Contributor Summit, and explicitly agreed that a group of people will
> >> work on creating it. I’m happy we now have a first version, that we can
> >> use as a basis for further discussions.
> >>
> >> Cheers,
> >> Lars
> >>
> >>
> >> _______________________________________________
> >> Development mailing list
> >> ***@qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> >>
> > _______________________________________________
> > Development mailing list
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Edward Welbourne]

Rafael Roquetto (25 October 2018 11:50)
> I understand this has already been set in stone,

I do not think you should take that for granted. We do have a process
by which all contributors can contribute to the decision and should be
listened to, so that the resulting decision can be shaped by any and all
of us.

> and I am not here in the hopes this will change.

Speak and know you are heard.
Persuasion is possible.

> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix?

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
will be made to relieve it. Various variations and permutations on
these themes may also be relevant; see Simon's mail.

> That is not to say problems never happened, but these things have side
> effects - sometimes the most unintended ones. As C++ programmers, we
> should know well that unintended side-effects steaming from
> well-intentioned constructs are no exception (pun intended).

This is why we takes care about designing things and invite review.
Which is exactly the process you see before you.

> Or is it proven technology?

See Volker's earlier post: KDE (among other communities) has been
using a CoC for some time and has (on the thankfully rare occasions
that it's mattered) found it does indeed work. Proof enough ?

It's clearly possible to get a code of conduct wrong; we need to take
care to avoid making those mistakes. It may be possible that a code of
conduct wouldn't be any help in *this* community, 'though it has been in
diverse others; if you believe that is the case, make the case for it.
Some of us, at least, shall listen.

> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it.

Nothing is ever so simple: projects that fail to be welcoming to
contributors get fewer contributions.

> I find it extremely off-putting to see that the Qt project is
> embarking in this sort of politics

I'm not sure why you see it as politics, or what you mean by "politics".
It's part of governance, ensuring we do have oversight of a process that
surely does happen informally anyway - if I see another reviewer being
(IMO) rude to a contributor I have been known to take that up with the
reviewer, on my own initiative; but I might be out of line (I have no
expertise in this area) in doing so, or might not go about it in the
most constructive way; and I have no authority, so the reviewer might
not pay attention to my poking. Having a Conduct Committee who
(hopefully) have some clue about how to diplomatically invite someone to
be gentler to their peers would be an improvement over my informal (and
arguably also rude) attempt to deal with what I perceive as rude; it
might also ensure that a consistent standard is applied for what *does*
constitute rudery.

> - again, if things were broken and a CoC could fix them, I would be
> more than happy to join the train, but that doesn't seem to be the
> case. At least from my humble perspective.

I have seen a contributor despair at a reviewer, who they felt was being
unfair, and give up on contributing. I have felt similarly about one
reviewer, from time to time.

> During all these years contributing to Qt I have encountered many
> times strong criticism in gerrit - some people were very harsh or
> *seemingly* rude - or that was what I thought,

Note that some folk aren't going to get past that.
The distinction between seeming rude and being rude is rather thin.

You and I have the confidence to stand up to rudery and get past the
initial impression to get constructive results despite it, but some folk
do get put off by it and we do lose their contributions as a result.
I have seen this happen. IIU Simon correctly, he has too.

> until I realized that: 1) it was just their modus operandi;

That may be: but if they learn to be at least somewhat friendly about
it, they're less likely to scare off contributors. There should be no
need for someone to tolerate intimidating conduct before they can get
the good that is in their code recognised and, after any needed
improvements, put to use.

> 2) at the end of the day, their comments made sense and improved my
> code;

That is nice, but surely it would be better if they could steer you
towards those improvements *without* making you uncomfortable on the
way. In particular, for some potential contributors, that makes the
difference between getting their contribution in and giving up; and a
kinder process might leave more contributors eager to come back with
further contributions, where an intimidating one is apt to discourage
them from attempting further contributions.

> 3) they were not butt hurt when roles were reversed.

I do not find that an adequate excuse. Certainly, if they *were* upset
they'd be guilty of hypocrisy. The fact that they can cope with abusive
treatment isn't any kind of justification for dishing such treatment out
to others. It is better to actually be considerate towards those whose
code one reviews.

I remember school-mates being singularly rude to each other all the
time. Notably, on the football pitch, they threw about a barrage of
insult, demand and blame - at their own team-mates, note - that made it
unpleasant to play with them. In competitive leagues, being a small boy
(until late in my time at school) and not much liked by the ones who got
to pick teams, I got to be assigned to a team consisting mostly of boys
a year younger; who, by virtue of my age, treated me with at least
somewhat more respect; so I was quite happy to not be picked to be in
the team of my peers, though I got dragged in enough times to see how
they treated one another (and me, but that's how they always treated
me). Eventually, once I'd grown and become rather good at what I did,
my peers felt they should condescend to let me play in their team; but I
declined, because I did not enjoy playing in the abusive environment
they generated. This left me in a team of (mostly) younger boys, so I
had to be captain, despite that being normally a forward's job, not a
centre-back's. My first rule was that my team were not allowed to be
rude to one another or blame each other for things that didn't go our
way; we were on the playing field to get some exercise and have some
fun; if we could also win, so much the better. This soon lead to a team
that was enjoying playing and worked together better than most of the
teams of our peers that we came up against. Despite being "less able"
players in the fairly objective terms of various teachers, this team
beat teams of "better" players because they were crushing their own
team-mates' morale, while we were having fun (at their expense).
That included sincerely congratulating them when they played well.

In an abusive environment, the thick-skinned bullies rise to the top and
keep the place abusive, so that their kind keeps on winning. In a more
respectful environment, folk who treat others with respect gain respect
and, feeling respected, are more able to deliver useful results. I
think this community is considerably closer to the latter than the
former, but the exact experience you describe is a shadow of the former,
that I'd gladly banish.

The questions I want addressed are:
* Will a CoC help ?
* If so *what* CoC do we want ? and
* What surrounding process will lead to respectful resolution of such
conflicts as do arise around the CoC ?

> Communication/criticism just like this is unambiguously
> straightforward and I *personally* prefer it this way.

Would you prefer it yet more if you were treated more gracefully, even
when someone is pointing out your errors ?

Eddy.

[Robert Loehning]

Am 25.10.2018 um 09:58 schrieb Lars Knoll:
> And btw, we have had a clear majority in favour of adding a CoC at the Contributor Summit, and explicitly agreed that a group of people will work on creating it. I’m happy we now have a first version, that we can use as a basis for further discussions.
>

Hi all,

to be precise: We had a clear majority of the people who voted in this
session. This might or might not correlate with a majority of the
project's members.

Cheers,
Robert

[Thiago Macieira]

On Thursday, 25 October 2018 03:05:04 PDT Robert Loehning wrote:
> Am 25.10.2018 um 09:58 schrieb Lars Knoll:
> > And btw, we have had a clear majority in favour of adding a CoC at the
> > Contributor Summit, and explicitly agreed that a group of people will
> > work on creating it. I’m happy we now have a first version, that we can
> > use as a basis for further discussions.
> Hi all,
>
> to be precise: We had a clear majority of the people who voted in this
> session. This might or might not correlate with a majority of the
> project's members.

Let me just be clear: this was not a vote. It was a straw poll, to gather the
attendees' opinion.

The Qt Project has no voting. All decisions are made by consensus wherever
possible, and failing to achieve that, we have an escalation route all the way
to the Chief Maintainer. Please note point 3 of RFC 7282[1], which describes
IETF's Consensus mechanism:

Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated

[1] https://tools.ietf.org/html/rfc7282
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Konstantin Tokarev]

25.10.2018, 20:56, "Thiago Macieira" <***@intel.com>:
> The Qt Project has no voting.

Nitpick: there is voting in privilege revocation procedure.

--
Regards,
Konstantin

[Alexey Andreyev]

Hello! Young Qt fanboy, who worried about the future of the project:

What problems are CoC trying to solve?
Abusive behaviour?

People are not social angels at all.
But how many situations of problematic behaviour at the Qt project do
we have with current terms?
When it's ruined some tasks we still could not solve? Could it be
compared to the successful situations?
Is the relative number a zero, one-two, ten, hundred?
Is the value grows, fixed or decreases somehow? Are there some
internal and external reasons?

Are CoC helping for other similar projects? Is there any research?

I agree we should have defined common values as a community. And I
want to contribute too.
I guess we should think twice at least about new fancy CoC. I'm happy
that nobody is forcing hard it for now.
I like the discussion at codereview.

From my point of view, some rude words could be filtered automatically
or semi-automatically if we want to
and it's not a huge problem. So let's skip all the cases when it's
just about swearing for now.

Let's focus on situations, when conflict is about the meaning of the sentences.

It's the case about ideology (a system of ideas and ideals, something
opposite to science in some terms, but something completing it to form
a community). From my point of view, our speech probably could not be
ideology-free.
And it's not some bad thing we should get rid of, ideology instead
should help community to develop and survive as a single whole.
Some "let's be free from well-defined ideology" is just yet another ideology.

So about ideology point CoC is trying to provide: I could see it for
now as "let's forbid "non-constructive" negative feedback and everyone
will be happy" (feel free to correct me).
My problem with that is that focusing on "negative feedback" as
absolute evil ("non-constructive" is practically not the key, because
it's not well defined).

I guess we could all agree that some "sweet" feedback could ruin the
community as easy as "direct offensive" feedback, if not faster. So do
we really want to somehow restrict negative side of feedback without
limiting positive? Is it practically possible to do it for the health
of the community?

Feel free to criticize me or skip a message if it's inappropriate. And
thank you for your time!
Sorry for a spelling, I'm not a native speaker.

2018-10-25 10:58 GMT+03:00, Lars Knoll <***@qt.io>:
> On 25 Oct 2018, at 09:51, Volker Krause via Development
> <***@qt-project.org<mailto:***@qt-project.org>> wrote:
>
> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>
>
>
> On 24 Oct 2018, at 17:09, Jason H <***@gmx.com<mailto:***@gmx.com>>
> wrote:
>
>
>
> In case it needs to be said-
> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
> things. But I am also against people judging other people's code for
> factors that have nothing to do with the code itself. I find that adding
> a value judgement of conduct to code to be intolerant. We had the
> ideal.
> I am FOR inclusion. I want everyone to feel welcome here.
> Everyone.>
> I agree. It seems to be about fixing something that isn’t broken, or as
> in that story in the Bible where the people came to a consensus that
> every other country around them had a king, so they should have a king
> too. Nothing good came out of it in any cases where we have seen this
> kind of illogic applied. “Most other big corporations have a deep
> hierarchy of management, with too much power concentrated at the top, and
> we want to be a big corporation, so we need to replicate that.” “The
> other lemmings are running away so maybe we’d better follow.” It’s not
> the open source way, which seemed to be working well enough already.
>
>
>
> If you give power to a committee of 3 people, they will probably abuse it
> eventually, misjudge, cause bitterness, create factions, and some
> developers will end up walking away. Seems predictable, doesn’t it?
>
>
>
>
> You claim that this is about fixing something that isn't broken. Your
> statement that a committee will predictably and eventually abuse their
> powers and misjudge is, I feel, a
>
> statement that is spreading fear, doubt and uncertainty, without any
> evidence within the scope of this community.
>
>
> On the other hand I am aware of at least one concrete case where the
> behavior of a reviewer has caused a contributor (with a track record of
> accepted patches, btw) to
>
> turn away from the project and even resulted in an email of complaint
> sent to the community manager. The lack of tools, written understanding
> and common agreement
>
> on what is good behavior resulted in that nothing happened at all and
> the contributor in question has stayed away from the project since then.
>
>
> I do think that this is the exception, but it is crucial that we have
> the right tools and mechanisms in place when unlikely exceptions happen,
> in order to deal with them
>
> instead of ignoring them. After having seen this with my own eyes, I am
> convinced of that.
>
>
> Whether it is a code of conduct or kindness guidelines - anything like
> that is something that I welcome as an improvement.
>
>
> Simon
>
> +1
>
> 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.
>
> On the contrary, it gave us a solid foundation to act against the (very
> few,
> fortunately) cases of abusive behavior to protect our contributors. As Simon
> I
> have seen the damage such behavior can do, and therefore would also welcome
> tools/rules to be in place to deal with such situations.
>
> Regards,
> Volker
>
> I fully agree.
>
> And btw, we have had a clear majority in favour of adding a CoC at the
> Contributor Summit, and explicitly agreed that a group of people will work
> on creating it. I’m happy we now have a first version, that we can use as a
> basis for further discussions.
>
> Cheers,
> Lars
>
>

[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'

[Laszlo Agocs]

Fully agree. Is it really necessary to dedicate ca. half of the proposed document to sections full of "enforcement", "ban", "violation", "danger", etc., which in the end leads to creating an overly dark and bureaucratic vibe?

Laszlo

________________________________
From: Development <development-bounces+laszlo.agocs=***@qt-project.org> on behalf of André Pönitz <***@t-online.de>
Sent: Thursday, October 25, 2018 7:39 PM
To: Volker Krause
Cc: ***@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

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'

[Jason H]

+1 this. I have no problems with the KDE CoC.


> Sent: Thursday, October 25, 2018 at 1:39 PM
> From: "André Pönitz" <***@t-online.de>
> To: "Volker Krause" <***@kdab.com>
> Cc: ***@qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> 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'
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Konstantin Shegunov]

+1 for the KDE CoC from me as well.
Better written, clearer and to the point.

On Thu, Oct 25, 2018 at 8:40 PM André Pönitz <***@t-online.de> 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. 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'
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Oliver Wolff]

+1 from here as well. I also think that the proposed document (and
especially the "enforcement" part) is way too long


On 25/10/2018 19:39, 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. 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'
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[Ulf Hermann]

On 10/26/18 9:05 AM, Oliver Wolff wrote:
> +1 from here as well. I also think that the proposed document (and
> especially the "enforcement" part) is way too long

The KDE CoC [1] does not specify any action to be taken when it's
violated. That's the main reason why it seems shorter. If you only
consider the equivalent sections in our proposed CoC, the KDE one is
actually much longer. That said, I wouldn't mind replacing the "Our
Pledge" and "Our Standards" paragraphs in the current proposal with the
KDE CoC if that helps with acceptance here.

But, how does this actually work in practice at KDE? Is there another
document that states what they do if someone oversteps the boundaries?
There isn't even a contact email in their CoC. So, if someone was
slapping me around with a large fish in the KDE IRC channel, I still
wouldn't know what to do about it.

Ulf

[1] https://www.kde.org/code-of-conduct/

[Oliver Wolff]

On 26/10/2018 09:18, Ulf Hermann wrote:
> On 10/26/18 9:05 AM, Oliver Wolff wrote:
>> +1 from here as well. I also think that the proposed document (and
>> especially the "enforcement" part) is way too long
> The KDE CoC [1] does not specify any action to be taken when it's
> violated. That's the main reason why it seems shorter. If you only
> consider the equivalent sections in our proposed CoC, the KDE one is
> actually much longer. That said, I wouldn't mind replacing the "Our
> Pledge" and "Our Standards" paragraphs in the current proposal with the
> KDE CoC if that helps with acceptance here.
>
> But, how does this actually work in practice at KDE? Is there another
> document that states what they do if someone oversteps the boundaries?
> There isn't even a contact email in their CoC. So, if someone was
> slapping me around with a large fish in the KDE IRC channel, I still
> wouldn't know what to do about it.
I think it depends on the CoC's main purpose (which we are currently
defining). I'd see it as a behavioral guideline which states how to
interact with other people. It might basically say that we treat each
other with respect and are not assholes (pardon the french). If a
(potential) contributor reads these, he will get the idea and know, what
collaboration in the project will (ideally) be like.

By filling that guideline with technicalities and punishments we take
away that positive vibe and create a more threatening atmosphere.
Additionally it lengthens the core document (unnessecarily in my eyes).
Enforcement and punishments are mere technicalities which can be
"hidden" in another document. The code of conduct should describe the
generic ways of working together for every day, while the additional
document of punishment will only be used rarely and thus can be "hidden"
a bit. I still think and hope that there will not be too many cases
where the CoC police will have to intervene.

Just my 2 cents,
Olli

>
> Ulf
>
> [1] https://www.kde.org/code-of-conduct/
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

[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/

[Christian Kandeler]

On Thu, 25 Oct 2018 19:39:45 +0200
André Pönitz <***@t-online.de> 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

[Jason H]

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" <***@qt.io>
> To: "***@qt-project.org" <***@qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> On Thu, 25 Oct 2018 19:39:45 +0200
> André Pönitz <***@t-online.de> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[NIkolai Marchenko]

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 <***@gmx.com> 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" <***@qt.io>
> > To: "***@qt-project.org" <***@qt-project.org>
> > Subject: Re: [Development] QUIP 12: Code of Conduct
> >
> > On Thu, 25 Oct 2018 19:39:45 +0200
> > André Pönitz <***@t-online.de> 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
> > ***@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Jason H]

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

[NIkolai Marchenko]

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 <***@gmx.com> 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 <https://github.com/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
> <https://github.com/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" <***@gmail.com>
> *To:* ***@gmx.com
> *Cc:* "Christian Kandeler" <***@qt.io>, "Qt development
> mailing list" <***@qt-project.org>
> *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 <***@gmx.com> 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" <***@qt.io>
>> > To: "***@qt-project.org" <***@qt-project.org>
>> > Subject: Re: [Development] QUIP 12: Code of Conduct
>> >
>> > On Thu, 25 Oct 2018 19:39:45 +0200
>> > André Pönitz <***@t-online.de> 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
>> > ***@qt-project.org
>> > http://lists.qt-project.org/mailman/listinfo/development
>> >
>> _______________________________________________
>> Development mailing list
>> ***@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>

[Jason H]

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

[Thiago Macieira]

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

[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

[NIkolai Marchenko]

> 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 <***@intel.com>
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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

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

[NIkolai Marchenko]

> 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 <***@intel.com>
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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Jason H]

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" <***@intel.com>
> To: ***@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.

[Thiago Macieira]

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

[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 <***@intel.com>:

> 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
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[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

[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.

[Konstantin Shegunov]

I think you're over-engineering the whole thing and you don't drive the
point of such a document home. My best suggestion is to simplify (heavily)
the process and the phrasing.

Firstly and most importantly drop the heavy and redundant wording, e.g. "
... pledge to making participation in our project and our community a
harassment-free experience for everyone, regardless of age, body size, ..."
"everyone" is already all those things. Unless your point was to write a
constitution, just state what you mean simply, plainly and succinctly.
Helps in reading, understanding and proceeding to implement. On that note
hardly will I be convinced that a new (or seasoned) contributor waste the
time to read through something that's longer than half a page instead of
diving into the heart of the matter, which is to write code, improve docs
or w/e.

Addendum: There's too much vague phrasing. When I was reading through the
text I read things of the sort:
"Showing empathy towards other community members"
and
"Other conduct which could reasonably be considered inappropriate in a
professional setting"
and what I thought was "What's that nonsense?! empathy?!". What is wrong
with stating it directly - "Don't be mean, respect others."?
Here's what Tero wrote on the boards (shortened the tips about language,
which shrunk it by about 5%-10%) as a guideline for moderators:

*The short moderation and banning guideline for the Qt Forum*
> First, the Qt Community is in general a friendly place. When you applied
> or were called to be a moderator, several other moderators read a good
> section of your posts, and agreed that you are very friendly towards to
> community in addition to being knowledgeable in Qt. Thank you, and keep up
> the friendly attitude!



Always assume that the person asking has a real valid problem. Trolls and
> ranters are very rare here, so it's best to assume that a person sounding
> aggressive is just having a bad day, or that english is their third or
> second language. The language barrier may cause the question to sound
> strange.

[...]

In general the following types of posts will be deleted
> obvious spam
> 'support' phone numbers
> obviously non-Qt services and sites
> backlink spam (spam with links to a completely non-Qt site, with the
> intention of raising search engine rankings)
> swearing
> completely off topic posting
> posting the same question in multiple subforums (remember to post a note
> on the one you leave up)
> Banning is in place when:
> The user posts harmful spam
> Abusive behaviour, swearing and being offensive
>

It's reasonable, short enough, easy to comprehend and apply.

Secondly, that whole committee thing is somewhat of a stretch in my mind.
It's going to be much more practical to have one contact person to "shuffle
the paper" and consider complaints/issues, answering questions about and
for the community, helping newer persons to get on with the program and so
on. Election can be by majority voting ran for a reasonable time period
(say 1 week) from a pool of proposed candidates. Alternatively, as the
community is somewhat dispersed over different media - forums, mailing
lists, IRC and so on a person for each of the channels mentioned can be
elected. On that note the proposed CoC doesn't take into account that
specific, for one we mostly police ourselves in the forum, and I imagine
people have an operator on IRC, but it's not clear how the committee is
supposed to operate on the different channels, are they to be omnipresent?

Thirdly, and I'll stop with my ramblings, there will always be grating
between people that work on something together for extended periods, no
matter if it's a huge C++ library or some triviality. If you try to stop
all of it, what my feeling of the proposed document is, brace yourselves,
you're going to fail miserably. I'd rather suggest handling the extreme
cases only and leave people blow off steam once in a while. Disruptions to
good order are more often than not correctable by a simple private notice.
Or to quote Sze-Howe Koh:

There are 2 ways to ensure that things don't get done in an open project:
>
> 1. Spend so much time molly-coddling everyone such that there is
> little time left to do actual work
> 2. Drive so many (potential) contributors away such that there are few
> people left to do actual work
>
> Somewhere in the middle of these two extremes is the sweet spot where
> people are neither molly-coddled nor driven away, and maximal work gets
> done. That is the spot a project wants to reach.


PS
I don't know why that (half-)political argument about women, hiring,
google, and whatnot, spun off but I see no relevance to the document, nor
did I read anything remotely related to it in the text. So let's drop it,
shall we?

[Ulf Hermann]

On 10/25/18 1:19 AM, Konstantin Shegunov wrote:
> I  think you're over-engineering the whole thing and you don't drive the
> point of such a document home. My best suggestion is to simplify
> (heavily) the process and the phrasing.

The CoC is not only a guide on how to behave, but also a "welcome"
message to new contributors. Therefore, there may be slightly redundant
language in there which specifically addresses people currently
under-represented in the Qt community.

> Secondly, that whole committee thing is somewhat of a stretch in my
> mind. It's going to be much more practical to have one contact person to
> "shuffle the paper" and consider complaints/issues, answering questions
> about and for the community, helping newer persons to get on with the
> program and so on. Election can be by majority voting ran for a
> reasonable time period (say 1 week) from a pool of proposed candidates.
> Alternatively, as the community is somewhat dispersed over different
> media - forums, mailing lists, IRC and so on a person for each of the
> channels mentioned can be elected. On that note the proposed CoC doesn't
> take into account that specific, for one we mostly police ourselves in
> the forum, and I imagine people have an operator on IRC, but it's not
> clear how the committee is supposed to operate on the differen > channels, are they to be omnipresent?

Phrasing this proposal in a water-proof way would require more wording
and a much more complicated process than the current proposal. The CoC
has to withstand conflict, and in a conflict each party will try to find
loop holes.

> Thirdly, and I'll stop with my ramblings, there will always be grating
> between people that work on something together for extended periods, no
> matter if it's a huge C++ library or some triviality. If you try to stop
> all of it, what my feeling of the proposed document is, brace
> yourselves, you're going to fail miserably. I'd rather suggest handling
> the extreme cases only and leave people blow off steam once in a while.
> Disruptions to good order are more often than not correctable by a
> simple private notice.

The Committee has the option of only handing out "a private reprimand"
in case of minor misconduct. See section "Resolutions".

Ulf

[Ulf Hermann]

> Here's what Tero wrote on the boards (shortened the tips about language,
> which shrunk it by about 5%-10%) as a guideline for moderators:
>
> *The short moderation and banning guideline for the Qt Forum*
> First, the Qt Community is in general a friendly place. When you
> applied or were called to be a moderator, several other moderators
> read a good section of your posts, and agreed that you are very
> friendly towards to community in addition to being knowledgeable in
> Qt. Thank you, and keep up the friendly attitude!
>
> Always assume that the person asking has a real valid problem.
> Trolls and ranters are very rare here, so it's best to assume that a
> person sounding aggressive is just having a bad day, or that english
> is their third or second language. The language barrier may cause
> the question to sound strange.
>
>  [...]
>
> In general the following types of posts will be deleted
> obvious spam
> 'support' phone numbers
> obviously non-Qt services and sites
> backlink spam (spam with links to a completely non-Qt site, with the
> intention of raising search engine rankings)
> swearing
> completely off topic posting
> posting the same question in multiple subforums (remember to post a
> note on the one you leave up)
> Banning is in place when:
> The user posts harmful spam
> Abusive behaviour, swearing and being offensive
>
>
> It's reasonable, short enough, easy to comprehend and apply.

Most of the problems listed there are much too harmless to invoke the
code of conduct about them and the "abuse" clause is too vague:

* Spammers of all kinds are generally not long time community members
and will just disappear when you confront them. There is no point in
designing an elaborate process for removing spam. That should just stay
as it is.

* Offtopic and multi-posting is not a thing the Code of Conduct should
cover. The Code of Conduct is for behavior that's actually hurtful to
someone.

* Swearing is one of the things the Committee might handle with a
private reprimand. This is sufficiently covered by the current proposal.

* Abusive behavior is what the code of conduct is actually about and
that needs to be defined in more detail. Hence the more elaborate wording.

Ulf

[Lorn Potter]

On 25/10/18 9:19 am, Konstantin Shegunov wrote:
> Addendum: There's too much vague phrasing. When I was reading through
> the text I read things of the sort:
> "Showing empathy towards other community members"
> and
> "Other conduct which could reasonably be considered inappropriate in a
> professional setting"
> and what I thought was "What's that nonsense?! empathy?!". What is wrong
> with stating it directly - "Don't be mean, respect others."?


Those do not mean the same as 'empathy', which is the "ability to
understand and share the feelings of another", or "put yourself in the
other persons shoes"

I think empathy is a fine word for this, there is nothing vague about it.

[Konstantin Shegunov]

On Thu, Oct 25, 2018 at 1:01 PM Lorn Potter <***@gmail.com> wrote:

> Those do not mean the same as 'empathy', which is the "ability to
> understand and share the feelings of another", or "put yourself in the
> other persons shoes"
>
> I think empathy is a fine word for this, there is nothing vague about it.
>

Okay, let me rephrase then. Is empathy required or needed? If it's neither
required nor needed, then I see no point in even mentioning it. It'd be one
of those pointless redundancies and empty platitudes people seem to be so
fond of these days. More to the point, is me feeling like crap, because
you're feeling under the blues improve your code, or your perception of the
community? I'd have hard time believing it. I'd much rather see people do
right (and you can codify that) by other people than to mess with
the psychobabble.

[Martin Smith]

I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all.

No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint.

martin

________________________________________
From: Development <development-bounces+martin.smith=***@qt-project.org> on behalf of Ulf Hermann <***@qt.io>
Sent: Wednesday, October 24, 2018 9:17:09 AM
To: ***@qt-project.org
Subject: [Development] QUIP 12: Code of Conduct

Hi,

regarding our earlier discussions on a possible Code of Conduct, here as
well as at the Contributors' Summit 2017, I've pushed a QUIP with the
necessary rules and definitions:

https://codereview.qt-project.org/243623

Please review it.

regards,
Ulf

[Alexey Andreyev]

> I suspect that most if not all of the commenters here who object to the
CoC object to the attempt to define unacceptable behavior. It really has to
be decided on a case by case basis, so remove the examples of unacceptable
behavior, and don't attempt to define it at all.

I'm okay to develop the rules. I disagree though to leave an attempt to
define unacceptable or acceptable behavior. What should we leave then?
General recommendation about being conscious and think about future
consequences? It could be written in one sentense. Why do we need the
document then?

> so remove the examples of unacceptable behavior
I agree that just the examples are not helping

> No one can object to the examples of positive behavior. No one can object
to a CoC that simply promotes those positive examples and then establishes
a complaint process and a CoC committee to rule on each complaint.

CoC committee is just a people. They need some agreements how to make
decisions.

чт, 25 Пкт. 2018 г. в 16:17, Martin Smith <***@qt.io>:

> I suspect that most if not all of the commenters here who object to the
> CoC object to the attempt to define unacceptable behavior. It really has to
> be decided on a case by case basis, so remove the examples of unacceptable
> behavior, and don't attempt to define it at all.
>
> No one can object to the examples of positive behavior. No one can object
> to a CoC that simply promotes those positive examples and then establishes
> a complaint process and a CoC committee to rule on each complaint.
>
> martin
>
> ________________________________________
> From: Development <development-bounces+martin.smith=***@qt-project.org>
> on behalf of Ulf Hermann <***@qt.io>
> Sent: Wednesday, October 24, 2018 9:17:09 AM
> To: ***@qt-project.org
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623
>
> Please review it.
>
> regards,
> Ulf
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Martin Smith]

>Why do we need the document then?

We need the document to explain the complaint process and to establish the committee for dealing with complaints.

>CoC committee is just a people. They need some agreements how to make decisions.

We are adults. Despite the apparent tolerance of the bad behavior of Donald Trump, we all know what is bad behavior in this context.

________________________________________
From: Alexey Andreyev <***@gmail.com>
Sent: Thursday, October 25, 2018 3:56:18 PM
To: Martin Smith
Cc: Ulf Hermann; Qt development mailing list
Subject: Re: [Development] QUIP 12: Code of Conduct

> I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all.

I'm okay to develop the rules. I disagree though to leave an attempt to define unacceptable or acceptable behavior. What should we leave then? General recommendation about being conscious and think about future consequences? It could be written in one sentense. Why do we need the document then?

> so remove the examples of unacceptable behavior
I agree that just the examples are not helping

> No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint.

CoC committee is just a people. They need some agreements how to make decisions.

чт, 25 окт. 2018 г. в 16:17, Martin Smith <***@qt.io<mailto:***@qt.io>>:
I suspect that most if not all of the commenters here who object to the CoC object to the attempt to define unacceptable behavior. It really has to be decided on a case by case basis, so remove the examples of unacceptable behavior, and don't attempt to define it at all.

No one can object to the examples of positive behavior. No one can object to a CoC that simply promotes those positive examples and then establishes a complaint process and a CoC committee to rule on each complaint.

martin

________________________________________
From: Development <development-bounces+martin.smith=***@qt-project.org<mailto:***@qt-project.org>> on behalf of Ulf Hermann <***@qt.io<mailto:***@qt.io>>
Sent: Wednesday, October 24, 2018 9:17:09 AM
To: ***@qt-project.org<mailto:***@qt-project.org>
Subject: [Development] QUIP 12: Code of Conduct

Hi,

regarding our earlier discussions on a possible Code of Conduct, here as
well as at the Contributors' Summit 2017, I've pushed a QUIP with the
necessary rules and definitions:

https://codereview.qt-project.org/243623

Please review it.

regards,
Ulf
_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
***@qt-project.org<mailto:***@qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

[Alexey Andreyev]

> We need the document to explain the complaint process and to establish
the committee for dealing with complaints.
If we have a committee, probably they should have some statements and
agreements about how to work (I'm okay if it should be discussed separately
from CoC)
> We are adults. Despite the apparent tolerance of the bad behavior of
Donald Trump, we all know what is bad behavior in this context
I'm afraid, provided example is not an exception of our behavior as adults

чт, 25 Пкт. 2018 г. в 17:02, Martin Smith <***@qt.io>:

> >Why do we need the document then?
>
> We need the document to explain the complaint process and to establish the
> committee for dealing with complaints.
>
> >CoC committee is just a people. They need some agreements how to make
> decisions.
>
> We are adults. Despite the apparent tolerance of the bad behavior of
> Donald Trump, we all know what is bad behavior in this context.
>
> ________________________________________
> From: Alexey Andreyev <***@gmail.com>
> Sent: Thursday, October 25, 2018 3:56:18 PM
> To: Martin Smith
> Cc: Ulf Hermann; Qt development mailing list
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> > I suspect that most if not all of the commenters here who object to the
> CoC object to the attempt to define unacceptable behavior. It really has to
> be decided on a case by case basis, so remove the examples of unacceptable
> behavior, and don't attempt to define it at all.
>
> I'm okay to develop the rules. I disagree though to leave an attempt to
> define unacceptable or acceptable behavior. What should we leave then?
> General recommendation about being conscious and think about future
> consequences? It could be written in one sentense. Why do we need the
> document then?
>
> > so remove the examples of unacceptable behavior
> I agree that just the examples are not helping
>
> > No one can object to the examples of positive behavior. No one can
> object to a CoC that simply promotes those positive examples and then
> establishes a complaint process and a CoC committee to rule on each
> complaint.
>
> CoC committee is just a people. They need some agreements how to make
> decisions.
>
> чт, 25 Пкт. 2018 г. в 16:17, Martin Smith <***@qt.io<mailto:
> ***@qt.io>>:
> I suspect that most if not all of the commenters here who object to the
> CoC object to the attempt to define unacceptable behavior. It really has to
> be decided on a case by case basis, so remove the examples of unacceptable
> behavior, and don't attempt to define it at all.
>
> No one can object to the examples of positive behavior. No one can object
> to a CoC that simply promotes those positive examples and then establishes
> a complaint process and a CoC committee to rule on each complaint.
>
> martin
>
> ________________________________________
> From: Development <development-bounces+martin.smith=***@qt-project.org
> <mailto:***@qt-project.org>> on behalf of Ulf Hermann <***@qt.io
> <mailto:***@qt.io>>
> Sent: Wednesday, October 24, 2018 9:17:09 AM
> To: ***@qt-project.org<mailto:***@qt-project.org>
> Subject: [Development] QUIP 12: Code of Conduct
>
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623
>
> Please review it.
>
> regards,
> Ulf
> _______________________________________________
> Development mailing list
> ***@qt-project.org<mailto:***@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
> _______________________________________________
> Development mailing list
> ***@qt-project.org<mailto:***@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/development
>

[Uwe Rathmann]

On Wed, 24 Oct 2018 07:17:09 +0000, Ulf Hermann wrote:

> Please review it.

Qt Community, Qt Contributors, Qt Project, Qt Company - these are
different things and whenever I see someone who is speaking in behalf of
the Qt project I'm wondering who is actually speaking.

The document already has the problem, that it seems to be legitimated by
the Qt Contributor summit, what somehow implies that contributing is the
criterion for having a voice in the Qt project.

Furthermore you have this blurred line between the Qt project and the Qt
company. IMHO a CoC for the Qt project is a chance to make things a bit
clearer, by having a chapter about what type of business activities are
seen as inappropriate in areas, that are owned by the Qt project.

Or am I the only one who does not like being redirected to a page full of
commercial content, when entering qt-project.org ?

My 2 cents,
Uwe

[Thiago Macieira]

On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
>
> https://codereview.qt-project.org/243623

Hello Ulf and everyone else on this thread

I've posted a few comments here and there relating to the process of adopting
anything in our community, but I haven't yet voiced my opinion on this
subject. This email is it.

Note that even though I am speaking for myself, I understand my opinion
reflects on my employer. So I want to say this first: Intel does support Open
Source Projects adopting Code of Conduct as well as actions leading to
increasing access and diversity of ideas, hopefully leading to improved code.
We also particularly like the Contributor Covenant text.

I am also personally in favour of adopting a CoC and I support adopting either
the Covenant text or KDE's. Both are fine to me. Another good one is
Mozilla's[1], which the SQLite developers have just adopted too.

In fact, I was there 10 years ago when KDE decided to adopt something. Back
then, I was also of the opinion that we shouldn't need anything. The KDE
community had always been a welcoming one: in my first Akademy, I was greeted
by people I had only met online as an old friend. Moreover, the KDE community
had always resisted any kind of formal structuring of anything, which led to
the Technical Working Group being created and disbanding in 2006. Even today,
the KDE e.V. takes great steps to make sure it is never seen as a ruling body.

But the CoC was adopted, with no ill effects. I do not have direct knowledge
of where they had to intervene, if at all, but I'm told it has happened. More
importantly, I have also grown as a person since then. In a particularly
telling moment, when a female colleague here in the office (located in a very
affluent, liberal and progressive part of the US) once asked my opinion on the
Python Donglegate incident and explained to me the reason why she interpreted
it the way she did, I realised how my worldview was so very different from
hers. I've come to understand how little things that did not bother me were
highly offensive to her.

I've seen basically three questions asked by the skepticals to this proposal:

1) if it ain't broke, why fix it?

To put it simply: the CoC has as an objective make sure the community is
always welcoming and inclusive. People have a limit on how much hostility
(intended or not) they're going to put up with. If they reach that limit,
they're going to simply avoid it and that can be anywhere from avoiding
contributions to certain parts of the code to stopping contributing altogether
(or worse). We don't want to lose them or their contributions.

Think of the CoC as preventive maintenance: you don't do it because it's
broken. You do it so it *won't* break in the first place.

2) why not let the code rule?

Code does not exist in isolation and the Qt Project is not a set of files in
Git. The Qt Project is a community that maintains that code, so we need rules
beyond code. We have contributors who don't contribute a lot of code, but that
does not make them any less important members of the community.

Besides, any commit comes with a commit message. Any review comes with
feedback and there are few that are simply "+2" with no text. We want good
code, improving Qt and for that we need to interact with one another.
Moreover, the major architectural issues are not discussed in code, but in
prose via email.

Finally, being good at C++ is not an excuse for being a jackass. No one should
get a pass because they're experts at something. We can't make the cold
calculus that "person X's productivity is worth 10 new contributors so we will
allow X's behaviour to turn away 10 contributors". What happens on the 11th?
And what if one of those turned out to be amazing after a few months?

So clearly code is not enough.

3) how do we prevent ill side-effects and abuse?

One ill side-effect would be the turning away of important contributors who
feel that the adoption of the CoC stands in the way of their participation.
But please note that has not happened to any significant manner in any of the
big Open Source Projects that have adopted CoCs. That includes the Linux
kernel: despite what you may have heard in the media, the kernel maintainers
and Linus himself subscribe to the new CoC and Linus has returned to
development.

We can also work with that person to find a compromise solution. I find it
hard to believe we couldn't, if that person is willing to see the other side
of the coin. And I speak from experience on that.

The rest should be in the CoC text itself and how it empowers the resolution
committee to make its decisions as well as any checks-and-balances on the com
committee itself. Specifically, the CoC should not be used to discriminate
against one's political views any more than on another's sexual orientations.
And what you do on your private time is your own business.

[1] https://www.mozilla.org/en-US/about/governance/policies/participation/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Elvis Stansvik]

Even if I'm just living in the outskirts of the Qt Project (have for a long
time) I just have to say I wholeheartedly agree with Thiago in his thoughts
below.

One comment inline below.

Den fre 26 okt. 2018 07:14Thiago Macieira <***@intel.com> skrev:

> On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> > Hi,
> >
> > regarding our earlier discussions on a possible Code of Conduct, here as
> > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > necessary rules and definitions:
> >
> > https://codereview.qt-project.org/243623
>
> Hello Ulf and everyone else on this thread
>
> I've posted a few comments here and there relating to the process of
> adopting
> anything in our community, but I haven't yet voiced my opinion on this
> subject. This email is it.
>
> Note that even though I am speaking for myself, I understand my opinion
> reflects on my employer. So I want to say this first: Intel does support
> Open
> Source Projects adopting Code of Conduct as well as actions leading to
> increasing access and diversity of ideas, hopefully leading to improved
> code.
> We also particularly like the Contributor Covenant text.
>
> I am also personally in favour of adopting a CoC and I support adopting
> either
> the Covenant text or KDE's. Both are fine to me. Another good one is
> Mozilla's[1], which the SQLite developers have just adopted too.
>
> In fact, I was there 10 years ago when KDE decided to adopt something.
> Back
> then, I was also of the opinion that we shouldn't need anything. The KDE
> community had always been a welcoming one: in my first Akademy, I was
> greeted
> by people I had only met online as an old friend. Moreover, the KDE
> community
> had always resisted any kind of formal structuring of anything, which led
> to
> the Technical Working Group being created and disbanding in 2006. Even
> today,
> the KDE e.V. takes great steps to make sure it is never seen as a ruling
> body.
>
> But the CoC was adopted, with no ill effects. I do not have direct
> knowledge
> of where they had to intervene, if at all, but I'm told it has happened.
> More
> importantly, I have also grown as a person since then. In a particularly
> telling moment, when a female colleague here in the office (located in a
> very
> affluent, liberal and progressive part of the US) once asked my opinion on
> the
> Python Donglegate incident and explained to me the reason why she
> interpreted
> it the way she did, I realised how my worldview was so very different from
> hers. I've come to understand how little things that did not bother me
> were
> highly offensive to her.
>
> I've seen basically three questions asked by the skepticals to this
> proposal:
>
> 1) if it ain't broke, why fix it?
>
> To put it simply: the CoC has as an objective make sure the community is
> always welcoming and inclusive. People have a limit on how much hostility
> (intended or not) they're going to put up with. If they reach that limit,
> they're going to simply avoid it and that can be anywhere from avoiding
> contributions to certain parts of the code to stopping contributing
> altogether
> (or worse). We don't want to lose them or their contributions.
>
> Think of the CoC as preventive maintenance: you don't do it because it's
> broken. You do it so it *won't* break in the first place.
>
> 2) why not let the code rule?
>
> Code does not exist in isolation and the Qt Project is not a set of files
> in
> Git. The Qt Project is a community that maintains that code, so we need
> rules
> beyond code. We have contributors who don't contribute a lot of code, but
> that
> does not make them any less important members of the community.
>
> Besides, any commit comes with a commit message. Any review comes with
> feedback and there are few that are simply "+2" with no text. We want good
> code, improving Qt and for that we need to interact with one another.
>

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 :)

So it's absolutely not only about code.

Elvis

Moreover, the major architectural issues are not discussed in code, but in
> prose via email.
>
> Finally, being good at C++ is not an excuse for being a jackass. No one
> should
> get a pass because they're experts at something. We can't make the cold
> calculus that "person X's productivity is worth 10 new contributors so we
> will
> allow X's behaviour to turn away 10 contributors". What happens on the
> 11th?
> And what if one of those turned out to be amazing after a few months?
>
> So clearly code is not enough.
>
> 3) how do we prevent ill side-effects and abuse?
>
> One ill side-effect would be the turning away of important contributors
> who
> feel that the adoption of the CoC stands in the way of their
> participation.
> But please note that has not happened to any significant manner in any of
> the
> big Open Source Projects that have adopted CoCs. That includes the Linux
> kernel: despite what you may have heard in the media, the kernel
> maintainers
> and Linus himself subscribe to the new CoC and Linus has returned to
> development.
>
> We can also work with that person to find a compromise solution. I find it
> hard to believe we couldn't, if that person is willing to see the other
> side
> of the coin. And I speak from experience on that.
>
> The rest should be in the CoC text itself and how it empowers the
> resolution
> committee to make its decisions as well as any checks-and-balances on the
> com
> committee itself. Specifically, the CoC should not be used to
> discriminate
> against one's political views any more than on another's sexual
> orientations.
> And what you do on your private time is your own business.
>
> [1] https://www.mozilla.org/en-US/about/governance/policies/participation/
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

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

[Alexey Andreyev]

Hello! :)
The CoC is a lie. From my point of view, some of the current intentions at
least.

I'm hesitating a bit, that I'm so loud. I'm doing this to prevent problems
at the community, trying to find bottlenecks and provide better solution
for us.

> The rest should be in the CoC text itself and how it empowers the
resolution committee to make its decisions as well as any
checks-and-balances on the com committee itself. Specifically, the CoC
should not be used to discriminate against one's political views any more
than on another's sexual orientations. And what you do on your private time
is your own business.

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?

Secondly, the idea about "non-discrimination" and being free from shared
political or other values (at least minimal) could be easy perverted as
restriction to even talk about the defined topics. It could be used against
the community false-defining some sentenses as restricted. And we have
real-life examples of this. So we probably need at least minimal shared
values if we are proposing some CoC, not just undefined "free from
discrimination".

> We can also work with that person to find a compromise solution. I find
it hard to believe we couldn't, if that person is willing to see the other
side of the coin. And I speak from experience on that.

I agree we should work together on shared values

> 3) how do we prevent ill side-effects and abuse? One ill side-effect
would be the turning away of important contributors who feel that the
adoption of the CoC stands in the way of their participation. But please
note that has not happened to any significant manner in any of the big Open
Source Projects that have adopted CoCs. That includes the Linux kernel:
despite what you may have heard in the media, the kernel maintainers and
Linus himself subscribe to the new CoC and Linus has returned to
development.

Looks like it doesn't happened yet to open source projects, yes (feel free
to correct me). Just want to add that proposed CoC raised the questions at
least in case of the kernel project and we should carefully research
negative impact too to prevent worst results

> 2) why not let the code rule? [...] So clearly code is not enough.

I agree. I guess the idea why some people focusing on the code it's because
the code is better defined and verifiable at least. And some people are
probably searching for metrics how to check CoC is positive for community
development not negative. If we don't provide well-defined document, it's
probably makes no sence to include undefined with visible dangerous
problems. That's why some probably prefers KDE's version more.

> 1) if it ain't broke, why fix it? [...] We don't want to lose them or
their contributions. Think of the CoC as preventive maintenance: you don't
do it because it's broken. You do it so it *won't* break in the first
place.

I probably agree. And want to add we should be very careful.

> But the CoC was adopted, with no ill effects.

I guess global situation changed since that. And what if we compare the
number of public conflicts at the world and dates when undefined rules
about that was accepted at big companies? And it's not about just example
with Theodore Ts'o. Look at the cinema world. We should be careful not to
create rules that could be just a backdoor for external companies to force
thier expansion ideas not focused on helping at all. I agree we should
think about others and help each other, and could try to build shared
values document. The questions is about implementation.

> So I want to say this first: Intel does support Open Source Projects
adopting Code of Conduct as well as actions leading to increasing access
and diversity of ideas, hopefully leading to improved code. We also
particularly like the Contributor Covenant text.

My idea was to show that "diversity of ideas" is just yet another idea. Not
all the ideas is clear and positive by default.

"What's you favourite idea? Mine is to be creative..." (from "Don’t Hug Me,
I’m Scared")


пт, 26 Пкт. 2018 г., 8:15 Thiago Macieira <***@intel.com>:

> On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> > Hi,
> >
> > regarding our earlier discussions on a possible Code of Conduct, here as
> > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > necessary rules and definitions:
> >
> > https://codereview.qt-project.org/243623
>
> Hello Ulf and everyone else on this thread
>
> I've posted a few comments here and there relating to the process of
> adopting
> anything in our community, but I haven't yet voiced my opinion on this
> subject. This email is it.
>
> Note that even though I am speaking for myself, I understand my opinion
> reflects on my employer. So I want to say this first: Intel does support
> Open
> Source Projects adopting Code of Conduct as well as actions leading to
> increasing access and diversity of ideas, hopefully leading to improved
> code.
> We also particularly like the Contributor Covenant text.
>
> I am also personally in favour of adopting a CoC and I support adopting
> either
> the Covenant text or KDE's. Both are fine to me. Another good one is
> Mozilla's[1], which the SQLite developers have just adopted too.
>
> In fact, I was there 10 years ago when KDE decided to adopt something.
> Back
> then, I was also of the opinion that we shouldn't need anything. The KDE
> community had always been a welcoming one: in my first Akademy, I was
> greeted
> by people I had only met online as an old friend. Moreover, the KDE
> community
> had always resisted any kind of formal structuring of anything, which led
> to
> the Technical Working Group being created and disbanding in 2006. Even
> today,
> the KDE e.V. takes great steps to make sure it is never seen as a ruling
> body.
>
> But the CoC was adopted, with no ill effects. I do not have direct
> knowledge
> of where they had to intervene, if at all, but I'm told it has happened.
> More
> importantly, I have also grown as a person since then. In a particularly
> telling moment, when a female colleague here in the office (located in a
> very
> affluent, liberal and progressive part of the US) once asked my opinion on
> the
> Python Donglegate incident and explained to me the reason why she
> interpreted
> it the way she did, I realised how my worldview was so very different from
> hers. I've come to understand how little things that did not bother me
> were
> highly offensive to her.
>
> I've seen basically three questions asked by the skepticals to this
> proposal:
>
> 1) if it ain't broke, why fix it?
>
> To put it simply: the CoC has as an objective make sure the community is
> always welcoming and inclusive. People have a limit on how much hostility
> (intended or not) they're going to put up with. If they reach that limit,
> they're going to simply avoid it and that can be anywhere from avoiding
> contributions to certain parts of the code to stopping contributing
> altogether
> (or worse). We don't want to lose them or their contributions.
>
> Think of the CoC as preventive maintenance: you don't do it because it's
> broken. You do it so it *won't* break in the first place.
>
> 2) why not let the code rule?
>
> Code does not exist in isolation and the Qt Project is not a set of files
> in
> Git. The Qt Project is a community that maintains that code, so we need
> rules
> beyond code. We have contributors who don't contribute a lot of code, but
> that
> does not make them any less important members of the community.
>
> Besides, any commit comes with a commit message. Any review comes with
> feedback and there are few that are simply "+2" with no text. We want good
> code, improving Qt and for that we need to interact with one another.
> Moreover, the major architectural issues are not discussed in code, but in
> prose via email.
>
> Finally, being good at C++ is not an excuse for being a jackass. No one
> should
> get a pass because they're experts at something. We can't make the cold
> calculus that "person X's productivity is worth 10 new contributors so we
> will
> allow X's behaviour to turn away 10 contributors". What happens on the
> 11th?
> And what if one of those turned out to be amazing after a few months?
>
> So clearly code is not enough.
>
> 3) how do we prevent ill side-effects and abuse?
>
> One ill side-effect would be the turning away of important contributors
> who
> feel that the adoption of the CoC stands in the way of their
> participation.
> But please note that has not happened to any significant manner in any of
> the
> big Open Source Projects that have adopted CoCs. That includes the Linux
> kernel: despite what you may have heard in the media, the kernel
> maintainers
> and Linus himself subscribe to the new CoC and Linus has returned to
> development.
>
> We can also work with that person to find a compromise solution. I find it
> hard to believe we couldn't, if that person is willing to see the other
> side
> of the coin. And I speak from experience on that.
>
> The rest should be in the CoC text itself and how it empowers the
> resolution
> committee to make its decisions as well as any checks-and-balances on the
> com
> committee itself. Specifically, the CoC should not be used to
> discriminate
> against one's political views any more than on another's sexual
> orientations.
> And what you do on your private time is your own business.
>
> [1] https://www.mozilla.org/en-US/about/governance/policies/participation/
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> Development mailing list
> ***@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>

[Thiago Macieira]

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

[Andy Nichols]

Thank you Thiago for your well put thoughts. This is in line with my thinking as well.

I'm glad we are finally at the point of having this discussion, as it's been quite a long time since I hosted the Code of Conduct discussion at the 2017 contributors summit.
https://wiki.qt.io/QtCS2017_Qt_Project_Code_of_Conduct

What has been so surprising about the discussion so far is the assumption that the people pushing the Code of Conduct have a political agenda, because this is not at all where this drive started from. The Qt project currently is a really nice community who is very supportive and respectful of each other. The Qt community is aligned in achieving the same goals, and the work we do to achieve that is done in good faith. The whole point of the Code of Conduct was to codify those same values so we could maintain that.

The choice of the Contributors Covenant as a starting point was arbitrary (I know, because I proposed it). The KDE and Mozzila CoC's are also just as acceptable in my eyes. Even looking at the notes for the CS2017 sessions, we were perfectly fine with the simple theme of "Be Kind. Be respectful". Nothing is set in stone at this point, everything is open to discussion still, even the point of whether we should adopt any code of conduct at all.

Based on discussions I've had this week, one of the biggest sticking points with any CoC regards enforcement. Even if we have a one sentence CoC how do gross violations of the CoC get handled? If there is an email address for reporting incidents then who is reading/responding to that for example? The proposal that is part of https://codereview.qt-project.org/#/c/243623/ is also completely open to discussion evaluation. The discussion at CS2017 that led the current proposal was based off of this:
"As part of creating the Code of Conduct, we will also establish a small private mailing list for usage in resolving breaches of the code. This would behave similarly to the Security mailing list. This proposal will be part of the draft submitted to the Qt Project for approval."
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.

So maybe a better way of looking at this is, today if you felt were legitimately being harassed by another member of the Qt Project, what would you do? Who would you tell and what kind of reaction would you expect? My understanding of how things are handled today is that its very ad hoc, which is less than ideal as well.

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?

I also want to make it clear that QUIP 12 can be completely different than what is in https://codereview.qt-project.org/#/c/243623/ and welcome a counter proposal based off the KDE CoC if someone would like to draft that.

I look forward to hearing any thoughts and ideas.

Andy Nichols

-----Original Message-----
From: Development <development-bounces+andy.nichols=***@qt-project.org> On Behalf Of Thiago Macieira
Sent: Friday, October 26, 2018 7:15 AM
To: ***@qt-project.org
Subject: Re: [Development] QUIP 12: Code of Conduct

On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> Hi,
>
> regarding our earlier discussions on a possible Code of Conduct, here
> as well as at the Contributors' Summit 2017, I've pushed a QUIP with
> the necessary rules and definitions:
>
> https://codereview.qt-project.org/243623

Hello Ulf and everyone else on this thread

I've posted a few comments here and there relating to the process of adopting anything in our community, but I haven't yet voiced my opinion on this subject. This email is it.

Note that even though I am speaking for myself, I understand my opinion reflects on my employer. So I want to say this first: Intel does support Open Source Projects adopting Code of Conduct as well as actions leading to increasing access and diversity of ideas, hopefully leading to improved code.
We also particularly like the Contributor Covenant text.

I am also personally in favour of adopting a CoC and I support adopting either the Covenant text or KDE's. Both are fine to me. Another good one is Mozilla's[1], which the SQLite developers have just adopted too.

In fact, I was there 10 years ago when KDE decided to adopt something. Back then, I was also of the opinion that we shouldn't need anything. The KDE community had always been a welcoming one: in my first Akademy, I was greeted by people I had only met online as an old friend. Moreover, the KDE community had always resisted any kind of formal structuring of anything, which led to the Technical Working Group being created and disbanding in 2006. Even today, the KDE e.V. takes great steps to make sure it is never seen as a ruling body.

But the CoC was adopted, with no ill effects. I do not have direct knowledge of where they had to intervene, if at all, but I'm told it has happened. More importantly, I have also grown as a person since then. In a particularly telling moment, when a female colleague here in the office (located in a very affluent, liberal and progressive part of the US) once asked my opinion on the Python Donglegate incident and explained to me the reason why she interpreted it the way she did, I realised how my worldview was so very different from hers. I've come to understand how little things that did not bother me were highly offensive to her.

I've seen basically three questions asked by the skepticals to this proposal:

1) if it ain't broke, why fix it?

To put it simply: the CoC has as an objective make sure the community is always welcoming and inclusive. People have a limit on how much hostility (intended or not) they're going to put up with. If they reach that limit, they're going to simply avoid it and that can be anywhere from avoiding contributions to certain parts of the code to stopping contributing altogether (or worse). We don't want to lose them or their contributions.

Think of the CoC as preventive maintenance: you don't do it because it's broken. You do it so it *won't* break in the first place.

2) why not let the code rule?

Code does not exist in isolation and the Qt Project is not a set of files in Git. The Qt Project is a community that maintains that code, so we need rules beyond code. We have contributors who don't contribute a lot of code, but that does not make them any less important members of the community.

Besides, any commit comes with a commit message. Any review comes with feedback and there are few that are simply "+2" with no text. We want good code, improving Qt and for that we need to interact with one another.
Moreover, the major architectural issues are not discussed in code, but in prose via email.

Finally, being good at C++ is not an excuse for being a jackass. No one should get a pass because they're experts at something. We can't make the cold calculus that "person X's productivity is worth 10 new contributors so we will allow X's behaviour to turn away 10 contributors". What happens on the 11th?
And what if one of those turned out to be amazing after a few months?

So clearly code is not enough.

3) how do we prevent ill side-effects and abuse?

One ill side-effect would be the turning away of important contributors who feel that the adoption of the CoC stands in the way of their participation.
But please note that has not happened to any significant manner in any of the big Open Source Projects that have adopted CoCs. That includes the Linux
kernel: despite what you may have heard in the media, the kernel maintainers and Linus himself subscribe to the new CoC and Linus has returned to development.

We can also work with that person to find a compromise solution. I find it hard to believe we couldn't, if that person is willing to see the other side of the coin. And I speak from experience on that.

The rest should be in the CoC text itself and how it empowers the resolution committee to make its decisions as well as any checks-and-balances on the com committee itself. Specifically, the CoC should not be used to discriminate against one's political views any more than on another's sexual orientations.
And what you do on your private time is your own business.

[1] https://www.mozilla.org/en-US/about/governance/policies/participation/
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center

[Thiago Macieira]

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

[Thiago Macieira]

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

[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

[Thiago Macieira]

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

[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

[Thiago Macieira]

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

[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