From: Shuah <shuah@kernel.org>
To: Theodore Ts'o <tytso@mit.edu>
Cc: Steven Rostedt <rostedt@goodmis.org>,
ksummit@lists.linux.dev,
tech-board-discuss@lists.linux-foundation.org,
shuah <shuah@kernel.org>
Subject: Re: [Tech-board-discuss] [MAINTAINERS SUMMIT] Maintainers Support Group
Date: Tue, 19 Sep 2023 16:32:05 -0600 [thread overview]
Message-ID: <19fc6e5b-3b20-7d4c-6e50-cc3bc5cea2da@kernel.org> (raw)
In-Reply-To: <ZQoG71Vdy9iLAcY1@mit.edu>
On 9/19/23 14:39, Theodore Ts'o wrote:
> On Tue, Sep 19, 2023 at 10:52:40AM -0600, Shuah wrote:
>> As a member of the CoC, I respectfully disagree with the statement "but all the
>> focus has mainly been around telling maintainers how to behave." This impression
>> might have been the result of one unfortunate incident that took place last year.
>> is only part of what CoC has been doing.
>>
>> A majority of reports are related to incorrect understanding of how the community
>> works and discusses technical issues. Most of them get resolved without involving
>> the community. This is behind the scenes silent work CoC does.
>>
>> It is unfortunate that CoC is being viewed as a body that is focused on telling
>> maintainers how to behave. I would encourage to not view CoC work based on one
>> or two cases that were outliers. CoC worked very hard to resolve them fairly and
>> that benefited the community as a whole.
>
> Shuah, I don't think this is the fault of the CoC. Much of it is in
> how people interpret the CoC, or think it should be adapted. For
> example, just this past week, on the maintainer's summit, this
> statement:
>
I agree with this statement that people have differing opinions on
the CoC role. There are people that don't think CoC is doing enough
and other side thinks it is focused on telling maintainers how to behave.
Neither is accurate.
People that think Coc isn't doing enough don't fully understand the
technical discussion dynamic and what constitutes a CoC violation,
and more importantly the role of a maintainer in making decisions
on accepting and rejecting patches.
The other side that thinks CoC is focused on "telling maintainers how
to behave" doesn't have visibility into the majority of reports CoC
determines that they fall into the category of normal technical
discussion and takes care of them behind the scenes.
>> Waah, waah, waah. The buffer cache is *trivial*. If you don't like the
>> buffer cache, don't use it. It's that simple.[1]
>
> ... resulted in Linus being accused as a CoC violation.
>
> I'm not sure that it qualifies as a CoC violation, but Dave Chinner
> certainly thought so, and publically accused Linus of that[2].
>
> Personally, I'm not convinced that people calling people out for real
> or imagined CoC violations is always going to be productive,
> especially when it wasn't an explicit personal attack. It's these
> sorts of edge cases is what causes some people to fear and badmouth
> CoC's. Which is, I think, unfortunate.
Yes. I agree that going CoC over disagreements isn't productive, neither
is looking the other way when real violation occur.
The question we have to answer as a community is are we better off with CoC
in place or not. I would think we are better off.
thanks,
-- Shuah
next prev parent reply other threads:[~2023-09-19 22:32 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-19 16:10 Steven Rostedt
2023-09-19 16:52 ` [Tech-board-discuss] " Shuah
2023-09-19 17:19 ` Steven Rostedt
2023-09-19 17:29 ` Steven Rostedt
2023-09-19 17:54 ` James Bottomley
2023-09-19 21:26 ` Shuah
2023-09-19 20:39 ` Theodore Ts'o
2023-09-19 21:02 ` Steven Rostedt
2023-09-20 12:03 ` Christian Brauner
2023-09-19 22:01 ` Theodore Ts'o
2023-09-19 22:07 ` Randy Dunlap
2023-09-19 22:40 ` Shuah
2023-09-19 22:32 ` Shuah [this message]
2023-09-19 22:53 ` Shuah
2023-09-19 17:03 ` Bart Van Assche
2023-09-19 17:21 ` Steven Rostedt
2023-09-19 22:55 ` Shuah
2023-09-19 23:21 ` Steven Rostedt
2023-09-20 7:06 ` Linus Walleij
2023-09-21 7:15 ` Jonathan Cameron
2023-09-20 19:52 ` Shuah
2023-09-20 22:54 ` Laurent Pinchart
2023-09-21 0:45 ` Shuah
2023-09-21 12:40 ` Linus Walleij
2023-09-21 12:56 ` Laurent Pinchart
2023-09-20 15:45 ` Mark Brown
2023-10-05 18:08 ` Jason Gunthorpe
2023-10-06 20:47 ` Linus Walleij
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19fc6e5b-3b20-7d4c-6e50-cc3bc5cea2da@kernel.org \
--to=shuah@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.org \
--cc=tech-board-discuss@lists.linux-foundation.org \
--cc=tytso@mit.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox