[Ksummit-discuss] [MAINTAINER TOPIC FOR KS] CoC and Linus position (perhaps undocumented/closed/limited/invite session)
Laurent Pinchart
laurent.pinchart at ideasonboard.com
Thu Sep 20 13:55:46 UTC 2018
Hi Tim,
On Thursday, 20 September 2018 16:49:40 EEST Tim.Bird at sony.com wrote:
> On Thu, 20 Sep 2018 09:33:05 +0300 Mauro Carvalho Chehab wrote:
> > Jani Nikula <jani.nikula at intel.com> escreveu:
> >> On Thu, 20 Sep 2018, Tim.Bird at sony.com wrote:
> >>> 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.
> >>
> >> Agreed.
> >>
> >> I think there's much more value in adopting a widely used code of
> >> conduct than writing your own, or even trying to tweak it. If a project
> >> uses the Contributor Covenant, you pretty much know the rules without
> >> actually having to read another document and wonder what this all means.
> >> In this regard, it's really not unlike the GPL for copyleft licenses;
> >> one acronym tells you what you can and can't do.
> >>
> >> With that perspective, I think the changes proposed in this thread do
> >> more harm than good. If people still insist the text should be improved,
> >> I think the proper flow is to file issues or pull requests to
> >> Contributor Covenant upstream [1], and later update to a new version of
> >> the document.
> >
> > The main experience of the Contributor Covenant's author seems to be
> > on Github. There is a fundamental difference between a Github-based
> > project workflow and the Kernel: there, everything happens inside a GUI
> > interface. Usually, those projects don't have a large number of
> > maintainers, nor contributors. Message traffic is typically not high.
> >
> > On such kind of interface, the maintainers can edit or delete all
> >
> > kinds of messages, even posted by a third party. So, a text like:
> > "Maintainers have the right and responsibility to remove, edit,..."
> >
> > would work. If the number of messages are small, it is also an easy
> > task.
> >
> > It could also work on a smaller e-mail-based project where there is
> > just one or two moderated ML.
> >
> > However, on a higly e-mail based project like the Kernel, where we receive
> > hundreds to thousands of messages per day, and we have a large
> > number of mailing lists, in order to comply with that CoC statement,
> > all email lists should be moderated. I can't imagine any way to have
> > a list like LKML moderated. Even moderating the linux-media ML nowadays
> > would be really hard, and would be someone's full time job.
> >
> > Even if LF hires a team of moderators for all Kernel mailing lists,
> > if someone cross-post a message on more than one list, different
> > moderators could take different measurements, with could be a problem,
> > if the same email is threated different by the different moderators.
> >
> > Not practical (and it comes with a cost).
> >
> > Using the terms of the CoC, by not taking any measure to stop
> > offensive posts, maintainers wouldn't be "acting in good faith".
> > So, maintainers are violating the policy.
> >
> > Also, if someone felt abused, the "unacceptable behavior may be
> > reported by contacting the Technical Advisory Board (TAB)".
> > The *may* word indicates that he can also go to other places to
> > do a similar complain. Implicitly, it opens space to go to court.
> >
> > So, the practical effect is that, if someone wants to fire
> > a random maintainer, all it has to do is to create a fake account,
> > send a bunch of random offensive messages to himself on his real
> > account, and then complain - first on TAB - then filing a lawsuit
> > (with can envolve both the TAB and the maintainer).
>
> I think the risk of a lawsuit is blown out of proportion.
> But, I think your characterization of the CoC as not a great fit,
> due to the issues you describe above, is justified.
>
> I believe that possibly there's a misperception about the
> "direction" of responsibility by Maintainers in the CoC. For most
> projects, the Maintainers are the top of the hierarchy, with all
> the power. And this section reads to most communities like
> a pledge that the Maintainers will defend the community
> and the rank-and-file members in it from abusive behavior.
> That is, they will take it upon themselves to do this, when
> they wouldn't face any repercussions for not making
> such a pledge. It's an honorable and noble thing.
>
> The Linux kernel is a bit more complex than that. Maintainers at
> all levels are usually both contributors as well as leaders, and they're
> squished in the middle between other contributors and Linus.
>
> No one wants maintainers or reviewers to feel overwhelmed
> by more responsibilities. I think it's a well-acknowledged fact that
> maintainers and reviewers are a precious and over-taxed resource.
> And we certainly don't want maintainers fearing repercussions
> for failing to enforce stuff. I don't believe there is any record of
> an extreme action, like banning, for anyone failing to enforce
> a CoC.
>
> > That's why I don't think that, the way it is, this CoC applies
> > to us. The way it is, it is just FUD. I can see a few
> > alternatives:
> >
> > 1) Revert the CoC patch;
> > 2) Use another CoC that would work for e-mail-based workflows;
> > 3) Patch it - either changing the text of the CoC or adding
> > a prologue adding ammendments to prevent the above risk
> > and solving the e-mail addresses on review tags.
> >
> > My view is that, currently, we have a major issue at the
> > contributing process. So, if nothing happens, I may wait until
> > the Maintainer's Summit before sending any pull requests
> > upstream.
>
> May I suggest that a more productive way to proceed is to keep
> doing what you usually do. The TAB is working out the details
> of enforcement policy, and a FAQ to go along with the CoC, that we
> plan to present at the Maintainers Summit.
May I suggest a (public) forum where everybody could post their concerns ? One
big concern is that the new code of conduct was dumped on the community
without much warning, dumping a FAQ the same way without consulting the user
base could produce a similar feeling.
Discussing the FAQ in public would be best but I understand that would be
difficult as it would very well quickly go in all kinds of random directions.
A way to report our concerns and feel heard would in my opinion be a good
middle ground.
> I think the roll-out of CoC enforcement will be a long, slow process, with
> plenty of time for us to hash out what we, as a community, believe are the
> best practices for dealing with violations. I think the vast majority of
> the kernel community consists of respectful and well-meaning
> individuals, who will see no negative repercussions personally, from
> the adoption of this CoC.
--
Regards,
Laurent Pinchart
More information about the Ksummit-discuss
mailing list