[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <f0afe22e-60c4-4389-8bd2-ff79d65f002c@linuxfoundation.org>
Date: Tue, 12 Nov 2024 15:32:43 -0700
From: Shuah Khan <skhan@...uxfoundation.org>
To: Daniel Vetter <daniel@...ll.ch>
Cc: gregkh@...uxfoundation.org, corbet@....net, workflows@...r.kernel.org,
rdunlap@...radead.org, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org, Linus Torvalds
<torvalds@...ux-foundation.org>, Miguel Ojeda <ojeda@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Steven Rostedt <rostedt@...dmis.org>, Dan Williams
<dan.j.williams@...el.com>, Theodore Ts'o <tytso@....edu>,
Shuah Khan <skhan@...uxfoundation.org>
Subject: Re: [PATCH v2] Documentation/CoC: spell out enforcement for
unacceptable behaviors
On 11/12/24 12:21, Daniel Vetter wrote:
> On Mon, 11 Nov 2024 at 17:39, Shuah Khan <skhan@...uxfoundation.org> wrote:
>> The Code of Conduct committee's goal first and foremost is to bring about
>> change to ensure our community continues to foster respectful discussions.
>>
>> In the interest of transparency, the CoC enforcement policy is formalized
>> for unacceptable behaviors.
>>
>> Update the Code of Conduct Interpretation document with the enforcement
>> information.
>>
>> Acked-by: Linus Torvalds <torvalds@...ux-foundation.org>
>> Acked-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>> Acked-by: Miguel Ojeda <ojeda@...nel.org>
>> Acked-by: Dave Hansen <dave.hansen@...ux.intel.com>
>> Acked-by: Jonathan Corbet <corbet@....net>
>> Acked-by: Steven Rostedt <rostedt@...dmis.org>
>> Acked-by: Dan Williams <dan.j.williams@...el.com>
>> Acked-by: Theodore Ts'o <tytso@....edu>
>> Signed-off-by: Shuah Khan <skhan@...uxfoundation.org>
>> ---
>>
>> Changes since v1:
>> - Updates Acks with Ted's ack.
>> - Fixes subsection formatting as per Randy's suggestion.
>> - Fixes a spelling error.
>>
>> .../code-of-conduct-interpretation.rst | 52 +++++++++++++++++++
>> 1 file changed, 52 insertions(+)
>>
>> diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst
>> index 66b07f14714c..ebddf218341d 100644
>> --- a/Documentation/process/code-of-conduct-interpretation.rst
>> +++ b/Documentation/process/code-of-conduct-interpretation.rst
>> @@ -156,3 +156,55 @@ overridden decisions including complete and identifiable voting details.
>> Because how we interpret and enforce the Code of Conduct will evolve over
>> time, this document will be updated when necessary to reflect any
>> changes.
>> +
>> +Enforcement for Unacceptable Behavior Code of Conduct Violations
>> +----------------------------------------------------------------
>> +
>> +The Code of Conduct committee works to ensure that our community continues
>> +to be inclusive and fosters diverse discussions and viewpoints, and works
>> +to improve those characteristics over time. The Code of Conduct committee
>> +takes measures to restore productive and respectful collaboration when an
>> +unacceptable behavior has negatively impacted that relationship.
>> +
>> +Seek public apology for the violation
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +The Code of Conduct Committee publicly calls out the behavior in the
>> +setting in which the violation has taken place, seeking public apology
>> +for the violation.
>> +
>> +A public apology for the violation is the first step towards rebuilding
>> +the trust. Trust is essential for the continued success and health of the
>> +community which operates on trust and respect.
>> +
>> +Remedial measures if there is no public apology for the violation
>> +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> +
>> +The Code of Conduct Committee determines the next course of action
>> +to restore the healthy collaboration by recommending remedial measure(s)
>> +to the TAB for approval.
>> +
>> +- Ban violator from participating in the kernel development process for
>> + a period of up to a full kernel development cycle. The Code of Conduct
>> + Committee could require public apology as a condition for lifting the
>> + ban.
>> +
>> +The scope of the ban for a period of time could include:
>> +
>> + a. denying patch contributions and pull requests
>> + b. pausing collaboration with the violator by ignoring their
>> + contributions and/or blocking their email account(s)
>> + c. blocking their access to kernel.org accounts and mailing lists
>> +
>> +Once the TAB approves one or more of the measures outlined in the scope of
>> +the ban by a two-thirds vote, the Code of Conduct Committee will enforce
>> +the TAB approved measure(s) in collaboration with the community, maintainers,
>> +sub-maintainers, and kernel.org administrators.
>
> This is a detail I missed at first, but I think it's a very important
> one and needs to be highlighted.
The paragraph after this one clears these questions and concerns.
>
> Years ago when the kernel CoC was put in plae, there was a very long
> discussion around whether maintainers are required to enforce the CoC,
> or not. The rather strong consensus was that they are not responsible,
> but help is appreciated, as documented in this patch: c1d1ba844f01
> ("Code of conduct: Fix wording around maintainers enforcing the code
> of conduct")
>
> This was also acknowledged once more in a patch merged two years ago
> with c1d1ba844f01 ("Code of conduct: Fix wording around maintainers
> enforcing the code of conduct") by changing "decisions by the
> committee" into "decisions regarding enforcement recommendations", to
> make it very explicit that they're just recommendations to the TAB and
> maintainers and that the CoC team does not have independent
> enforcement powers.
>
> The approval by the TAB is still here, but maintainers don't seem to
> get a say anymore. Is this the intention, because it seems to be a
> really substantial change? From our experience on the fd.o side, there
> is a subset of maintainers who do not appreciate this responsibility
> at all and very much would not like to have it. Given that, and the
> kernel's strong consensus a few years ago against this I don't think
> enlisting maintainers for enforcement without a wide agreement is
> going to be well received - even when personally I think it's the
> right approach to CoC enforcement, I did not put an ack on that patch
> for clear reasons.
>
> Also, if a maintainer refuses to implement an enforcement decision,
> will they be sanctioned too? Since this is all an entirely new section
> and does not touch any of the existing sections I'm also not clear on
> when one or the other rules apply, and how they interact.
>
> This part looks confusing to me, and a bit in a scary way.
>
> Cheers, Sima
>
>
>> +
>> +The effectiveness of the remedial measure(s) approved by the TAB depends
>> +on the trust and cooperation from the community, maintainers, sub-maintainers,
>> +and kernel.org administrators in enforcing them.
This paragraph clearly indicates the scope. The key work is "cooperation".
It isn't the intent to force maintainers to enforce it. On the contrary,
the Code of Conduct Committee's ability to enforce a ban relies on the
cooperation from the community.
There are several checks and balances for bans can be approved, such as
the CoC Committee has to agree on the ban, the TAB has to agree on it
and vote on it.
This document makes that very clear.
thanks,
-- Shuah
Powered by blists - more mailing lists