llvm dev - May 2016 - Resuming the discussion of establishing an LLVM code of conduct

Greetings all,

This has come up a few times, and I would like to resume the effort to
establish an LLVM code of conduct.

First and foremost, many thanks to Philip Reames who sat down with me
several months ago and worked through a number of suggestions that I've
tried to incorporate into an updated patch with the draft text:
http://reviews.llvm.org/D13741

I think his updates plus a few others go a long way to address some of the
concerns raised in the previous discussions. The big issues I saw being
raised (but in my words, I trust others to chime in with useful
clarifications or corrections as needed):

First and foremost, this should not substantially change the community's
conduct. We have strong existing practice of keeping good behavior. I hope
the wording now makes this reasonably clear.

There were also a number of things unclear or easily mistaken about the
"reporting" process and what happens there. Philip in particular
helped
craft significant improvements here, and much of the credit is his. Notable
things improved or addressed IMO:

- Nothing should ever prevent the community from self-enforcing good
behavior much as it has been for a long time.

- When violations are reported, there may not have been any issue at all,
in which case nothing happens.

- Any issue may also have already been addressed much as our community has
addressed issues on its own for many years. In those cases, the committee
need not take any further action.

- The committee will of course need to gather information from those
involved and witnesses, and only make a decision with all of the
information available. I think this is much more clear now.

- Physical spaces may escalate the severity. Although I hope it never
happens, I think it is more clear now that *if* this happens immediate
steps will be taken to ensure everyone's safety and law enforcement
involved if necessary.

- It is structured to make it clear who is on the advisory committee. We
still have to select an advisory committee, etc., which is something I'm
*not* trying to figure out here and now. I think once we have the framework
in place, we can start working on that and adjust the framework if issues
with it come up in the process.


This still isn't a really formal thing with hard and fast rules. But I
don't think that is what the community needs. I do think they provide the
framework the community needs to effectively handle and cope if issues come
up. While I suspect it is impossible to get everyone 100% happy here, I
think this is very close and a reasonable starting point which can be
evolved as necessary if problems arise.

Thanks,
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/29f0b6e9/attachment.html>

On Thu, May 5, 2016 at 4:21 PM, Chandler Carruth via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Greetings all,
>
> This has come up a few times, and I would like to resume the effort to
> establish an LLVM code of conduct.
Sincerely and pragmatically - what do you think will be different
after this is in place.. Bureaucracy is great, but what's broken or
pandemic that you're trying to fix?
>From my side I can be a sarcastic smartass from time to time, but
overall I don't see that being a heavy burden.. (maybe I'm mistaken?)
Other than myself - very rarely you get some disagreements on the ML,
but has it ever been serious? Are these disagreements involving any
typical suspects? The job postings can be a bit OT, but don't seem to
soo frequent..

If one very good engineer is unintentionally/inadvertently causing
friction - how would you deal with that at a policy level which is
different from what happens today?

Personally I want a document that I can point people to and say 'this is 
what we expect of you if you interact with our community'.

Really simple case where this would have been useful was when a certain 
member of the Linus community used profanity on the list - which may be 
fine in their mailing lists but is certainly not in ours.

Cheers,
-Neil.

On 05/05/16 09:58, C Bergström via llvm-dev wrote:
> On Thu, May 5, 2016 at 4:21 PM, Chandler Carruth via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Greetings all,
>>
>> This has come up a few times, and I would like to resume the effort to
>> establish an LLVM code of conduct.
> Sincerely and pragmatically - what do you think will be different
> after this is in place.. Bureaucracy is great, but what's broken or
> pandemic that you're trying to fix?
>
>  From my side I can be a sarcastic smartass from time to time, but
> overall I don't see that being a heavy burden.. (maybe I'm
mistaken?)
> Other than myself - very rarely you get some disagreements on the ML,
> but has it ever been serious? Are these disagreements involving any
> typical suspects? The job postings can be a bit OT, but don't seem to
> soo frequent..
>
> If one very good engineer is unintentionally/inadvertently causing
> friction - how would you deal with that at a policy level which is
> different from what happens today?
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Am 05.05.2016 um 10:58 schrieb C Bergström via llvm-dev:
> Sincerely and pragmatically - what do you think will be different
> after this is in place.. Bureaucracy is great, but what's broken or
> pandemic that you're trying to fix?
 From the last discussion, I gather that it's an attempt to prevent 
