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

On 9 May 2016 at 03:07, C Bergström <llvm-dev at lists.llvm.org>
wrote:
> 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

> On 9 May 2016 at 03:07, C Bergström <llvm-dev at lists.llvm.org>
wrote:
> > 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
> 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
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160510/1efb9d87/attachment.html>

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