[llvm-dev] Resuming the discussion of establishing an LLVM code of conduct

Robinson, Paul via llvm-dev llvm-dev at lists.llvm.org
Mon May 9 13:07:50 PDT 2016


> 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


More information about the llvm-dev mailing list