Re: [Ksummit-discuss] Call to Action Re: [PATCH 0/7] Code of Conduct: Fix some wording, and add an interpretation document
Date: Sun Oct 28 2018 - 17:48:48 EST
On Sat, Oct 27 2018, Josh Triplett wrote:
> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> On Wed, Oct 24 2018, Josh Triplett wrote:
>> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >> On Sun, Oct 21 2018, Josh Triplett wrote:
>> >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> >> >> I call on you, Greg:
>> >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> >> >> - to revert 8a104f8b5867c68
>> >> >> - to return to your core competence of building a great team around
>> >> >> a great kernel
>> >> >>
>> >> >> #Isupportreversion
>> >> >>
>> >> >> I call on the community to consider what *does* need to be said, about
>> >> >> conduct, to people outside the community and who have recently joined.
>> >> >> What is the document that you would have liked to have read as you were
>> >> >> starting out? It is all too long ago for me to remember clearly, and so
>> >> >> much has changed.
>> >> >
>> >> > The document I would have liked to have read when starting out is
>> >> > currently checked into the source tree in
>> >> > Documentation/process/code-of-conduct.rst .
>> >> I'm curious - what would you have gained by reading that document?
>> > I would have then had rather less of a pervasive feeling of "if I make
>> > even a single mistake I get made an example of in ways that will feed
>> > people's quotes files for years to come".
>> Thanks for your reply. Certainly feeling safe is important, and having
>> clear statements that the community values and promotes psychological
>> safety is valuable.
>> The old "code of conflict" said
>> If however, anyone feels personally abused, threatened, or otherwise
>> uncomfortable due to this process, that is not acceptable.
>> would you have not found this a strong enough statement to ward off that
>> pervasive feeling?
> Not when that document started out effectively saying, in an elaborate
> way, "code > people". (Leaving aside that the more important detail
> would be the community actually acting consistently with the code of
> conduct it espoused.)
I certainly cannot argue with that. .... that those starting words have
been preserved in the code-of-conduct-interpretation.rst, so we still
>> In the current code, would The "Our Pledge" section have been
>> sufficient, or do you think the other sections would have actually
>> helped you?
> "Our Standards" would have been at least as important to me personally,
> as would "Enforcement" (and more importantly, examples of that applying
> in practice and not just as empty words).
I find it interesting that you appear to particularly value the
Enforcement section, I particularly dislike it.
It is also interesting that you seem to fear that it might be "empty
words", and elsewhere in this thread Laura Abbott wondered
Will those problems actually be handled appropriately when the time
comes? I can't actually say for sure
She goes on to opine that trust is needed, but if we really had trust,
we might not need the code.
None of us, to my knowledge, has credible expertise or demonstrated
experience in this area, so we might easily become the blind misleading
the blind. However I would like to make one more attempt to give
context and meaning to my dislike for that section.
The approach described seem to be combative rather than conciliatory.
The first action-step described is to mark a report - to complain. This
isn't quite as bad as being litigious, but it seems headed in that
direction. I would rather we gave people the power to resolve their own
issues, rather than an avenue to magnify them but involving others.
Think for a moment about how we resolve technical differences. I
acknowledge that we don't always resolve them very well, but when we do
- what techniques seem to work? We don't have any court to which we can
apply to resolve our differences, we need to present our case and garner
support from like-minded people. To help with that, we do have some
standards like "no regressions" and "maintainable" and various
coding-style guidelines. They don't necessarily answer everything but
they help. Over all this, there is a general principle that the person
who writes the code makes the decisions - "code talks". The person who
puts in the effort gets heard more than the person who complains from
the side lines. This isn't all perfect, but it largely works, and we
are familiar with it.
Can we translate any of that experience to the social/harm side of
1/ We can have some standards. We will never all agree on the level
of detail needed (but then, we don't all agree on checkpatch.pl
either), but anything generally in the right direction would help (I
like "Be helpful. Don't be harmful". "Be kind to each other" is in
2/ We can voice our support when we see a cause the we agree with,
whether it is a revised API, or discomfort with a particular
3/ We can make sure that people who have done valuable work (written a
patch, found a bug, etc) have a place where they can be heard, even if
they find the need to filter all messages from an unrepentant abuser.
I think our practice, in the technical sphere, has generally been
towards conciliation, not combat. I think that is the experience that
we should try to leverage in the more social sphere.
A useful side-node is that "hurting people hurt people". If someone
does hurt you, there is a good chance that they are hurting themselves.
Do you want to increase that hurt by fighting back? Would it not be
better to simply side-step.
Description: PGP signature