llvm dev - Oct 2015 - RFC: Introducing an LLVM Community Code of Conduct

On Tue, Oct 13, 2015 at 2:45 PM Philip Reames <listmail at
philipreames.com>
wrote:
> +1 to the general idea of a CoC
>
> A couple of specific thoughts:
>
> 1) It would have been nice for this not to appeared out of thin air.  In
> an ideal world, a previous update would have mentioned ongoing thought and
> research in this area.
>
Well, water and bridge and all. =/ I understand the challenges of this
coming out of thin air, but I also don't know how to have proceeded
differently. I didn't really have a useful intermediate state to share or I
would have. =/ It is definitely something to avoid where possible, I'm just
not sure it was realistically possible in this instance.

2) Several folks have mentioned that they'd like to see this less
verbose.
> I disagree, but I do think that it sometimes comes across as focusing too
> much on the details.  It might be good to summarize the general principals,
> and then list for the more legalistic bits as notes or footnotes.  Make it
> clear that a list isn't the *point*, but it does help to clarify.
>
I feel like the first two paragraphs tried to do exactly this. Is there
same specific part that didn't work for you?

I think the challenge here is that most ideas I have end up making the
early sections nearly as long. The list of principles is already formatted
to facilitate skimming and so I feel like this is a pretty good compromise
on the verbosity front. If you have specific ideas that you think would be
better, I'm all ears.

> 3) I really liked the suggestion down thread of reframing
"reporting" as
> "asking for moderation".  I think it needs to be clear that there
can be
> consequences, but focusing on resolving the situation at hand seems like a
> better starting point for most discussions.
>
There is a very important problem with calling this moderation. That
implies that the event has to *continue* and also implies some levels of
necessary on-going interaction. For a broad range of the ways that these
things can go wrong, it is really important that the person who has become
uncomfortable be able to leave the situation and feel safe. Moderation and
mediation don't provide that kind of safety for some, and I think we need
to design this to be supportive of the most challenging cases.

Of course, when moderation or mediation are the appropriate *responses* to
a report, I would hope they are used. Perhaps it would be helpful to add
them to the list? I'm imagining an added bullet point to the "Responses
may
include" section along the lines of:

* Providing either moderation or mediation to ongoing interactions (where
appropriate and safe).

Thoughts?

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

On 10/13/2015 03:55 PM, Chandler Carruth wrote:
> On Tue, Oct 13, 2015 at 2:45 PM Philip Reames 
> <listmail at philipreames.com <mailto:listmail at
philipreames.com>> wrote:
>
>     2) Several folks have mentioned that they'd like to see this less
>     verbose.  I disagree, but I do think that it sometimes comes
>     across as focusing too much on the details.  It might be good to
>     summarize the general principals, and then list for the more
>     legalistic bits as notes or footnotes.  Make it clear that a list
>     isn't the *point*, but it does help to clarify.
>
>
> I feel like the first two paragraphs tried to do exactly this. Is 
> there same specific part that didn't work for you?
I was more going for the details section.  Taking the "Be Welcoming" 
section as an example.  Suggested formatting:
- *Be welcoming.* We strive to be a community that welcomes and supports 
people of all backgrounds and identities.

    This includes, but is not limited to members of any race, ethnicity,
    culture, national origin, colour, immigration status, social and
    economic class, educational level, sex, sexual orientation, gender
    identity and expression, age, size, family status, political belief,
    religion, and mental and physical ability.

(i.e. indent the last sentence to separate key point from details.)

To be clear, this is a *really* minor point.  Think nitpick in code 
review, not a design objection.
>
>     3) I really liked the suggestion down thread of reframing
>     "reporting" as "asking for moderation".  I think it
needs to be
>     clear that there can be consequences, but focusing on resolving
>     the situation at hand seems like a better starting point for most
>     discussions.
>
>
> There is a very important problem with calling this moderation. That 
> implies that the event has to *continue* and also implies some levels 
> of necessary on-going interaction. For a broad range of the ways that 
> these things can go wrong, it is really important that the person who 
> has become uncomfortable be able to leave the situation and feel safe. 
> Moderation and mediation don't provide that kind of safety for some, 
> and I think we need to design this to be supportive of the most 
> challenging cases.
This is a completely reasonable point and definitely worth considering.

Part of what I'm aiming for is to avoid having a report be automatically 
a "big deal".  I want people to be able to speak up when they're
at all
uncomfortable without feeling like the only mechanism available 
automatically has major consequences and should be used only as a last 
resort.  Other ways to do this, I'm entirely open
to.
>
> Of course, when moderation or mediation are the appropriate 
> *responses* to a report, I would hope they are used. Perhaps it would 
> be helpful to add them to the list? I'm imagining an added bullet 
> point to the "Responses may include" section along the lines of:
>
> * Providing either moderation or mediation to ongoing interactions 
> (where appropriate and safe).
Seems reasonable.  Minor word smithing suggestion:
* Providing either moderation or mediation to ongoing interactions 
(where appropriate, safe, and desired by both parties).

(This part would be fine as either a phabricator review comment or a 
post commit suggestion for improvement.)
>
> Thoughts?
>
> -Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/ce06bbca/attachment.html>

On 10/13/2015 06:17 PM, Philip Reames wrote:
> (This part would be fine as either a phabricator review comment or a 
> post commit suggestion for improvement.)
Realized after sending my last that this sentence was unclear.  I meant 
that it was at a level of detail best addressed in the form of an actual 
review.  Doing this entirely by email is somewhat of a waste of time.  
It's minor enough that I'd be fine suggesting a patch to revise after 
the initial policy lands.

One implicit assumption I have that I should probably call out is that 
we will land a draft of this proposal, and then use our usual processes 
to revise it in minor ways.  Initial landing does not a policy make; I'd 
suggest we explicitly make this a draft for a while.  Once interested 
parties are relatively happy, we can send out an update to llvm-dev with 
a proposal to remove the draft-ness. I think we need to get a lot more 
visibility before this is ready to move out of draft state.

Philip

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