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

[Daniel Vetter <daniel.vetter@ffwll.ch>]

On Thu, Sep 20, 2018 at 9:01 AM, Josh Triplett <josh@joshtriplett.org> wrote:
> On Thu, Sep 20, 2018 at 09:33:05AM +0300, Jani Nikula wrote:
>> On Thu, 20 Sep 2018, Tim.Bird@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.

Yup, this matches the universal recommendation we've received when
looking into what CoC to wrap freedesktop.org in.

>> 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.
>
> Seconded. I've seen many changes accepted upstream, and it seems
> reasonable to start there first.
>
> To the extent we need any kernel-specific process clarifications that
> *can't* usefully go upstream, I would suggest keeping them in a separate
> document.

This is the same approach we're picking on the freedesktop.org/x.org
foundation side (the freedesktop.org CoC applied to a lot more than
just drm). We're still working on some of the process and
implementation details (e.g. the exact appeals procudures isn't
defined yet). But that's all going to be written out in a separate
policy, not in the code of conduct itself.

I think that's also a good place to put clarifications (along the line
of what David Woodhouse just suggested in another reply), like that we
don't consider email addresses that showed up on public mailing lists
as private data. Which is also what the freedesktop.org privacy policy
spells out: If you send mails to mailing lists, everything in there is
public (and due to the nature of distributed archives, can't be taken
down again, since freedesktop.org doesn't even control them). If you
don't like that, don't send mails to mailing lists.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch