Resuming the discussion of establishing an LLVM code of conduct

Weighing in as a mostly-lurker:

A CoC is a great idea. I'm ok with Chandler's current draft. I'm ok with his first draft. I'm ok with just adopting a standard one like Swift did. I think it's important to enumerate several of the most common kinds of harassment, and it's understood that it's not a comprehensive list.

I think the pedantry of this thread is unwarranted; the very real cancer of pervasive tech-community harassment dwarfs the slim chances of the CoC itself being somehow abused, so I think it's a no-brainer to adopt it and move on. We can always revisit if it becomes a problem in practice, but my intuition is that a year from now it will have long since faded as a point of controversy.

Many thanks to everybody who has participated in drafting the CoC. You're getting more grief than you deserve.

As activity on the thread dies down and I guess it has been socialized
to the point of annoyance (myself and probably others based on private
emails).. I'll assume the current draft is mostly stable, but to
confirm, Chandler are you done playing with your CoC?

As a side note: I'm a bit disappointed by some of the "leadership"
around here, who immediately attacked my alternative instead of trying
to give more constructive feedback or having an open mind.

As activity on the thread dies down and I guess it has been socialized
to the point of annoyance (myself and probably others based on private
emails).. I'll assume the current draft is mostly stable, but to
confirm, Chandler are you done playing with your CoC?

I personally think the code is fine as it is.

However, we still need to sort out two main issues:

1. The committee

* How is this committee going to be formed? Vote? Nomination? From
where? By whom?
* How many people will compose the committee? A few? A lot?
* How do we know the committee is not just being fair, but truthful to
the code and the community? Some form of auditing is in order.
* How long are these people going to stay? How are they going to be replaced?
* If we find problems, how can we propose changes and who can they be
replaced with?

Also, another suggestion, is to have interim sub-committees for
specific cases. For example, if something happened around the ARM code
base, me, Tim, James could help providing insight, and ensuring due
diligence.

2. The code itself

One of the arguments in favour of long lists of minorities and
harassment examples is that the list has to be explicit to avoid
doubt, but to be precise and fair, we need to update the code to
reflect the problems we face in the future.

Regardless of my opinion, this seems to be a larger consensus than the
committee situation. But without the ability and a defined process to
actually change the code, that promise is void. So, I'll repeat your
question:

How are revisions/errata to be handled in the future?

It's perfectly possible that neither the composition and dynamics of
the committee, nor the revision process belong to either the code of
conduct or the reporting guidelines. But we must discuss and reach a
consensus about this before both go in.

I don't think strong handed decisions will be for the good of the
community, with or without the code. We are a community that goes
beyond its individual members. We have values of respect, inclusion
and equality that go beyond individual countries.

We have never had a strong handed decision this large in the community
as far as I can remember, and doing so now would go against the values
that we all agree are good and we want to keep with the code.

I think the crucial things people are asking now is transparency and
representativeness. I don't think any modern community can thrive
without either these values. Nor I think we can drop them on the floor
because of other values. There's always a way to keep *all* your
values, it just takes longer to reach consensus.

cheers,
--renato

> As activity on the thread dies down and I guess it has been socialized
> to the point of annoyance (myself and probably others based on private
> emails).. I'll assume the current draft is mostly stable, but to
> confirm, Chandler are you done playing with your CoC?

I personally think the code is fine as it is.

However, we still need to sort out two main issues:

1. The committee

* How is this committee going to be formed? Vote? Nomination? From
where? By whom?
* How many people will compose the committee? A few? A lot?
* How do we know the committee is not just being fair, but truthful to
the code and the community? Some form of auditing is in order.
* How long are these people going to stay? How are they going to be
replaced?
* If we find problems, how can we propose changes and who can they be
replaced with?

Also, another suggestion, is to have interim sub-committees for
specific cases. For example, if something happened around the ARM code
base, me, Tim, James could help providing insight, and ensuring due
diligence.

I fully agree with Renato. Given that we are going to have a code,
the next topic is who to entrust with taking the appropriate action,
and how to identify not just the first committee but their successors
in a way that preserves the trust of the community.

And while I am completely happy to postulate the good will of the
people proposing these things, the *whole* *point* of codifying them
is to keep things from going bad later. We haven't defined any of
the necessary processes for any of that.

--paulr

Just as a heads up, I have updated the revision adding the code of conduct to incorporate the TOC summary at the top (not sure i have the formatting right yet, but i’ll iterate on that) in addition to other minor updates.

I think that we are largely converging here on the draft documents, but I’d actually like to see folks who are happy explicitly ack the latest revision.

There is a large set of open questions around forming the advisory committee and the process around it. Renato raised many of these excellent questions in his email. However, I would like to suggest that we first get the draft framework in place, and then, after the dust settles a bit and folks’ inboxes have recovered, we start a fresh discussion that focuses on the issues around forming the advisory committee. Some folks have volunteered already to drive that discussion, so I’m very hopeful it will kick off in a week or so. But I think we should refrain (for now) from deep-diving on the issues around forming the advisory committee to keep this thread somewhat more focused.

My hope is that once the advisory committee side of this is settled, we can then discuss moving these out of “draft” status.

-Chandler

PS: Also, thanks to everyone for the constructive comments and support here.

I tip my hat to you Chandler - The effort you put and endure is nearly
heroic. (You do realize that the questions which Renato asked are
nearly exactly the same as I proposed in the start and again just
before his email, which in fact I was quoted on.. anywho..)

I'm still very strongly against any CoC which isn't "standardized" or
extremely simple.

Maybe opensource.org would be willing to consider something along
these lines. If the trend is common enough on projects maybe it's a
discussion at a higher level and shouldn't fall solely on the
shoulders of this community.

Side thought - the GNU and liberal license communities diverge on
licensing philosophies.. I wonder if they'd also diverge on community
policies.. hmm..

Side thought before I forget - SPI may have a lot of the voting
technology and surrounding details for how to form and manage an "open
source" centric committee. If LLVM isn't a unique case - maybe we can
lean on what other successful communities do..