damage before it can happen.
I'm quite sceptical about that. It's hard to do in general because you 
can't really foresee what people will do, and it will give trolls just 
another tool to work with; last time it was badly done because it tried 
to cover all bases and ended up being overspecific (judging from the 
comments, it's still happening; I can't see the text because the website
requires Javascript and I cannot activate that on non-preapproved websites).

However, some people in the committee insist.
I suspect some want to protect the current cooperative tone, and some 
want to avoid another accusation of being unfair as certainly happened 
the last time a troll was evicted from the list.
I do not think the former can be achieved without inviting other kinds 
of damage, and to the latter I'd say that you can't evade responsibility
for misdecisions is the same, whether you misdecide a specific case or 
misdecide the rules. Except that the latter has far more far-reaching 
consequences but people tend to feel the impact less...
> From my side I can be a sarcastic smartass from time to time, but
> overall I don't see that being a heavy burden.. (maybe I'm
mistaken?)
It's all a question of perceived aggression.
Some people will perceive you to be a burden, some won't even notice, 
most will be somewhere in-between. It's more dependent on the reader's 
cultural and personal background than anything else.
> Other than myself - very rarely you get some disagreements on the ML,
> but has it ever been serious?
I think the last time this discussed, something like that came up once 
in the lifetime of the ML, and it was dealt with.
> If one very good engineer is unintentionally/inadvertently causing
> friction - how would you deal with that at a policy level which is
> different from what happens today?
I have seen that happen in another community.
In the end, he was evicted. The reasoning was that even an excellent 
engineer does more damage than good if he's deterring a dozen people, 
some of which might be as good as him or grow into being as good as him. 
Also, letting him stay would mean that his behaviour would get copied.

So I'm generally in favor of having a code of conduct, but it should be 
short, vague enough to allow flexible reactions to unforeseen 
behavioural patterns, and concentrate more on intent and effect than on 
specific behaviours, so we don't end in a court system with lawyers and 
appeals and procedure in a community that simply has neither resources 
nor expertise to properly execute that.

That's just my 2 cents from the sideline; I had expected LLVM to become 
a significant part of my life so I did take sides last time this was 
discussed, but none of my expectations have materialized (due to reasons 
outside of the LLVM project) so I'm not going to vote this time, I'm 
just offering my observations and background knowledge.

Regards,
Jo

In the interests of individual liberty and individual justice, I feel I
must speak now.

The last sentence of the third paragraph bothers me:

In addition, violations of this code outside these spaces may
affect
> a person's ability to participate within them.
​This essentially gives the committee *carte blanche* to police our
thoughts no matter where we are or what we're doing. I don't like the
idea
of having my thoughts policed. There are people out there who *will*
abuse ​this
for their own ends! I can't let those people do that.

I'm afraid if this sentence goes in, I go out--and fork the LLVM family.
Yes, I feel *that* strongly about freedom of thought.

In the sample list of unacceptable behaviors, I'd consider adding the
following:

   - Demanding special treatment for being a particular race, sex, sexual
   orientation, gender identity, etc. *Nobody* gets this privilege.
   - Kafkatrapping (e.g. denying X proves you are part of problem X)
   - False accusations
   - Dog-piling (inviting a bunch of people, many outside the community, to
   join the conversation and attack the target)

I'd also consider, in the "Personal Attacks" item, that the
emphasis on
racist and sexist terms be removed. Yes, they're bad. The individual is not
the mass, after all. Perhaps in addition to the "Personal Attacks"
item we
should also have an item for treating people as parts of groups instead of
as individuals. There's no need to deny their lived experience by jamming
them under some worthless label.

​I also would like​​ a clause demonstrating our commitment to technical
excellence. In particular, I would like it to emphasize that the
*only* standard
by which a contribution is judged is its merit. No other factors may be
used--and certainly no irrelevant factors such as race or sex or sexual
orientation or gender identity or... (And I don't just mean technically
excellent code here. Artistic contributions should be judged on artistic
merits. Documentation and other writing should be judged on correctness,
readability, and usefulness.)

Finally, I fear that the reporting process will be abused by less savory
people to destroy their enemies. For this reason, I suggest that there also
be consequences for the *accuser* if:

   - The accused is punished, and
   - The accused is later found to have been innocent.

In this case, the accuser would also suffer the punishment. (Of course,
this can be abused, too. We'll have to strike the right balance between the
rights of the accuser and the rights of the accused. This is hard to get
right.)

Just my two cents. I actually don't expect you to act on any of these. In
fact, I expect you all to write me off from this point forward, just for
that last proposal. ;)  But if you act on only one, please make it the
first one. I'm willing to compromise on the others, but no controls on my
speech outside of LLVM's spaces is non-negotiable.

Chip
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/c0512627/attachment.html>

On 5 May 2016, at 12:14, Charles Davis via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> The last sentence of the third paragraph bothers me:
> 
>> In addition, violations of this code outside these spaces may affect
>> a person's ability to participate within them.
> ​This essentially gives the committee carte blanche to police our thoughts
no matter where we are or what we're doing. I don't like the idea of
having my thoughts policed. There are people out there who will abuse ​this for
their own ends! I can't let those people do that.
Something like this is required, based on real problems that have existed in
some other communities.  If one LLVM contributor is attacking another on
Facebook / Twitter / whatever, then it’s not acceptable for the LLVM community
to simply say ‘it’s not on our mailing lists, it’s not our problem’.

Similarly, it’s hard to claim that a project is inclusive of group X if
committer Y is attacking group X elsewhere in a way that associates the project
with their statements (for example, soliciting LLVM-related consulting work from
the same account) and the project is happy to permit this.

These are not hypothetical problems, they are ones that I have first-hand
experience with (though, thankfully, not in this community).  The code of
conduct does need to provide a mechanism for addressing these, though the
sanctions that can be employed (removal of commit rights, removal of mailing
list access) are fairly mild.  We don’t want to be in a situation where people
can say ‘don’t get involved with LLVM, they hate people like you’ and we say
‘oh, that’s just an LLVM developer posting on his own site / social media
thingy, it’s nothing to do with us.  [S]He’s never used LLVM infrastructure to
harass people like you, so it’s not our problem’.

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3719 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/e71a6dcb/attachment.bin>

Hi Chandler,

I wanted to take a moment to thank you and Phil for your work on this document,
and to voice my sincere support for both the goals and for the proposed CoC.

—Owen

> On May 5, 2016, at 1:21 AM, Chandler Carruth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Greetings all,
> 
> This has come up a few times, and I would like to resume the effort to
establish an LLVM code of conduct.
> 
> First and foremost, many thanks to Philip Reames who sat down with me
several months ago and worked through a number of suggestions that I've
tried to incorporate into an updated patch with the draft text:
http://reviews.llvm.org/D13741 <http://reviews.llvm.org/D13741>
> 
> I think his updates plus a few others go a long way to address some of the
concerns raised in the previous discussions. The big issues I saw being raised
(but in my words, I trust others to chime in with useful clarifications or
corrections as needed):
> 
> First and foremost, this should not substantially change the
community's conduct. We have strong existing practice of keeping good
behavior. I hope the wording now makes this reasonably clear.
> 
> There were also a number of things unclear or easily mistaken about the
"reporting" process and what happens there. Philip in particular
helped craft significant improvements here, and much of the credit is his.
Notable things improved or addressed IMO:
> 
> - Nothing should ever prevent the community from self-enforcing good
behavior much as it has been for a long time.
> 
> - When violations are reported, there may not have been any issue at all,
in which case nothing happens.
> 
> - Any issue may also have already been addressed much as our community has
addressed issues on its own for many years. In those cases, the committee need
not take any further action.
> 
> - The committee will of course need to gather information from those
involved and witnesses, and only make a decision with all of the information
available. I think this is much more clear now.
> 
> - Physical spaces may escalate the severity. Although I hope it never
happens, I think it is more clear now that *if* this happens immediate steps
will be taken to ensure everyone's safety and law enforcement involved if
necessary.
> 
> - It is structured to make it clear who is on the advisory committee. We
still have to select an advisory committee, etc., which is something I'm
*not* trying to figure out here and now. I think once we have the framework in
place, we can start working on that and adjust the framework if issues with it
come up in the process.
> 
> 
> This still isn't a really formal thing with hard and fast rules. But I
don't think that is what the community needs. I do think they provide the
framework the community needs to effectively handle and cope if issues come up.
While I suspect it is impossible to get everyone 100% happy here, I think this
is very close and a reasonable starting point which can be evolved as necessary
if problems arise.
> 
> Thanks,
> -Chandler
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/7ed882b0/attachment.html>

