[PATCH] D122937: Provide the complete response and reporting Code of Conduct documentation. Remove the word draft from all documents, add information about the CoC committee expectations and add a place for transparency reports.

Tue Apr 19 08:51:25 PDT 2022

tonic marked 18 inline comments as done.
tonic added a comment.

I have addressed all the comments or responded why I did not make the change. I will be updating the patch next.

================
Comment at: llvm/docs/CodeOfConduct.rst:98
+
+If you believe someone is violating the code of conduct you can always report it to the LLVM Foundation Code of Conduct Committee by emailing conduct at llvm.org. All reports will be kept confidential. This isn’t a public list and only members of the advisory committee will receive the report. For details on what to include in the report, please see our :doc:`Reporting Guide <ReportingGuide>`.
+
----------------
aaron.ballman wrote:
> Please wrap to the usual 80-col limits and convert smart quotes like `’` into dumb quotes `'` (here and elsewhere in your changes).
> 
> Do we want to make `conduct at llvm.org` into links in this document so people can just click it if needed? (I don't believe that will add any additional spam burden on the account -- listing the address is sufficient to trigger spam.)
> 
> please see our Reporting Guide -> please see the Reporting Guide
Those style quotes are required to make the links work correctly. 

Anything with @ is automatically turned into a email link.

I made the our/the change.

================
Comment at: llvm/docs/CodeOfConduct.rst:119
+
+Transparency reports will be published here as they become available.
+
----------------
aaron.ballman wrote:
> Do we want to add any extra information about what's expected to be in the transparency report (or more importantly, what's expected to NOT make it into a transparency report) as not all readers may be familiar with this?
> 
> I see later that we do have some information on what's in the transparency reports elsewhere, so maybe we want to link to there from here?
This section is meant to just list them, but I will add a link to the description. 

================
Comment at: llvm/docs/ReportingGuide.rst:12

-* What happened and who was involved.
-* Whether this event constitutes a code of conduct violation.
-* Whether this is an ongoing situation, or if there is a threat to anyone's
-  physical safety.
+* For any incident involving an online platform (ie. mailing lists, forums, irc/discord/slack, etc) we ask that you make any reports by emailing conduct at llvm.org. This is received by all members of the CoC Committee.

----------------
aaron.ballman wrote:
> Same question here about whether we want to make a link for the email address.
Sphinx generates this into a link for the html pages automatically. 

================
Comment at: llvm/docs/ReportingGuide.rst:14

-If this is determined to be an ongoing incident or a threat to physical safety,
-the working groups' immediate priority will be to protect everyone involved.
-This means we may delay an "official" response until we believe that the
-situation has ended and that everyone is physically safe.
+* For a LLVM Developers’ Meeting has a Code of Conduct team. For each conference, their names and contact details are listed on the event webpage. You can also approach any other staff member, who can be identified by special badges and often found at the registration desk. All incidents reported in person at a  LLVM Developers’ Meeting will be emailed to the Code of Conduct Committee. 

----------------
aaron.ballman wrote:
> How does this change confidentiality of the report? e.g., should the reporter assume that in addition to the CoC team, all staff members have access to the report, or only the staff member contacted, something else?
I will modify this to make clear that the staff is there to help you find a Code of Conduct team member and not resolve the incident.

================
Comment at: llvm/docs/ReportingGuide.rst:16

-The working group will try to contact other parties involved or witnessing the
-event to gain clarity on what happened and understand any different
-perspectives.
+* For meetups, please report the incident to the local meetup organizers first. Each meetup will have a contact listed on the associated meetup page. If you feel uncomfortable with this or if you feel the incident was not well handled by the local organizers, please email conduct at llvm.org. All meetup organizers who receive an in person report are asked to email conduct at llvm.org with the incident information.

----------------
aaron.ballman wrote:
> I think this policy is reasonable, but it does leave some daylight for reports to be accidentally dropped if the meetup organizer doesn't pass the information along to the conduct team.
> 
> Would it make sense to modify this slightly to report the incident to the local meetup organizer AND CoC team at the same time, with the understanding that the local organizer should take immediate action and report back to the CoC team. This way, the CoC team is still alerted to the potential issue and it helps mitigate the risk that an event organizer doesn't report up (either accidentally or otherwise).
Sure, I will add this.

================
Comment at: llvm/docs/ReportingGuide.rst:26

-After any incident, the advisory committee will make a report on the situation
-to the LLVM Foundation board. The board may choose to make a public statement
-about the incident. If that's the case, the identities of anyone involved will
-remain confidential unless instructed by those individuals otherwise.
-
-Appealing
-=========
+* Your contact info (so we can get in touch with you). Include email and optionally a phone number.
+* Names or descriptions of anyone who was involved or who witnessed the incident.
----------------
aaron.ballman wrote:
> Should we add a bullet point discussing anonymous reporting?
 The process does require a working email so we can get more information from the reporter and get feedback on the resolution. It doesn't mean that someone can't create a new email and exclude personal information. However, I don't know if we should actively encourage anonymous reports either by explaining how to do it. 

================
Comment at: llvm/docs/ResponseGuide.rst:19
+* For LLVM meetups, the local organizers will be the first point of contact.
+* Any other event funded by the LLVM Foundation or listed on the LLVM website, will have a code of conduct response team or point of contact for CoC reports.
+
----------------
aaron.ballman wrote:
> It's not entirely clear that "listed on the LLVM website" is quite accurate. For example, we have working group meetings listed on the website, as well as community office hours, and neither of those will have a CoC response team. We may want to reword it slightly to say that there MAY be a code of conduct response team, but if there's not one specific to the event, file the concerns the usual way.
Well, this is talking about in person events. AFAIK no working groups are in person right now. But it will apply to other events such as workshops at conferences. This will be documented either on the website or in docs. 

However, all working groups should have a response/contact person(s) clearly listed on the website for multiple reasons (including CoC immediate response). I plan to contact all working groups to gather this information in the coming weeks as it is not listed currently. Office hours will also need to mention this somewhere and right now that is on the webpage, but it should also be on the calendar listing as well. 

================
Comment at: llvm/docs/ResponseGuide.rst:59
+6. The :ref:`resolution<Resolutions>` is implemented.
+7. All reports, data, notes, and resolutions are logged in a private location (ie. Google Drive or other database).
+
----------------
aaron.ballman wrote:
> Do we have a retention policy we want to mention for how long we keep all this data? (I read this as "we retain it forever".)
In my opinion, it's going to depend on the violation and resolution. As the CoC committee will be changing over time, some data is important to keep longer than others. I think the CoC is going to have to figure this out over time. 

================
Comment at: llvm/docs/ResponseGuide.rst:92
+
+
+The committee will aim to have a resolution agreed upon within two weeks of receipt of the incident report. In the event that a resolution cannot be determined within that time, the CoC committee will respond to the reporter(s) with an updated and projected timeline for resolution. 
----------------
mehdi_amini wrote:
> Is the double empty line intentional?
> 
Nope. Will be fixed in updated version.

================
Comment at: llvm/docs/ResponseGuide.rst:107
+
+The reportee will be given 3 days to respond with the option to request additional time if needed and subject to approval of the CoC Committee.
+
----------------
aaron.ballman wrote:
> mehdi_amini wrote:
> > hubert.reinterpretcast wrote:
> > > Should this be business days with consideration for the locality, etc. of the reportee?
> > I find "business days" to be quite un-inclusive actually, in particular for OSS projects. Not everyone is paid to work on the project and if someone reports something on a Monday, they may only be able to dedicate significant more time on their week end for example.
> > I would suggest to use "a week" instead to cover "more people's schedule".
> Given how many three-day weekends exist in different places, I agree that three days may be a bit tight and seven might be a bit more palatable. However, I'm also not opposed to three days because I understand the need for addressing the incident in a timely manner. But I'd avoid "business days" (that also gets into things like whether a national holiday is or isn't a business day, etc).
I will change this to a week as I agree it would meet more schedules. 

================
Comment at: llvm/docs/ResponseGuide.rst:127
+* An imposed suspension (i.e. asking someone to “take a week off” from mailing lists, bug tracker, IRC, Discord, repositories, or other communication forms). 
+* A permanent or temporary ban from some or all LLVM Project spaces (online or in person).
+
----------------
mehdi_amini wrote:
> Does that include forbidding someone to send a patch to the project for example? What if this person published a patch, can someone else still cherry-pick it in the repo with the author attribution?
> 
> (I would think that a very extreme situation would be needed to trigger such a response anyway)
Most likely yes. All of our methods to submit a patch to the project go through some sort of infrastructure - mailing list or Phab. So their access to those things would be removed through a ban.  

If someone gets their permission and wants to take over a patch as their own then they can do so. However, they should not act as a proxy for someone who is banned. This would now be their patch. 

This is a very specific situation and if someone is given a ban, the CoC committee would provide the actual details of the ban and have final say on this. 

================
Comment at: llvm/docs/ResponseGuide.rst:129
+
+
+Once a resolution is agreed upon, but before it is enacted, the committee will contact the reporter and any other affected parties to explain the proposed resolution. They will ask if this resolution is acceptable and must note feedback for the record. However, the committee is not required to act on this feedback.
----------------
mehdi_amini wrote:
> Is the double empty line intentional?
No, will fix.

================
Comment at: llvm/docs/ResponseGuide.rst:142
+
+Appeals can be requested up to 30 days after a resolution has been communicated to the individual(s). Appeals will be evaluated within a reasonable time frame.
+
----------------
aaron.ballman wrote:
> Do we want to nail "reasonable time frame" down further? I'd have guessed we'd want to guarantee some resolution within some time period (two week goal, as with the original report?)
Sure, I can change this.

================
Comment at: llvm/docs/ResponseGuide.rst:177
+.. _Write The Docs Response Guide: https://www.writethedocs.org/code-of-conduct/#guidelines-for-reporting-incidents
+
----------------
mehdi_amini wrote:
> Formatting nit: this may not be very important, but this file does not have an empty line after the section titles.
Ok, will be fixed in next revision.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D122937/new/

https://reviews.llvm.org/D122937