The LLVM Compiler Infrastructure
Site Map:
Search this Site

Useful Links
Release Emails
14.0.0: Mar 2022
13.0.1: Feb 2022
13.0.0: Oct 2021
12.0.1: Jul 2021
12.0.0: Apr 2021
11.0.1: Jan 2021
All Announcements

Maintained by the
llvm-admin team
April 28, 2022 - CoC Transparency Report

The LLVM Code of Conduct sets standards for how the community interacts with each other and is enforced by a Code of Conduct committee. This committee follows publically disclosed reporting and response procedures. One of the requirements is to publish a transparency report of any incidents reported. These reports provide the community with transparency into if and how the Code of Conduct committee responds and resolves incidents.

The Code of Conduct Advisory committee currently consists of the LLVM Foundation Board of Directors and a sub-committee of 4 members was selected to investigate the incoming Code of Conduct reports.

5 separate incidents were described as a part of a single incident report, and 2 were determined to be LLVM Code of Conduct violations. This report was received on September 30, 2021.

The 2 incidents were concluded as violating the rules of being respectful, being careful in the words that you choose and being kind to others, and finally, when we disagree, try to understand why. Additionally, the committee has found one incident, though not a code of conduct violation, to be a potential LLVM Developer Policy concern.

To address the 2 Code of Conduct violations, the acting committee gave the reportee a verbal warning and a behavior plan to use when encountering these situations in the future.

Regarding LLVM Developer policy concern, this portrayed some fragmentation in the current process of code review and policy documentation. This is ongoing and awaiting final resolution.

  • A contributor reported that a patch on LLVM’s Phabricator instance had been merged without addressing all the concerns and without complete approval of a requested reviewer. After the reviewer inquired why such concerns weren’t addressed, the patch author abruptly dismissed those concerns. The committee deemed this as not respectful and informed the patch author of different approaches to avoid responding this way in future interactions.
  • A set of core developers discussed an approach to tackle cyclic dependencies. One individual disagreed with the approach and that was expressed harshly across three different code reviews on LLVM’s Phabricator instance. The committee concluded that these comments were not direct violations.
  • During an exchange on LLVM’s Discord where an individual asked for justification on a technical direction, the response received back gave no clear justification and instead refuted that giving rationale is not productive as it would result in repetitive discussions. The committee concluded this was also not a direct violation but represents a general pattern of communication that is concerning.
  • On LLVM’s Phabricator instance, a reviewer requested the reasoning behind the code changes in the patch. After several pings, the author responded by refusing to answer the concern. The committee informed the patch author that this did not adhere to the Code of Conduct rule “When we disagree, try to understand why”. This repeated situation also identified the necessity for a well defined clear path of escalation for disagreements that the committee will scope out with related code owners.
  • The commit was then merged, where the reviewer found additional changes that violated the policy for this particular type of patch, e.g. applying functional changes to a NFC commit. The code owner ultimately requested that those portions be reverted where the author agreed and requested a formal review for that. This was not found to be a violation.
  • A contributor reported that an individual recommended in several code reviews that clang-format should not be applied and raised further concerns with others’ white spacing. The committee inquired more context from the code owner, where they specified that the tool doesn’t conform nicely with that portion of the codebase. Though this isn’t a CoC violation, this inconsistency with the LLVM Developer Policy should be documented to reduce confusion for contributors.