I’d like to second what Owen said.  Thanks very much for the hard work on this,
and I think that you’re picking up from a pretty good place with the document
itself.

– Steve
> On May 5, 2016, at 12:35 PM, Owen Anderson via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Hi Chandler,
> 
> I wanted to take a moment to thank you and Phil for your work on this
document, and to voice my sincere support for both the goals and for the
proposed CoC.
> 
> —Owen
> 
> 
>> On May 5, 2016, at 1:21 AM, Chandler Carruth via llvm-dev <llvm-dev
at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 
>> Greetings all,
>> 
>> This has come up a few times, and I would like to resume the effort to
establish an LLVM code of conduct.
>> 
>> First and foremost, many thanks to Philip Reames who sat down with me
several months ago and worked through a number of suggestions that I've
tried to incorporate into an updated patch with the draft text:
http://reviews.llvm.org/D13741 <http://reviews.llvm.org/D13741>
>> 
>> I think his updates plus a few others go a long way to address some of
the concerns raised in the previous discussions. The big issues I saw being
raised (but in my words, I trust others to chime in with useful clarifications
or corrections as needed):
>> 
>> First and foremost, this should not substantially change the
community's conduct. We have strong existing practice of keeping good
behavior. I hope the wording now makes this reasonably clear.
>> 
>> There were also a number of things unclear or easily mistaken about the
"reporting" process and what happens there. Philip in particular
helped craft significant improvements here, and much of the credit is his.
Notable things improved or addressed IMO:
>> 
>> - Nothing should ever prevent the community from self-enforcing good
behavior much as it has been for a long time.
>> 
>> - When violations are reported, there may not have been any issue at
all, in which case nothing happens.
>> 
>> - Any issue may also have already been addressed much as our community
has addressed issues on its own for many years. In those cases, the committee
need not take any further action.
>> 
>> - The committee will of course need to gather information from those
involved and witnesses, and only make a decision with all of the information
available. I think this is much more clear now.
>> 
>> - Physical spaces may escalate the severity. Although I hope it never
happens, I think it is more clear now that *if* this happens immediate steps
will be taken to ensure everyone's safety and law enforcement involved if
necessary.
>> 
>> - It is structured to make it clear who is on the advisory committee.
We still have to select an advisory committee, etc., which is something I'm
*not* trying to figure out here and now. I think once we have the framework in
place, we can start working on that and adjust the framework if issues with it
come up in the process.
>> 
>> 
>> This still isn't a really formal thing with hard and fast rules.
But I don't think that is what the community needs. I do think they provide
the framework the community needs to effectively handle and cope if issues come
up. While I suspect it is impossible to get everyone 100% happy here, I think
this is very close and a reasonable starting point which can be evolved as
necessary if problems arise.
>> 
>> Thanks,
>> -Chandler
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/33d78666/attachment.html>

On May 5, 2016, at 1:21 AM, Chandler Carruth via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Greetings all,
> 
> This has come up a few times, and I would like to resume the effort to
establish an LLVM code of conduct.
Awesome, long overdue.  Thank you for pushing this.
> First and foremost, many thanks to Philip Reames who sat down with me
several months ago and worked through a number of suggestions that I've
tried to incorporate into an updated patch with the draft text:
http://reviews.llvm.org/D13741 <http://reviews.llvm.org/D13741>
What is the value in having a bespoke LLVM code of conduct?

The Swift community has been using the standard "Contributor Covenant” to
good effect:
https://swift.org/community/#code-of-conduct
http://contributor-covenant.org

Why do we need to “innovate" here?

-Chris


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/06a0219b/attachment.html>

