Re: [Ksummit-discuss] [TECH-TOPIC] Review - Code of Conduct: Let's revamp it.

[Mauro Carvalho Chehab <mchehab+samsung@kernel.org>]

Em Mon, 24 Sep 2018 19:31:07 +0000
Jason Cooper <jason@lakedaemon.net> escreveu:

> All,
> 
> On Mon, Sep 24, 2018 at 08:24:07AM -0600, Shuah Khan wrote:
> > I have been trying to follow various threads on this topic and none of them address
> > the review of this patch that went in. There is no mistake in the title of this topic.
> > I do consider this topic to be more general than limited to Maintainer Summit. Hence,
> > the choice of a wider Technical designation.  
> 
> fwiw, I agree with the insufficient scope, and the lack of public
> mailinglist discussion.
> 
> I'd like to make a drive-by observation (or two), if I may.  The kernel
> community is *huge* and *active* in comparison to most other projects.
> It also has a lot more history than most others.  That history isn't
> stored in a database, only to be accessed through a web page, accepting
> the single database as canonical.  Rather, the history is stored in many
> places, accessible by many different methods, and verifiable against
> other remote copies of the history.
> 
> This difference is an understated advantage of the kernel development
> process.  Once you say "it", you can never refute that you said it.  The
> history itself provides a conscious check.  As a result, I don't think a
> CoC in any form is going to cause any sort of material change in anyones
> behavior.  Rather, it'll just push away valuable and scarce talent.
> 
> The second observation is that trying to adopt a single CoC for the
> _entire_ Linux development community is an exercise in futility.  As
> Daniel Vetter has mentioned many times in these recent discussions, dri
> has been happily living under their own CoC for quite some time.  So we
> can gather a) it works for them, and b) it doesn't bother any other
> subsystems.
> 
> So why are we trying to apply a single CoC to everyone?  Why not let
> each subsystem / sub-community adopt their own and see how it goes?  A/B
> test it.  It could either be a footer link for the respective
> mailinglist, or a link in MAINTAINERS.  Any community not specifying one
> defaults to the Code of Conflict.

Well, we have a privacy policy for media development that touches some
of the items covered by the CoC:

	https://linuxtv.org/wiki/index.php/LinuxTVWiki:Privacy_policy

The rationale behind it is very different than the one for the CoC...
it was added mainly to comply to the new EU legislation.

It is based on Wikipedia privacy policy (with some amendments), as the
main thing that we host there (where maintainers don't have control) are
wiki pages.

Yet, while not a CoC, it says things like:

   "LinuxTV is collaborative, with users writing most of the policies and selecting from amongst themselves people to hold certain administrative rights. These rights may include access to limited amounts of otherwise nonpublic information about recent contributions and activity by other users. They use this access to help protect against vandalism and abuse, fight harassment of other users, and generally try to minimize disruptive behavior on the sites."

In other words, it crosses some lines with this CoC. It also explicitly
says that:

	"Any information you post publicly on the Wiki or send via e-mail to a discussion list is just that – public. For example, if you put your mailing address on your talk page, that is public, and not protected by this Policy. And if you edit without registering or logging into your account, your IP address will be seen publicly. Please think carefully about your desired level of anonymity before you disclose personal information on your user page or elsewhere."

That's said, I like the concept of global CoC, but you touched an
interesting point: it may conflict with already-existing CoC and similar
documents.

> I'd like to assume the backdoor method the CoC was introduced was purely
> to avoid a never-ending bikeshed.  And the subsequent threads are
> evidence that it didn't take a prognosticator to predict the mess.
> 
> Perhaps that's an indicator that it shouldn't be done that way.  Maybe
> approaching the problem on a per-sub-community will work better.  I
> dunno.
> 
> Just my 2 cents.
> 
> 
> Thanks,
> 
> Jason.
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss



Thanks,
Mauro