Re: [Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)

[<Tim.Bird@sony.com>]

> -----Original Message-----
> From: Mauro Carvalho Chehab
> Em Thu, 20 Sep 2018 06:23:05 +1000
> Dave Airlie <airlied@gmail.com> escreveu:
> 
> > On Thu, 20 Sep 2018 at 05:56, Mauro Carvalho Chehab
> > <mchehab+samsung@kernel.org> wrote:
> > >
> > > Em Wed, 19 Sep 2018 10:16:21 -0400
> > > James Bottomley <James.Bottomley@HansenPartnership.com>
> escreveu:
> > >
> > > > On Wed, 2018-09-19 at 09:03 -0300, Mauro Carvalho Chehab wrote:
> > > > > Em Wed, 19 Sep 2018 08:37:49 -0300
> > > > > Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu:
> > > > >
> > > > > > Em Wed, 19 Sep 2018 07:28:02 -0400
> > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> escreveu:
> > > > > >
> > > > > > > On Tue, 2018-09-18 at 16:29 -0300, Mauro Carvalho Chehab wrote:
> > > > > > > > Em Tue, 18 Sep 2018 10:02:08 -0400
> > > > > > > > James Bottomley <James.Bottomley@HansenPartnership.com>
> > > > > > > > escreveu:
> > > > > > > >
> > > > > > > > > > After the past 2-3 days I get the feeling there are
> > > > > > > > > > maintainers unsure about how this affects them and I think
> > > > > > > > > > assuaging those fears might be a good thing.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > From my perspective, which is probably fairly widespread:
> > > > > > > > > we're already pretty much policing the lists using a set of
> > > > > > > > > rules which match fairly closely to the new CoC, so there
> > > > > > > > > should really be no huge impact.
> > > > > > > >
> > > > > > > > After carefully reading it a couple of times, I think it has a
> > > > > > > > huge impact.
> > > > > > > >
> > > > > > > > The more immediate impact is with regards to this wording:
> > > > > > > >
> > > > > > > >       "Examples of unacceptable behavior by participants
> > > > > > > > include:
> > > > > > > >       ...
> > > > > > > >       * Publishing others’ private information, such as a
> > > > > > > > physical or electronic
> > > > > > > >         address, without explicit permission"
> > > > > > > >
> > > > > > > > When we publish a patch with a Signed-off-by, Reviewed-by,
> > > > > > > > Acked-by, Requested-by, Suggested-by, etc, we are actually
> > > > > > > > publishing an electronic address.
> > > > > > > >
> > > > > > > > The DCO 1.1 has an explicit clause that would allow to publish
> > > > > > > > the email address from the SOB's, together to its
> > > > > > > > redistribution:
> > > > > > > >
> > > > > > > > "       (d) I understand and agree that this project and the
> > > > > > > > contribution
> > > > > > > >             are public and that a record of the contribution
> > > > > > > > (including all
> > > > > > > >             personal information I submit with it, including my
> > > > > > > > sign-off) is
> > > > > > > >             maintained indefinitely and may be redistributed
> > > > > > > > consistent with
> > > > > > > >             this project or the open source license(s)
> > > > > > > > involved."
> > > > > > > >
> > > > > > > > But that doesn't cover the other tags.
> > > > > > >
> > > > > > > I disagree with the strictness of the interpretation: "including
> > > > > > > all personal information I submit with it" covers all the other
> > > > > > > tags. Although the expectation is the permission was obtained by
> > > > > > > one of the people adding the sign off because that's how the DCO
> > > > > > > flows, which might be a bit wishful thinking, we've always
> > > > > > > thought that it covers the additional tags for the use case
> > > > > > > section (d) was created for: national data protection acts and if
> > > > > > > it covers that case, it surely covers the CoC permission case.
> > > > > >
> > > > > > I see your point. Yes, that places the SOB signer's as^W backs
> > > > > > responsible for such thing.
> > > > > >
> > > > > > > Additionally, as others have said, if the tag was added from
> > > > > > > information in the public mailing list, it's not private within
> > > > > > > the meaning of the CoC.  I think the electronic mail example in
> > > > > > > the CoC is simply because it's more used in a github type
> > > > > > > environment where email addresses are private and not
> necessarily
> > > > > > > part of the workflow.
> > > > > >
> > > > > > If it doesn't apply, it should be removed. Legal documents with
> > > > > > unneeded terms only cause confusion (and this *is* a legal
> document
> > > > > > - a
> > > > >
> > > > > In time:
> > > > >     and this *is* a legal document -> I believe that this is a
> > > > > legal document
> > > > >
> > > > > I'm actually waiting for a legal advice about this under US laws.
> > > > > Under Brazilian laws (and probably other civil law system), I'm
> > > > > almost sure it is a contract - if this is a valid or a void one has
> > > > > yet to be seen.
> > > >
> > > > OK, I can't disagree with this.  It does definitely impose obligations
> > > > that are legally meaningful.  However ...
> >
> > A legal document would mean there were legal repercussions for
> > violating it, like violating copyright laws or getting fired for
> > violating your employment contract.
> >
> > This doesn't seem to stand on that, this is a set of guidelines for
> > how a community should act.
> 
> The previous CoC were a set of guidelines. That's not the case of
> this one anymore. It has a legal language, defining a mediation forum
> (TAB), improper conducts, penalties, scope, responsibilities, etc.
Just because it has these sections, and language that is also used
in legal documents, does not make it a legal document.

My view is that it's intended to be a social document, with guidelines
for actions within the community  (Actions by maintainers, actions
by contributors, actions by the TAB).  To me it's more like rules for
a party at my house.  If someone doesn't abide by the rules, I'll ask
them to leave the party.  And I'll ask others at the party to remind people
to abide by the rules.  But the person kicked out can hardly call the cops
on me for doing so.
   -- Tim

> 
> > The people interpreting the document are
> > members of the community that we in theory trust (via TAB elections).
> 
> My view is that, the way it is, if someone is not happy with TAB
> decisions, it can use CoC to fill a suit in court.

Is there an example where this has happened, or even come close to
happening (e.g. someone verbally threatened to sue based on a 
CoC action like e-mail banning?)  If so, I'd like to look at the details.
The only things I can think of are cases where there actually is a legal
document governing granting access to, for example, a social media
site.

> If this happens,
> I suspect that it will turn very badly, as the improper conducts
> are too wide. The ones that will be hurt are the maintainers
> (as about half of the document is about duties and penalties to
> maintainers).
> 
> I don't see there a single word about penalties for false claims.
Demonstrably false claims, made in bad faith, would violate the
CoC, IMHO.  So they'd be covered.
> 
> > These are examples of things that cause problems, and guidelines to
> > follow to avoid bad behaviours, but the intent still matters at the
> > end of the day. If someone complains you accidentally tagged their
> > email, the people on the complaints review will figure that out.
> >
> > It's funny we don't really have this problem with the drm so far, due
> > to mainly group maintainership. If someone sends me a private email
> > unless it's a security issue, I ask them to resend it to the public
> > lists and/or use a public bugzilla, before I action it. This ensures
> > that members of group teams can engage as a group instead of one
> > maintainer having the primary inbox load.
> >
> > I've no objections to clarifying this sort of thing and I think it's
> > important that we do, but trying to turn this document into something
> > like an legal employment contract isn't going to be helpful.
> 
> I'm actually in favor of the opposite: to remove everything that looks
> like a legal contract.
> 
> Something like the patch below.

Since this CoC has been used by a LOT of projects, it might be worth
researching the discussions leading to the adoption of it in those
other projects, to see if similar issues were raised, and what  the response
was.  I'm not sure if I'll have time to do that myself in the short term,
but I'll try to at least look at some of the public revision history of the CoC
to see if there's any enlightenment there.

Regards,
 -- Tim


> 
> PS. It incorporates Tony's suggestions, with an addition with regards
> to IRC public channels. It is not common, but sometimes we give
> credits on some patches from people that commented on IRC chats,
> and that sometimes we don't know their emails.
> 
> I opted to not realign the document, in order to make easier to review.
> 
> Thanks,
> Mauro
> 
> diff --git a/Documentation/process/code-of-conduct.rst
> b/Documentation/process/code-of-conduct.rst
> index ab7c24b5478c..aa763c51f421 100644
> --- a/Documentation/process/code-of-conduct.rst
> +++ b/Documentation/process/code-of-conduct.rst
> @@ -30,50 +30,48 @@ Examples of unacceptable behavior by participants
> include:
>    advances
>  * Trolling, insulting/derogatory comments, and personal or political attacks
>  * Public or private harassment
> -* Publishing others’ private information, such as a physical or electronic
> -  address, without explicit permission
> +* Publishing others' private information, such as a physical or electronic
> +  address[1], without explicit permission
>  * Other conduct which could reasonably be considered inappropriate in a
>    professional setting
> 
> +[1] Note that electronic addresses used on public mailing lists and public
> +IRC channels associated with the Kernel community are not considered to
> be
> +private information and can (in fact should) be used to give credit in
> +Reported-by, Acked-by, Tested-by etc. tags.
> 
>  Our Responsibilities
>  ====================
> 
>  Maintainers are responsible for clarifying the standards of acceptable
> behavior
> -and are expected to take appropriate and fair corrective action in response
> to
> +and are asked to take appropriate and fair corrective action in response to
>  any instances of unacceptable behavior.
> 
> -Maintainers have the right and responsibility to remove, edit, or reject
> -comments, commits, code, wiki edits, issues, and other contributions that
> are
> +Maintainers have the right to remove, edit, or reject
> +comments, commits, code, wiki edits, issues and other contributions that
> are
>  not aligned to this Code of Conduct, or to ban temporarily or permanently
> any
>  contributor for other behaviors that they deem inappropriate, threatening,
> -offensive, or harmful.
> +offensive or harmful.
> 
>  Scope
>  =====
> 
>  This Code of Conduct applies both within project spaces and in public spaces
> -when an individual is representing the project or its community. Examples of
> -representing a project or community include using an official project e-mail
> -address, posting via an official social media account, or acting as an
> appointed
> -representative at an online or offline event. Representation of a project
> may be
> +when an individual is representing the project or its community. It also
> +applies to e-mails using kernel.org address. Representation of a project may
> be
>  further defined and clarified by project maintainers.
> 
>  Enforcement
>  ===========
> 
> -Instances of abusive, harassing, or otherwise unacceptable behavior may be
> +Instances of abusive, harassing, or otherwise unacceptable behavior should
> be
>  reported by contacting the Technical Advisory Board (TAB) at
>  <tab@lists.linux-foundation.org>. All complaints will be reviewed and
>  investigated and will result in a response that is deemed necessary and
> -appropriate to the circumstances. The TAB is obligated to maintain
> -confidentiality with regard to the reporter of an incident.  Further details of
> +appropriate to the circumstances. The TAB will maintain
> +confidentiality with regards to the reporter of an incident. Further details of
>  specific enforcement policies may be posted separately.
> 
> -Maintainers who do not follow or enforce the Code of Conduct in good faith
> may
> -face temporary or permanent repercussions as determined by other
> members of the
> -project’s leadership.
> -
>  Attribution
>  ===========
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__lists.linuxfoundation.org_mailman_listinfo_ksummit-
> 2Ddiscuss&d=DwIGaQ&c=fP4tf--1dS0biCFlB0saz0I0kjO5v7-
> GLPtvShAo4cc&r=rUvFawR4KzgZu1gSN5tuozUn7iTTP0Y-
> INWqfY8MsF0&m=n5VBZF5ShttXTIqCERDxd88PVFiYKmeFXfyy5oZcCck&s=zc
> 7vcXOl4dMEPO_2XDmFX0UNg6up4d7ZMKLKFwSaiKQ&e=