On Thu, May 5, 2016 at 1:47 PM Chris Lattner <clattner at apple.com>
wrote:
> On May 5, 2016, at 1:21 AM, Chandler Carruth via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>
> Greetings all,
>
> This has come up a few times, and I would like to resume the effort to
> establish an LLVM code of conduct.
>
>
> Awesome, long overdue.  Thank you for pushing this.
>
> First and foremost, many thanks to Philip Reames who sat down with me
> several months ago and worked through a number of suggestions that I've
> tried to incorporate into an updated patch with the draft text:
> http://reviews.llvm.org/D13741
>
>
> What is the value in having a bespoke LLVM code of conduct?
>
> The Swift community has been using the standard "Contributor Covenant”
to
> good effect:
> https://swift.org/community/#code-of-conduct
> http://contributor-covenant.org
>
> Why do we need to “innovate" here?
>
A lot of that was discussed in the original thread. I'm somewhat reluctant
to try to repeat all of it... But one thing I would point out is that this
*isn't* bespoke and is directly derived from other widely used codes of
conduct.

>
> -Chris
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/c3b0456f/attachment.html>

On 5 May 2016 at 21:47, Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> The Swift community has been using the standard "Contributor Covenant”
to
> good effect:
> https://swift.org/community/#code-of-conduct
> http://contributor-covenant.org
>
> Why do we need to “innovate" here?
Hi Chris,

I think the swift code is simple, and albeit over-specifying, good
enough for most purposes. In comparison to the current proposal, I
think it would be an improvement, but there are two main problems:


   1. We don't have project maintainers.

We have code owners, some of them haven't touched the sources, or
haven't interacted with the community in a while. The current owners
haven't singed up for maintainership (whatever that entails), so we
can't just change the roles.

GCC follows the maintainer model, and I think while this may curb some
code instability, it also slows down progress in the speed we're used
to. I don't want to change that.

I think this format is working well, and formalising maintainers just
for the sake of the CoC would be too much.


   2. We don't have a single strong leader.

We have many strong leaders, but not a single point of reference. You
were much more active years ago, and no one has actually stepped in as
you faded into other projects.

I personally think your "rule" was one that not one of us would be
able to do justice. Mainly because in the the interim, the community
has spread out a bit and an odd form of meritocratic anarchy has
formed. So, while there are barons and generals, there is no king.
LLVM now is used by so many big companies with so much money at stake
that it would be impossible for any single company to completely
control it like when Apple was the single user.



The foundation may have tried to take your place, but I don't think it
succeeded. I don't think it will in its present form, and I personally
think it shows how mature our community really is.

The reason that is so, is because of the wide spread invisible control
that goes on in the back-stage. You rarely see so many closed meetings
in open source conferences as I see in the LLVM dev meetings, and that
is part of the quirks of a permissive license most of the companies we
work for enjoy. While most of us do all the work and discussions in
the open, our companies have their own agenda and it's not uncommon to
see big changes happening without so much of a discussion in the list
first.

Examples are the foundation itself, the code of conduct, the complete
annihilation of the ELF back-end in LLD last year, etc. For a
community that wants to be inclusive by means of a CoC, we surely do a
lot behind closed doors without any discussion in the open.

As others have noticed, the CoC discussion has become polarised, with
two groups sharing their ideas without conceding space. This, to me,
is a beacon that shows me that we still value openness and consensus.
And that is why I still spend my time arguing.

Maybe I'm so wrong, I should be embarrassed. Maybe the foundation now
controls everything and the code will be enforced, and I'll probably
be banned from time to time. I surely hope not, as the last 7 years
have been the best time of my career. But again, I can always do
something else, in a community that is more in sync to my values, if
this is not it.

cheers,
--renato

On 05/05/2016 04:14 AM, Charles Davis wrote:
> In the interests of individual liberty and individual justice, I feel 
> I must speak now.
>
> The last sentence of the third paragraph bothers me:
>
>     In addition, violations of this code outside these spaces may affect
>     a person's ability to participate within them.
>
> ​This essentially gives the committee /carte blanche/ to police our 
> thoughts no matter where we are or what we're doing. I don't like
the
> idea of having my thoughts policed. There are people out there who 
> /will/ abuse ​this for their own ends! I can't let those people do
that.
I disagree strongly with your interpretation of this clause.  I also 
find your wording inflammatory and utterly unhelpful to the discussion 
at hand.

The intent of this wording is to ensure that harassment done off the 
mailing lists can still be considered a violation of the CoC.  For 
instance, send of private harassing email, harassing tweets from a 
non-work account, etc...

Do you have *specific and targeted* wording changes that you feel would 
resolve your concerns while still meeting the stated purpose?

>
> I'm afraid if this sentence goes in, I go out--and fork the LLVM 
> family. Yes, I feel /*that*/ strongly about freedom of thought.
>
> In the sample list of unacceptable behaviors, I'd consider adding the 
> following:
>
>   * Demanding special treatment for being a particular race, sex,
>     sexual orientation, gender identity, etc. *Nobody* gets this
>     privilege.
>   * Kafkatrapping (e.g. denying X proves you are part of problem X)
>   * False accusations
>   * Dog-piling (inviting a bunch of people, many outside the
>     community, to join the conversation and attack the target)
>
I view all of these as being already covered by the current proposal 
under the "Be respectful" and "Be careful in the words that you
choose
and be kind to others" sections.
> I'd also consider, in the "Personal Attacks" item, that the
emphasis
> on racist and sexist terms be removed. Yes, they're bad. The 
> individual is not the mass, after all. Perhaps in addition to the 
> "Personal Attacks" item we should also have an item for treating 
> people as parts of groups instead of as individuals. There's no need 
> to deny their lived experience by jamming them under some worthless label.
Strongly disagreed.  History has shown that sexist and racists actions 
are unfortunately common and that explicitly calling out said behavior 
as unacceptable does change peoples actual behavior.
> Finally, I fear that the reporting process will be abused by less 
> savory people to destroy their enemies. For this reason, I suggest 
> that there also be consequences for the /accuser/ if:
>
>   * The accused is punished, and
>   * The accused is later found to have been innocent.
>
> In this case, the accuser would also suffer the punishment. (Of 
> course, this can be abused, too. We'll have to strike the right 
> balance between the rights of the accuser and the rights of the 
> accused. This is hard to get right.)
I believe this already covered by the reporting policy.  In particular, 
you'll note that there is no assumption in the document about who 
actually violated the CoC.  It absolutely could be the person who 
initiated the report.  Someone trying to abuse the system in this was 
would absolutely be violating the CoC as stated.
>
> Just my two cents. I actually don't expect you to act on any of these. 
> In fact, I expect you all to write me off from this point forward, 
> just for that last proposal. ;)  But if you act on only one, please 
> make it the first one. I'm willing to compromise on the others, but no 
> controls on my speech outside of LLVM's spaces is non-negotiable.
If you are not willing to avoid personal attacks and keep your behavior 
professional, I, personally, will not be sorry to see you leave.  A 
highly relevant quote: "Your right to swing your arms ends just where 
the other man’s nose begins."

Philip

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160505/c2b1e0ac/attachment.html>

Chris Lattner via llvm-dev wrote:
> 
> What is the value in having a bespoke LLVM code of conduct?
> 
> The Swift community has been using the standard "Contributor Covenant”
> to good effect:
> https://swift.org/community/#code-of-conduct
> http://contributor-covenant.org
> 
> Why do we need to “innovate" here?
Was it not the very behavior of the *author* of said "Contributor
Covenant"
that has provided a definitive example of wielding a code of conduct as
a weapon to police wrongthink?  Speech that occurred, one might add, in a
discussion on social media completely unrelated to the programming project?

  [ https://github.com/opal/opal/issues/941 ]

Would not such an incident give one pause?

Would not one be inclined to put on the brakes, having seen the author's
demonstrated intentions?

How in the fiduciary melonfarming troutdangle does one not, having seen
those cards laid bare, say: "Whoa.  Thanks for illustrating how you intend
this to function.  We'll shop somewhere else."


Personally I'm pleased the Ruby maintainers did decide to innovate, and
that they managed to arrive at something arguably more elegant, and
certainly more concise:

https://www.ruby-lang.org/en/conduct/



Regards,

Bill