Promoting the GNU Kind Communication Guidelines?

Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello,

Following the announcement made by RMS regarding the new GNU Kind
Communication Guidelines (GKCG) [1], I would like to know if the Guix
developpers in particular its maintainers would agree to adopt it in
place of the current Code of Conduct (CoC)?

Adopting the GKCG instead of a CoC would help attracting people (like
me) who agree to use a welcoming and respectful language which
encourages everyone to contribute but are reluctant in contributing to
any project following a CoC due to its punitive nature and the politics
of its authors [2][3].

Thanks.

[1] http://lists.gnu.org/archive/html/info-gnu/2018-10/msg00001.html
[2] https://www.contributor-covenant.org/
[3] https://geekfeminism.wikia.com/wiki/Meritocracy

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Promoting the GNU Kind Communication Guidelines?

[Tobias Geerinckx-Rice]

Hullo Mathieu!

Mathieu Lirzin wrote:
> Following the announcement made by RMS regarding the new GNU 
> Kind
> Communication Guidelines (GKCG) [1], I would like to know if the 
> Guix
> developpers in particular its maintainers would agree to adopt 
> it in
> place of the current Code of Conduct (CoC)?

They seem reasonable (a tad reactionary, but hey, it's rms) but 
orthogonal to our CoC.

> Adopting the GKCG instead of a CoC would help attracting people 
> (like
> me) who agree to use a welcoming and respectful language which
> encourages everyone to contribute but are reluctant in 
> contributing to
> any project following a CoC due to its punitive nature and the 
> politics
> of its authors [2][3].

I've (re-)read the links you've provided (thanks). I guess it's 
supposed to be obvious what you find disagreeable about them, but 
if one doesn't disagree, it's not that obvious. :-)

(TBH that's the only reason I replied at all: I'd like to learn 
more about the different perspectives on this issue. The 'debate' 
dividing other projects is entirely unenlightening and tedious. I 
hope we can do better.)

That said, I hope we can address any perceived lack of merit in 
(our copy of) the CoC without resorting to its original 
authors. The resulting irony blast would level multiple city 
blocks.

Kind regards,

T G-R

> [1] 
> http://lists.gnu.org/archive/html/info-gnu/2018-10/msg00001.html
> [2] https://www.contributor-covenant.org/
> [3] https://geekfeminism.wikia.com/wiki/Meritocracy

Re: Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello Tobias,

Tobias Geerinckx-Rice <me@tobias.gr> writes:

> I've (re-)read the links you've provided (thanks). I guess it's
> supposed to be obvious what you find disagreeable about them, but if
> one doesn't disagree, it's not that obvious. :-)

IMO Discussing what I find disagreeable with the particular form of
Feminism advocated by the links I have provided is off topic.

Without direspecting those who agrees with those ideas, I think it is
reasonably obvious that not everybody supporting Free Software, supports
those unrelated political ideas.

> That said, I hope we can address any perceived lack of merit in (our
> copy of) the CoC without resorting to its original authors. The
> resulting irony blast would level multiple city blocks.

I don't understand the last sentence.  Can you explain it with
simpler words?

>> [1] http://lists.gnu.org/archive/html/info-gnu/2018-10/msg00001.html
>> [2] https://www.contributor-covenant.org/
>> [3] https://geekfeminism.wikia.com/wiki/Meritocracy

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

On Tue, Oct 23, 2018 at 01:15:23PM +0200, Mathieu Lirzin wrote:
> Adopting the GKCG instead of a CoC would help attracting people (like
> me) who agree to use a welcoming and respectful language which
> encourages everyone to contribute but are reluctant in contributing to
> any project following a CoC due to its punitive nature and the politics
> of its authors [2][3].

FWIW once I noticed that Guix had adopted the Contributor Covenant, it 
factored strongly into my decision to stop contributing to the project 
last year.

I can't say for sure that I would contribute again if the CoC were gone, 
but I would very much welcome this change.  

-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Jack Hill]

Alex,

On Tue, 23 Oct 2018, Alex Griffin wrote:

> FWIW once I noticed that Guix had adopted the Contributor Covenant, it
> factored strongly into my decision to stop contributing to the project
> last year.

Interesting. I too am eager understand your thinking on this.

When thinking about this issue today, I remembered some of Sage Sharp's 
writings [0][1]. What struck me about those writings is that it is not 
just about the language in our policies, but about how we use the policies 
when conducting ourselves as a community. In particular, it is about more 
than just how we communicate. It is about who is included and empowered in 
the community, and how we handle problems that arise. Getting all of this 
right is hard work, and I am happy to take all the advice I can get from 
people who have done more thinking and had more real world experience in 
this area, whether that be the Contributor Covenant, the GNU Kind 
Communication Guidelines, or other writings about community building (even 
those not specific to software).

When embarking on the hard work or community building (like the hard work 
of promoting software freedom), I find it helpful to see where we are 
heading. In Guix the Free Software Distribution Guidelines did this for 
the software freedom issues, and, while perhaps imperfect, the CoC did 
this for the community building issues. Regardless of how we sort out the 
details of implementation, I hope that we set, document, and communicate a 
high goal for our community building work.

Best,
Jack

P.S. Apologies if guix-devel is not the right place to be having this 
conversation. I like Guix a lot and am interested in it being a just 
community.

[0] http://sage.thesharps.us/2016/01/25/code-of-conducts-warning-signs/
[1] http://sage.thesharps.us/2015/10/06/what-makes-a-good-community/

Re: Promoting the GNU Kind Communication Guidelines?

[Ludovic Courtès]

Hello,

Jack Hill <jackhill@jackhill.us> skribis:

> On Tue, 23 Oct 2018, Alex Griffin wrote:
>
>> FWIW once I noticed that Guix had adopted the Contributor Covenant, it
>> factored strongly into my decision to stop contributing to the project
>> last year.
>
> Interesting. I too am eager understand your thinking on this.

Same here.  For the record, the code of conduct was adopted in Guix
in Dec. 2015.

Ludo’.

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

Jack Hill <jackhill@jackhill.us> skribis:
>
> Interesting. I too am eager understand your thinking on this.

I am skeptical of codes of conduct in FLOSS projects because they often 
come bundled with a certain (non-software-related) political orthodoxy.

The Contributor Covenant is the worst offender in this regard, having 
been created specifically for that purpose [1]. Although most of the 
offending text has now been removed from the document itself, the same 
spirit still follows behind it to projects that adopt the CC.

(It is also baffling to me that programmers would want to recreate an 
imitation HR department in their time off from the corporate world, but 
I'll put that aside.)

On Wed, Oct 24, 2018 at 12:02:37PM +0200, Ludovic Courtès wrote:
>
> Same here.  For the record, the code of conduct was adopted in Guix
> in Dec. 2015.

I hadn't noticed when I first started contributing. A bad code of 
conduct can still work out fine with good project leadership in place, 
which is why the Contributor Covenant was only one of several factors 
influencing my decision to move away from Guix.

I hope it is evident that I don't oppose the CoC out of a desire to 
behave badly. Please forgive some vagueness as well; I tried very hard 
not to provoke unnecessary controversy. As a result much of this email 
was edited out before sending.

-- 
Alex Griffin

[1]: https://twitter.com/coralineada/status/1041465346656530432

Re: Promoting the GNU Kind Communication Guidelines?

[Tonton]

On Wed, 24 Oct 2018 09:21:16 -0500
Alex Griffin <a@ajgrf.com> wrote:

> Jack Hill <jackhill@jackhill.us> skribis:
> >
> > Interesting. I too am eager understand your thinking on this.  
> 
> I am skeptical of codes of conduct in FLOSS projects because they often 
> come bundled with a certain (non-software-related) political orthodoxy.
> 
> The Contributor Covenant is the worst offender in this regard, having 
> been created specifically for that purpose [1]. Although most of the 
> offending text has now been removed from the document itself, the same 
> spirit still follows behind it to projects that adopt the CC.

CoC's are most definitely political, just like the GKCG. Orthodoxy in this
context I think is mostly meaningless - as most sides of this debate are as
orthodox as the others. There's also this:

> "I don’t agree with Coraline Ada Ehmke’s politics. Should I avoid this code
> of conduct?
> 
> If you’re a meritocracy fan, you already abide by the principle of
> separating the person from the contribution. And even if you’re not,
> adopting the Contributor Covenant does not imply any political or social
> orientation aside from the (unfortunately politicized) goal of making your
> project welcoming and inclusive to people of all backgrounds."
- https://www.contributor-covenant.org/faq

While I do agree that CoC's should be redundant and unneeded, our current
culture in FLOSS is sadly not there yet. Harrasment is - at least as far as I
have observed - way to common. An interesting element here is that many of the
harrassers don't seem to understand that they are harrassing.

This is the reason why, as has been discussed before on this list, I (I think
we/Guix) try to tell people kindly. It is after all normal to make mistakes,
it is also the way we learn. Usually nudging people to use inclusive language
and reminding ourselves when we slip is enough - and it encourages a much
nicer, and I'd argue productive, community. I see this in my day to day
situation also.


I have to admit I'm surprised at how good the GKCGs are. But, as has already
bin pointed out, it is lacking some important elements like process and
acceptable and unacceptable.


As some have come up and stated they quit Guix because of the CoC; I'm at the
opposite end of the spectrum. I run Guix with or without the community, but I
choose to participate in Guix because it has a good CoC that is held with
kindness by many in the community.

I look forward to winter, when I have more time for programming... :)

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

> An interesting element here is that many of the
> harrassers don't seem to understand that they are harrassing.

I'm so glad you brought this up, because it seems equally plausible to me that the other party could be reacting  overly sensitively.

This is precisely why it is a bad idea to set up an authority for people to appeal to. In many cases it's not clear which party is the unreasonable one, and it must be worked through with dialogue.

If people don't have to work things out among themselves, and disputes are instead handled by a committee of project maintainers, contributors lose the opportunity to better understand each other. Oh, and that committee of maintainers have all agreed according to the Contributor Covenant that they have a responsibility to punish abusers, so they might find it difficult to avoid being biased towards punishing the accused.

Software projects should focus on software. They are not equipped to administer justice.

-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Tonton]

On Fri, 26 Oct 2018 17:37:32 -0500
Alex Griffin <a@ajgrf.com> wrote:

> > An interesting element here is that many of the
> > harrassers don't seem to understand that they are harrassing.  
> 
> I'm so glad you brought this up, because it seems equally plausible to me
> that the other party could be reacting  overly sensitively.
> 
> This is precisely why it is a bad idea to set up an authority for people to
> appeal to. In many cases it's not clear which party is the unreasonable
> one, and it must be worked through with dialogue.
> 
> If people don't have to work things out among themselves, and disputes are
> instead handled by a committee of project maintainers, contributors lose
> the opportunity to better understand each other. Oh, and that committee of
> maintainers have all agreed according to the Contributor Covenant that they
> have a responsibility to punish abusers, so they might find it difficult to
> avoid being biased towards punishing the accused.

It seems to me you are making punishment way bigger than it actually is.
Great big lumps of shit has to hit someones fan before punishment is talked
about. The harshest I've seen here has been once when a core maintainer asked
a community member to take a break and rethink; in this case the person
being asked to take a break was claiming to be a victim (the whole thing
seemed to me a lot of grey scale and misunderstandings). Most of what I see
and participate in are friendly, inclusive dialogues - including the ones
where we work through grievances and misunderstandings.

Now, for issues that are of a difficult character it makes sense to not have
an open dialogue with all parties involved. There are many reasons for this
and I encourage everyone interested to read up on trauma, anxiety, depression
and other similar psycho-social issues, especially from the point of view of
those affected. The process should not be a one sided - the decision makers
should talk, and in these cases all parties should be reached out to for an
explanation. But I don't know if this is the current Guix process.

> 
> Software projects should focus on software. They are not equipped to
> administer justice.
> 

I think software projects should focus on building software, and to do that
you need someone to build it. Programming is an incredibly social activity -
even for me, here I sit alone and mostly work on stuff that only I will ever
see or use. So we focus on building an inclusive awesome community, because
that is one of the best ways to get awesome software. To build a community we
need to build a culture. To build a culture you need to have some way of
creating glue - cohesiveness. Either you auto-disassociate anyone not "tough
enough" or you use something like a CoC and someone enforcing it (or you find
other ways of reaching these goals; but AFAIK the two above are the main ones
used in FLOSS today).

Remember the CoC is only true for some communities/cultures, it does not
influence your legal entity outside of your interactions with the community
(unless the issues are severe enough to have broken an actual law where one
of the parties are).

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

On Sun, Oct 28, 2018, at 1:42 PM, Tonton wrote:
> It seems to me you are making punishment way bigger than it actually is.

The CoC actually says that maintainers have a responsibility to remove 
offenders or risk being removed themselves. In contrast the Debian Code 
of Conduct says:

> While this code of conduct should be adhered to by participants, we 
> recognize that sometimes people may have a bad day, or be unaware of 
> some of the guidelines in this code of conduct. When that happens, you 
> may reply to them and point out this code of conduct. Such messages 
> may be in public or in private, whatever is most appropriate. However, 
> regardless of whether the message is public or not, it should still 
> adhere to the relevant parts of this code of conduct; in particular, 
> it should not be abusive or disrespectful. Assume good faith; it is 
> more likely that participants are unaware of their bad behaviour than 
> that they intentionally try to degrade the quality of the discussion.

The difference is like night and day.

> Remember the CoC is only true for some communities/cultures, it does not
> influence your legal entity outside of your interactions with the community

To enter into a covenant, or agree to be bound by a code, means to stake 
your word on it. The words themselves actually carry weight, and not 
just as rules to follow, which is why the tiniest details of these 
documents receive so much scrutiny.

From sentence 1 of the Contributor Covenant:
> In the interest of fostering an open and welcoming environment, we as 
> contributors and maintainers pledge to [...]

This snippet right here is a problem even before we get to the meat and 
potatoes. I don't appreciate the presumption that my mere participation 
indicates my agreement with this document. It rubs me the wrong way even 
when I'm only reporting a bug (which does fall under its scope, because 
'issues', as found in an issue tracker, are explicitly mentioned further 
down).

-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

In a sense, the Debian Code of Conduct is a code in name only. It's really just 6 guidelines for kind communication and resolving conflicts peacefully, and finally a method for seeking recourse either as a last resort or in serious cases. The Contributor Covenant is actually a real covenant.
-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Thorsten Wilms]

On 28/10/2018 20.50, Alex Griffin wrote:
>  From sentence 1 of the Contributor Covenant:
>> In the interest of fostering an open and welcoming environment, we as
>> contributors and maintainers pledge to [...]
> This snippet right here is a problem even before we get to the meat and
> potatoes. I don't appreciate the presumption that my mere participation
> indicates my agreement with this document.

Especially as it's easily possible to contribute a patch without being 
aware of the CC.

It says it's a pledge. How does it mean anything just sitting there? 
Must there not be an act of making/joining the pledge?

Seems to me either that language must go, or in future, contributions 
(at least those ending up in the tree) can only be accepted from people 
who explicitly made/joined/signed the pledge (AKA read and sign this 
EULA before contributing even the tiniest bug-fix).


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

On Sun, Oct 28, 2018, at 1:42 PM, Tonton wrote:
> It seems to me you are making punishment way bigger than it actually is.

Think about it this way. The Contributor Covenant goes on about the many different ways that a disagreement might escalate, while the Debian CoC spends almost all of its time modeling how to de-escalate a disagreement.

-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Björn Höfling]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

On Sun, 28 Oct 2018 14:50:54 -0500
Alex Griffin <a@ajgrf.com> wrote:

> On Sun, Oct 28, 2018, at 1:42 PM, Tonton wrote:

> >From sentence 1 of the Contributor Covenant:
> > In the interest of fostering an open and welcoming environment, we
> > as contributors and maintainers pledge to [...]  
> 
> This snippet right here is a problem even before we get to the meat
> and potatoes. I don't appreciate the presumption that my mere
> participation indicates my agreement with this document. It rubs me
> the wrong way even when I'm only reporting a bug (which does fall
> under its scope, because 'issues', as found in an issue tracker, are
> explicitly mentioned further down).
> 

You can harass in just one bug report: "Module foo does not work for
me. [Normal bug report things here] This beast is written in
such a bad way, the bug is more its contributor Bar, he/she/zhe is so
[inappropriate phrase here], get rid of him/her/zhe immediately and the
problem is resolved."

Nobody asked about reporting, nobody asked to sign a CoC or anything,
yet this is harassment and the project (maintainer) should take
immediate steps to protect Bar.

The same harassment can pretty well be packed in a patch.

In law, there is the term of "conduct implying an intent". So even not
signing anything you could argue that by sending a bug or a patch you
silently agree with the community guidelines, CoC, etc. You enter the
community be interacting the first time. And will be judged by their
guidelines. 

Björn



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: Promoting the GNU Kind Communication Guidelines?

[Thorsten Wilms]

On 29/10/2018 09.59, Björn Höfling wrote:
> In law, there is the term of "conduct implying an intent". So even not
> signing anything you could argue that by sending a bug or a patch you
> silently agree with the community guidelines, CoC, etc. You enter the
> community be interacting the first time. And will be judged by their
> guidelines.

It used to be that you could pick a Free Software project and send a patch.

Now sending a patch is supposed to imply agreeing to the equivalent of 
an EULA? Everyone is expected to welcome that as progress?

Again "... we as contributors and maintainers pledge ..." is bullshit. I 
pledged nothing. More pragmatic and truthful would be:

"The project owners expect everyone who contributes to the project by 
any means, or who communicates via any of the means that belong to the 
project, to stick to the rules below. Breaking the rules may lead to any 
of: a warning, rejection of contributions, a ban where and as far as 
possible."

-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

On Mon, Oct 29, 2018 at 11:49:23AM +0100, Thorsten Wilms wrote:
> bullshit. I pledged nothing. More pragmatic and truthful would be:
> 
> "The project owners expect everyone who contributes to [...]

Exactly. I would actually have less of a problem with it if it were 
presented as moderation rules come down from on high. They still might 
be bad rules that I disagreed with (or not), but at least there would 
only be a problem if I broke a rule.

When the CoC actually purports to speak for me, then there's a problem 
even if no one ever invokes the CoC. I view the Contributor Covenant in 
particular as pushing identity politics on the free software world and 
manufacturing consent for that agenda. That's why the website proudly 
lists all the projects that agreed to it, and why they go push newer 
projects to adopt it.

I mean don't you think it's odd that the net effect of CoCs is to cause 
drama and divide communities, when they're supposed to be about 
welcoming everybody? Even if you can't understand why it shakes out like 
that, that alone should throw up red flags in your mind.

-- 
Alex Griffin

Re: Promoting the GNU Kind Communication Guidelines?

[Christopher Lemmer Webber]

Thorsten Wilms writes:

> On 29/10/2018 09.59, Björn Höfling wrote:
>> In law, there is the term of "conduct implying an intent". So even not
>> signing anything you could argue that by sending a bug or a patch you
>> silently agree with the community guidelines, CoC, etc. You enter the
>> community be interacting the first time. And will be judged by their
>> guidelines.
>
> It used to be that you could pick a Free Software project and send a patch.
>
> Now sending a patch is supposed to imply agreeing to the equivalent of
> an EULA? Everyone is expected to welcome that as progress?

Submitting code to a project under a copyleft license is also agreeing
to policy.

Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Mark H Weaver]

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Thorsten Wilms writes:
>
>> On 29/10/2018 09.59, Björn Höfling wrote:
>>> In law, there is the term of "conduct implying an intent". So even not
>>> signing anything you could argue that by sending a bug or a patch you
>>> silently agree with the community guidelines, CoC, etc. You enter the
>>> community be interacting the first time. And will be judged by their
>>> guidelines.
>>
>> It used to be that you could pick a Free Software project and send a patch.
>>
>> Now sending a patch is supposed to imply agreeing to the equivalent of
>> an EULA? Everyone is expected to welcome that as progress?
>
> Submitting code to a project under a copyleft license is also agreeing
> to policy.

What is the basis for this claim?

While I'm generally in favor of the CoC, I strongly oppose the idea that
submitting a patch or communicating with us implies automatic agreement
to our policies.

We should not claim that someone has "agreed" to anything without their
conscious knowledge and consent.  Even if the law would allow us to make
such a claim, we should not do it because it would be unjust.

Please, it is enough to make our policies clear and highly visible, to
encourage people to read them, and to give the lead project maintainers
the authority to issue warnings, and if deemed necessary, to ban people
from our communication channels who repeatedly or severely violate our
CoC.  I support that practice, as long as it's used judiciously, and I
have every confidence in Ludovic and Ricardo to do so.

We do _not_ need to extract promises from contributors ahead of time
that they will follow our policies, and I think it's a bad idea to ask
them to.  It's a worse idea to claim that they've done so implicitly
without their knowledge or consent.

      Mark

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Christopher Lemmer Webber]

Mark H Weaver writes:

> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> Thorsten Wilms writes:
>>
>>> On 29/10/2018 09.59, Björn Höfling wrote:
>>>> In law, there is the term of "conduct implying an intent". So even not
>>>> signing anything you could argue that by sending a bug or a patch you
>>>> silently agree with the community guidelines, CoC, etc. You enter the
>>>> community be interacting the first time. And will be judged by their
>>>> guidelines.
>>>
>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?
>>
>> Submitting code to a project under a copyleft license is also agreeing
>> to policy.
>
> What is the basis for this claim?
>
> While I'm generally in favor of the CoC, I strongly oppose the idea that
> submitting a patch or communicating with us implies automatic agreement
> to our policies.
>
> We should not claim that someone has "agreed" to anything without their
> conscious knowledge and consent.  Even if the law would allow us to make
> such a claim, we should not do it because it would be unjust.
>
> Please, it is enough to make our policies clear and highly visible, to
> encourage people to read them, and to give the lead project maintainers
> the authority to issue warnings, and if deemed necessary, to ban people
> from our communication channels who repeatedly or severely violate our
> CoC.  I support that practice, as long as it's used judiciously, and I
> have every confidence in Ludovic and Ricardo to do so.
>
> We do _not_ need to extract promises from contributors ahead of time
> that they will follow our policies, and I think it's a bad idea to ask
> them to.  It's a worse idea to claim that they've done so implicitly
> without their knowledge or consent.
>
>       Mark

I suspect we do not disagree Mark, but the way in which you replied to
me makes it sound like we do, so let me clarify. :)  My short reply was
because I was trying to demonstrate, in few words, that the message I
was replying to was introducing an inaccuracy.  I did not clarify what
that was, but I will below.

We accept many patches from users where the user does not sign an actual
document, but their patch and their name applied on the top is
considered sufficient evidence that they have declared their code to be
licensed under the GPL.

But I should clarify the claim I was making, since I was not trying to
say that the legal or mechanistic aspects of this were equivalent.  Let
me quote what was I was replying to:

>>> It used to be that you could pick a Free Software project and send a patch.
>>>
>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>> an EULA? Everyone is expected to welcome that as progress?

The statement above makes it sound like the Code of Conduct is
dramatically new.  My claim here was that in both cases, there is a
policy the community has adopted.  One is legal and copyleft, the other
is behavioral and a code of conduct.  In both cases, your participation
in this community is dependent on your willingness to agree to respect
the policies and norms that the group upholds.

What's interesting to me is that this isn't new at all, it's just
codified for some specific things.  The Code of Conduct is not a legal
document, it is a set of policies about community norms.  Many of these
norms already existed, and the same process (speak to the person, ask
them to change their behavior, if we can't fix it, yes they may be
banned) has existed for a long time in free software circles.  What is
new from the code of conduct perspective is making explicit what some of
those norms are, and what participants can expect if they are not
upheld.

I have seen some accusations that this is censorship or an overreach or
equivalent to an EULA to have these norms enforced.  And yet the free
software community, and especially GNU projects, have long been
enforcing of policies.  Copyleft is a mechanism for enforcement of
policies by law, but even beyond that, I think most of the members of
this group would find it perfectly acceptable to ban someone who began
to post patches to the list under a license that was incompatible with
the GPL and which "poisoned" our ability to use them upon seeing them.
The former is a legal agreement, the latter is a norms agreement, but
they are both policy, and by participating in our group in general you
have an understanding that these policies exist.  The code of conduct
does not provide a legal enforcement mechanism, so the EULA comment in
that sense does not hold up; this is just a codification of some of the
norms that we have.  But someone made the EULA comment, and the extent
that it *did* make sense (that there are policies, in some way), I
wanted to reply to it.

The free software community has always had policies, has always asked
people to respect language, has always had the expectation that if you
participate in our community, you are expected to abide by certain
norms.  Having those norms even be explicit is not new; there are norms
posted all over the GNU website, and participants are frequently asked
to abide by them.  Internet forums of all kinds have expressed rules and
policies.  That is not new.

Let's be clear about what the difference is then about adding a code of
conduct: we are extending and making explicit the norm-policies of
requirement to participate in our community to extend to various forms
of respect for others.  For a long time, many such norms were even
implicit rather than explicit.  We are choosing to make explicit some
norms that encourage good behavior and respectful treatment amongst
participants in the group.  We are also explicitly requiring respecting
the well being of participants who have long had difficulty
participating due to reasons that are largely culturally systemic.

It is this last sentence that most people objecting to a code of conduct
seem suspicious of, but I feel like much of the conversation around code
of conducts beats around the bush that many of the skeptics simply don't
believe that last sentence is true.  Well, it turns out the code of
conduct is a useful document whether you believe that last sentence is
true, but I believe it sticks in the craw of people who believe that our
society does not have unequal distributions of justice, and that is the
source of almost all objections.

Every community provides some sort of governance.  Having policies,
whether legal (copyleft) or norms (all the other things we expect), is
not new, and I hope I have demonstrated that.  So a code of conduct is
not any more like adding an EULA for all participants than other policy
traditions are.

All the best,
 - Chris

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Thorsten Wilms]

Thanks to Mark H Weaver for writing ... how to say .. the mirror 
perspective of what I wish I would have written as sole input so far :)


On 30/10/2018 14.28, Christopher Lemmer Webber wrote:

>>>> It used to be that you could pick a Free Software project and send a patch.
>>>>
>>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>>> an EULA? Everyone is expected to welcome that as progress?
> 
> The statement above makes it sound like the Code of Conduct is
> dramatically new.

It is based on the fact that there are many projects that existed for 
some time before adopting a CoC. The EULA comparison is only about CoCs 
with "covenant" and "we contributors pledge" type of language.

While benefiting from and accepting a copyleft license is pretty much a 
precondition for a patch, that is not the case for a CoC that tries to 
bind one on contribution.


> My claim here was that in both cases, there is a
> policy the community has adopted.  One is legal and copyleft, the other
> is behavioral and a code of conduct.  In both cases, your participation
> in this community is dependent on your willingness to agree to respect
> the policies and norms that the group upholds.

Submitting a patch might involve only the most minimal interaction with 
one maintainer. Staying within a very narrow subset of rules that a 
group might uphold should suffice to cause no harm to anyone while 
allowing people to benefit from the work.

The group is not clearly delineated. The actual norms are only shown in 
how the maintainers and regulars act.


> The code of conduct
> does not provide a legal enforcement mechanism, so the EULA comment in
> that sense does not hold up; this is just a codification of some of the
> norms that we have.  But someone made the EULA comment, and the extent
> that it *did* make sense (that there are policies, in some way), I
> wanted to reply to it.

What I had in mind is: Unpacking an old-school software that has a 
shrink-wrap EULA is meant to imply acceptance of the license.

Likewise, contributing to Guix is apparently meant to imply that one 
makes the pledge as outlined in that CoC.

In both cases, you are meant to not get one without the other. It 
happened that one could not read the EULA in advance and it happened 
that I contributed before reading the CoC carefully. I distrust it's 
origin and I'm not happy about a few details, though they most likely 
will never matter. So I could almost, but not quite make such a promise, 
but I cannot be made to make such a promise. Especially retroactively. 
Even less can I be made to make a promise that might change:

I assume that Ricardo and Ludovic want to have the option of editing the 
CoC without asking every single contributor. Well, people should better 
know what the current state of their pledge is.

Not that I think the two would introduce a nasty surprise, it's just 
that the "covenant" and "we as contributors ... pledge" language is 
dishonest.

Reject a contribution, talk to me, warn me, set an ultimatum, ban me if 
I did wrong by your norms as you see fit, that's all fine and expected 
with or without CoC anyway, but please don't try to make me say: those 
norms are mine (independent on whether they could be).

If I sound like a drama royal person ... so be it! ;)


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Alex Sassmannshausen]

Hi Thorsten,

Thorsten Wilms writes:
> [...]
>
> Likewise, contributing to Guix is apparently meant to imply that one
> makes the pledge as outlined in that CoC.
>
> In both cases, you are meant to not get one without the other. It
> happened that one could not read the EULA in advance and it happened
> that I contributed before reading the CoC carefully. I distrust it's
> origin and I'm not happy about a few details, though they most likely
> will never matter. So I could almost, but not quite make such a
> promise, but I cannot be made to make such a promise. Especially
> retroactively. Even less can I be made to make a promise that might
> change:
>
> I assume that Ricardo and Ludovic want to have the option of editing
> the CoC without asking every single contributor. Well, people should
> better know what the current state of their pledge is.
>
> Not that I think the two would introduce a nasty surprise, it's just
> that the "covenant" and "we as contributors ... pledge" language is
> dishonest.

Out of curiosity, would you personally feel better about the CoC if it
used terms such as "This community commits to" or "This community
pledges to" insteead of "We as contributors commit to"?

I ask because one of the positives about the CC wording from my
perspective is that it specifically makes it a collective responsibility
to uphold certain norms, and not just the responsibility of the
"projec authorities".  It is understood that there are specific channels
for dealing with violations of those norms, but the community as a whole
stands behind that.

Alex

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Thorsten Wilms]

On 31/10/2018 09.58, Alex Sassmannshausen wrote:
> Out of curiosity, would you personally feel better about the CoC if it
> used terms such as "This community commits to" or "This community
> pledges to" insteead of "We as contributors commit to"?

In as far as contributing doesn't make one part of the community ... it 
would be a slight improvement. On the other hand, it's just vaguer about 
whom it puts words into their mouths.


> I ask because one of the positives about the CC wording from my
> perspective is that it specifically makes it a collective responsibility
> to uphold certain norms, and not just the responsibility of the
> "projec authorities".  It is understood that there are specific channels
> for dealing with violations of those norms, but the community as a whole
> stands behind that.

Yeah, that's the positive reading. A negative is that it is an attempt 
to push people to declare a mixed bag as their own, with no voice in the 
process (other than take it or leave it). One that contains 
hard-to-argue-with aspects, but also questionable and vague parts.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Alex Sassmannshausen]

Thanks for your answers.  I'm glad to hear that there might be room for
some form of dialogue on wording.

Cheers!

Alex

Thorsten Wilms writes:

> On 31/10/2018 09.58, Alex Sassmannshausen wrote:
>> Out of curiosity, would you personally feel better about the CoC if it
>> used terms such as "This community commits to" or "This community
>> pledges to" insteead of "We as contributors commit to"?
>
> In as far as contributing doesn't make one part of the community
> ... it would be a slight improvement. On the other hand, it's just
> vaguer about whom it puts words into their mouths.
>
>
>> I ask because one of the positives about the CC wording from my
>> perspective is that it specifically makes it a collective responsibility
>> to uphold certain norms, and not just the responsibility of the
>> "projec authorities".  It is understood that there are specific channels
>> for dealing with violations of those norms, but the community as a whole
>> stands behind that.
>
> Yeah, that's the positive reading. A negative is that it is an attempt
> to push people to declare a mixed bag as their own, with no voice in
> the process (other than take it or leave it). One that contains
> hard-to-argue-with aspects, but also questionable and vague parts.

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Mark H Weaver]

Hi Chris,

Christopher Lemmer Webber <cwebber@dustycloud.org> writes:

> Mark H Weaver writes:
>
>> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>>
>>> Thorsten Wilms writes:
>>>
>>>> On 29/10/2018 09.59, Björn Höfling wrote:
>>>>> In law, there is the term of "conduct implying an intent". So even not
>>>>> signing anything you could argue that by sending a bug or a patch you
>>>>> silently agree with the community guidelines, CoC, etc. You enter the
>>>>> community be interacting the first time. And will be judged by their
>>>>> guidelines.
>>>>
>>>> It used to be that you could pick a Free Software project and send a patch.
>>>>
>>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>>> an EULA? Everyone is expected to welcome that as progress?
>>>
>>> Submitting code to a project under a copyleft license is also agreeing
>>> to policy.
>>
>> What is the basis for this claim?
>>
>> While I'm generally in favor of the CoC, I strongly oppose the idea that
>> submitting a patch or communicating with us implies automatic agreement
>> to our policies.
>>
>> We should not claim that someone has "agreed" to anything without their
>> conscious knowledge and consent.  Even if the law would allow us to make
>> such a claim, we should not do it because it would be unjust.
>>
>> Please, it is enough to make our policies clear and highly visible, to
>> encourage people to read them, and to give the lead project maintainers
>> the authority to issue warnings, and if deemed necessary, to ban people
>> from our communication channels who repeatedly or severely violate our
>> CoC.  I support that practice, as long as it's used judiciously, and I
>> have every confidence in Ludovic and Ricardo to do so.
>>
>> We do _not_ need to extract promises from contributors ahead of time
>> that they will follow our policies, and I think it's a bad idea to ask
>> them to.  It's a worse idea to claim that they've done so implicitly
>> without their knowledge or consent.
>>
>>       Mark
>
> I suspect we do not disagree Mark, but the way in which you replied to
> me makes it sound like we do, so let me clarify. :)  My short reply was
> because I was trying to demonstrate, in few words, that the message I
> was replying to was introducing an inaccuracy.  I did not clarify what
> that was, but I will below.
>
> We accept many patches from users where the user does not sign an actual
> document, but their patch and their name applied on the top is
> considered sufficient evidence that they have declared their code to be
> licensed under the GPL.
>
> But I should clarify the claim I was making, since I was not trying to
> say that the legal or mechanistic aspects of this were equivalent.  Let
> me quote what was I was replying to:
>
>>>> It used to be that you could pick a Free Software project and send a patch.
>>>>
>>>> Now sending a patch is supposed to imply agreeing to the equivalent of
>>>> an EULA? Everyone is expected to welcome that as progress?
>
> The statement above makes it sound like the Code of Conduct is
> dramatically new.  My claim here was that in both cases, there is a
> policy the community has adopted.  One is legal and copyleft, the other
> is behavioral and a code of conduct.  In both cases, your participation
> in this community is dependent on your willingness to agree to respect
> the policies and norms that the group upholds.

These two cases are fundamentally different, in my view.

Contrary to what you wrote above, I assert that submitting code to a
project under licensed under the GNU GPL does _not_ require my agreement
to any policy.

All that can be reasonably expected of me, as a contributor to free
software projects, is that I'm being honest about the copyright status
of my contributions.  This is not an instance of agreeing to project
policy, but simply of not committing fraud.  It is obvious, and
therefore unsurprising and unobjectionable.

In contrast, I would be *very* surprised to learn that my contribution
to a project had been construed to imply agreement with that project's
policies, and I've been contributing to various free software projects
for about 25 years now.

I see no compelling need for Guix contributors to agree with our CoC.
It is enough for the project maintainers to agree, and for the lead
maintainers to possess the technical means to enforce the CoC through
their control over our communication channels.

> What's interesting to me is that this isn't new at all, it's just
> codified for some specific things.  The Code of Conduct is not a legal
> document, it is a set of policies about community norms.  Many of these
> norms already existed, and the same process (speak to the person, ask
> them to change their behavior, if we can't fix it, yes they may be
> banned) has existed for a long time in free software circles.  What is
> new from the code of conduct perspective is making explicit what some of
> those norms are, and what participants can expect if they are not
> upheld.
>
> I have seen some accusations that this is censorship or an overreach or
> equivalent to an EULA to have these norms enforced.  And yet the free
> software community, and especially GNU projects, have long been
> enforcing of policies.  Copyleft is a mechanism for enforcement of
> policies by law, but even beyond that, I think most of the members of
> this group would find it perfectly acceptable to ban someone who began
> to post patches to the list under a license that was incompatible with
> the GPL and which "poisoned" our ability to use them upon seeing them.

Agreed.

> The former is a legal agreement, the latter is a norms agreement, but
> they are both policy, and by participating in our group in general you
> have an understanding that these policies exist.

Again, I think these cases are fundamentally different.  I do _not_
think it's reasonable to expect that all Guix project participants will
be familiar with the policies outlined in our CoC.

Incidentally, I agree that it would be _desireable_ for project
participants to be familiar with our policies and to agree with them.
However, I don't think it should be required.

>                                                   The code of conduct
> does not provide a legal enforcement mechanism, so the EULA comment in
> that sense does not hold up; this is just a codification of some of the
> norms that we have.  But someone made the EULA comment, and the extent
> that it *did* make sense (that there are policies, in some way), I
> wanted to reply to it.

I agree that the lack of a legal enforcement mechanism in our CoC is a
very significant difference with EULAs.  Whereas EULAs are backed by the
full force of the law with all that entails, the most that will happen
if you violate our CoC is that we might deny you write access to our
project infrastructure.

That said, I also see at least two similarities between EULAs and your
suggestion that participation implies agreement with our policies: (1)
in both cases, there is the presumption that someone has agreed to terms
without making explicit statement to that effect, and (2) in both cases,
agreement to the terms is a prerequisite for participation.

> The free software community has always had policies, has always asked
> people to respect language, has always had the expectation that if you
> participate in our community, you are expected to abide by certain
> norms.  Having those norms even be explicit is not new; there are norms
> posted all over the GNU website, and participants are frequently asked
> to abide by them.  Internet forums of all kinds have expressed rules and
> policies.  That is not new.

I agree, it's not new.

However, if we were to start requiring people to agree with our policy
as a prequisite to their participation, or worse, to presume that they
have implicitly agreed, that _would_ be new.  Let's not do that please.

> Let's be clear about what the difference is then about adding a code of
> conduct: we are extending and making explicit the norm-policies of
> requirement to participate in our community to extend to various forms
> of respect for others.  For a long time, many such norms were even
> implicit rather than explicit.  We are choosing to make explicit some
> norms that encourage good behavior and respectful treatment amongst
> participants in the group.  We are also explicitly requiring respecting
> the well being of participants who have long had difficulty
> participating due to reasons that are largely culturally systemic.
>
> It is this last sentence that most people objecting to a code of conduct
> seem suspicious of, but I feel like much of the conversation around code
> of conducts beats around the bush that many of the skeptics simply don't
> believe that last sentence is true.  Well, it turns out the code of
> conduct is a useful document whether you believe that last sentence is
> true, but I believe it sticks in the craw of people who believe that our
> society does not have unequal distributions of justice, and that is the
> source of almost all objections.

I agree with all of this.

It seems to me that our only point of disagreement here is on the
question of whether to require/assume that all participants agree with
our policies.

      Regards,
        Mark

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Mark H Weaver]

Mark H Weaver <mhw@netris.org> writes:

> Christopher Lemmer Webber <cwebber@dustycloud.org> writes:
>
>> The free software community has always had policies, has always asked
>> people to respect language, has always had the expectation that if you
>> participate in our community, you are expected to abide by certain
>> norms.  Having those norms even be explicit is not new; there are norms
>> posted all over the GNU website, and participants are frequently asked
>> to abide by them.  Internet forums of all kinds have expressed rules and
>> policies.  That is not new.
>
> I agree, it's not new.
>
> However, if we were to start requiring people to agree with our policy
> as a prequisite to their participation, or worse, to presume that they
> have implicitly agreed, that _would_ be new.  Let's not do that please.

My response here was not sufficient.  Let me try again.

To my mind, there's an important but subtle distinction between:

(1) Posting policies and rules that apply to project participants, and
(2) Requiring that participants "agree" to the policies and rules.

In the first case, we are making the participants aware of the rules,
and of the possible consequences for breaking those rules.  Note that
this doesn't require participants to make any promises or to hold a
particular set of political beliefs.  I have no problem with this, and
moreover I fully support it.

In the second case, we are essentially demanding that participants make
promises about their future behavior, and declare themselves to share
the beliefs and goals encoded in the CoC.

The first case is analogous to the national and local laws that we all
must live under.

The second case is analogous to being asked by my government to sign an
endorsement and pledge of allegiance to those laws.

Do you see the difference?

      Mark

Re: Patch submission should not imply agreement to policy (was Re: Promoting the GNU Kind Communication Guidelines?)

[Thorsten Wilms]

On 30/10/2018 08.48, Mark H Weaver wrote:

> While I'm generally in favor of the CoC, I strongly oppose the idea that
> submitting a patch or communicating with us implies automatic agreement
> to our policies.

Quoting from the other thread:
On 29/10/2018 18.43, Ricardo Wurmus wrote:>

 > If you would like to improve the text of the Code of Conduct
 > to clarify it, I would like to encourage you to submit a
 > patch draft here:
 >
 >      https://github.com/ContributorCovenant
 > /contributor_covenant

Not a draft, just an issue to see if there's a chance to change the 
"pledge" issue at the root:
https://github.com/ContributorCovenant/contributor_covenant/issues/624

Just in case anyone here feels like showing some support there.


-- 
Thorsten Wilms

thorwil's design for free software:
http://thorwil.wordpress.com/

Re: Promoting the GNU Kind Communication Guidelines?

[Tonton]

On Sun, 28 Oct 2018 14:50:54 -0500
Alex Griffin <a@ajgrf.com> wrote:

> On Sun, Oct 28, 2018, at 1:42 PM, Tonton wrote:
> > It seems to me you are making punishment way bigger than it actually is.  
> 
> The CoC actually says that maintainers have a responsibility to remove 
> offenders or risk being removed themselves. ...

I'm assuming you are referring to this passage:

> Project 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.

The risk of maintainers being removed is slight, the text here talks about
misconduct and other maintainers have to make a decision on a case by case
basis - just like they would have to in relation to any other accusation of
breach. As far as I understand this paragraf is explicitly saying that
maintainers are within the scope of the CoC and they have some extra
responsiblity to it.

> > Remember the CoC is only true for some communities/cultures, it does not
> > influence your legal entity outside of your interactions with the
> > community  
> 
> To enter into a covenant, or agree to be bound by a code, means to stake 
> your word on it. The words themselves actually carry weight, and not 
> just as rules to follow, which is why the tiniest details of these 
> documents receive so much scrutiny.

There are limits though. The CC pledges you to abide by it's rules in
relation to a certain community. Outside of this you are not pledged to it.
but see below.

I'm not sure I understand what you mean by "The words themselves actually
carry weight, and not just as rules to follow" How do they carry weight
outside of setting rules? I'm a bit intrigued by how much weight you put in
your words though. Do you never blow with the wind and dance with the stars
because of this bondage to words?

	:)

> 
> From sentence 1 of the Contributor Covenant:
> > In the interest of fostering an open and welcoming environment, we as 
> > contributors and maintainers pledge to [...]  
> 
> This snippet right here is a problem even before we get to the meat and 
> potatoes. I don't appreciate the presumption that my mere participation 
> indicates my agreement with this document. It rubs me the wrong way even 
> when I'm only reporting a bug (which does fall under its scope, because 
> 'issues', as found in an issue tracker, are explicitly mentioned further 
> down).
> 

This is kind of like the Law of Cardamom[1]. The CC and most other CoC's I've
seen in FLOSS assume you are acting in good faith and that we are kind to
each other. I too spent some time mulling that one over, but seeing as it
asks you to pledge what I see as a low standard of communication I found no
problem with it. The fact that it gives some of us pause is probably enough
to warrant a change though.

So I skimmed over debians CoC[2] and find it to be mostly similar to the CC,
though with a more positive and welcoming language (which also skips mention
of negative behaviour). There's a few things I miss from it like process -
which is alluded to, but not present as far as I could see. Looks good to me
with a few additions.

Let's see what comes of the discussion.

[1]: https://en.wikipedia.org/wiki/When_the_Robbers_Came_to_Cardamom_Town#Law
[2]: https://www.debian.org/code_of_conduct

On Sun, 28 Oct 2018 16:26:58 -0500
Alex Griffin <a@ajgrf.com> wrote:
> Think about it this way. The Contributor Covenant goes on about the many
> different ways that a disagreement might escalate, while the Debian CoC
> spends almost all of its time modeling how to de-escalate a disagreement.

I wonder if we are reading the same document. I'm assuming it's this one:
https://www.contributor-covenant.org/version/1/4/code-of-conduct
As far as I can see it spends equal time on positive and negative behaviour
and then defines responsibilities, scope and process. Debians spend time
encouraging positive behaviour, and alludes to process - it misses
responsibility and properly talking about process.

Debians also misses defining negative behaviour, which leaves it up to
potential contributors to investigate what is allowed and not in the
community. This is enough for some to not bother trying, and that is one of
the important points. I (we) want to include them.

On Sun, 28 Oct 2018 15:25:01 -0500
Alex Griffin <a@ajgrf.com> wrote:
> In a sense, the Debian Code of Conduct is a code in name only. It's really
> just 6 guidelines for kind communication and resolving conflicts
> peacefully, and finally a method for seeking recourse either as a last
> resort or in serious cases. The Contributor Covenant is actually a real
> covenant.

that's the same thing. :) I encourage reading the tao of pooh - this is
completely off topic.

RE: Promoting the GNU Kind Communication Guidelines?

[Cook, Malcolm]

This so very well said - thank you Alex - were there a vote to recast mine flows thusly:

> I'm so glad you brought this up, because it seems equally plausible to me
 > that the other party could be reacting  overly sensitively.
 > 
 > This is precisely why it is a bad idea to set up an authority for people to
 > appeal to. In many cases it's not clear which party is the unreasonable one,
 > and it must be worked through with dialogue.
 > 
 > If people don't have to work things out among themselves, and disputes are
 > instead handled by a committee of project maintainers, contributors lose
 > the opportunity to better understand each other. Oh, and that committee
 > of maintainers have all agreed according to the Contributor Covenant that
 > they have a responsibility to punish abusers, so they might find it difficult to
 > avoid being biased towards punishing the accused.
 > 
 > Software projects should focus on software. They are not equipped to
 > administer justice.

Re: Promoting the GNU Kind Communication Guidelines?

[Ludovic Courtès]

Hello Mathieu,

Good to see you here!

Mathieu Lirzin <mthl@gnu.org> skribis:

> Following the announcement made by RMS regarding the new GNU Kind
> Communication Guidelines (GKCG) [1], I would like to know if the Guix
> developpers in particular its maintainers would agree to adopt it in
> place of the current Code of Conduct (CoC)?

Speaking for myself: no.  I think the GKCG fails to address important
issues, such as defining what’s acceptable and what’s not as well as
clear processes to address this.

> Adopting the GKCG instead of a CoC would help attracting people (like
> me) who agree to use a welcoming and respectful language which
> encourages everyone to contribute but are reluctant in contributing to
> any project following a CoC due to its punitive nature and the politics
> of its authors [2][3].

Codes of conduct codify acceptable behavior and formalize processes:
what can I do as a contributor if I’m a victim bad behavior or
harassment?  What are the group communication rules?  What if I
knowingly break those rules?

By adopting the code of conduct, we maintainers committed to spend our
time as needed to so your experience contributing to Guix won’t be a
source of stress or worse, as is too often the case in on-line
communities.

The GKCG do not do that.  Problems will be dealt with in an ad hoc
fashion (as they already are in groups that have not codified rules), if
they are addressed at all.

I hope this answers your question.

Happy hacking!

Ludo’.

Re: Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello Ludo,

ludo@gnu.org (Ludovic Courtès) writes:

> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> Following the announcement made by RMS regarding the new GNU Kind
>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
>> developpers in particular its maintainers would agree to adopt it in
>> place of the current Code of Conduct (CoC)?
>
> Speaking for myself: no.  I think the GKCG fails to address important
> issues, such as defining what’s acceptable and what’s not as well as
> clear processes to address this.

I am sad that you feels that the GKCG is not sufficient for defining the
acceptable behavior of the members of a Free Software community.

>> Adopting the GKCG instead of a CoC would help attracting people (like
>> me) who agree to use a welcoming and respectful language which
>> encourages everyone to contribute but are reluctant in contributing to
>> any project following a CoC due to its punitive nature and the politics
>> of its authors [2][3].
>
> Codes of conduct codify acceptable behavior and formalize processes:
> what can I do as a contributor if I’m a victim bad behavior or
> harassment?  What are the group communication rules?  What if I
> knowingly break those rules?
>
> By adopting the code of conduct, we maintainers committed to spend our
> time as needed to so your experience contributing to Guix won’t be a
> source of stress or worse, as is too often the case in on-line
> communities.
>
> The GKCG do not do that.  Problems will be dealt with in an ad hoc
> fashion (as they already are in groups that have not codified rules), if
> they are addressed at all.
>
> I hope this answers your question.

Yes it does perfectly.

I personnaly think dealing with such issues in an ad hoc fashion is the
right approach when acceptable behaviors are the norm, which IME has
been the case.

Anyway I still hope that the Guix community will eventually accept the
GKCG as an acceptable tradeoff in the CoC debate.

Thanks.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Promoting the GNU Kind Communication Guidelines?

[Ricardo Wurmus]

Hello Mathieu,

> Mathieu Lirzin <mthl@gnu.org> skribis:
>
>> Following the announcement made by RMS regarding the new GNU Kind
>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
>> developpers in particular its maintainers would agree to adopt it in
>> place of the current Code of Conduct (CoC)?
>
> Speaking for myself: no.  I think the GKCG fails to address important
> issues, such as defining what’s acceptable and what’s not as well as
> clear processes to address this.

[Apologies for the delay; I’m currently traveling.]

Adding to what Ludovic wrote, I also would not want to replace the
current proven Contributor Covenant with the recently emerged GKCG.
Using *both* of them would not be useful, I think, as I find our current
CoC to be sufficient; using *only* the GKCG and dropping the existing
CoC would be a mistake in my opinion, as our CoC describes a process
which the GKCG does not.

Committing to a process to deal with grievances is a very desirable
feature of our current CoC that I don’t want to give up.  As one of the
people who shares responsibility for dealing with incidents of
harassment or misunderstandings, this helps me do a better job.

Even so, I encourage people to continue to engage in fostering kind
communication in the channels of the Guix project, something that this
community by and large does very well.

>> Adopting the GKCG instead of a CoC would help attracting people (like
>> me) who agree to use a welcoming and respectful language which
>> encourages everyone to contribute but are reluctant in contributing to
>> any project following a CoC due to its punitive nature and the politics
>> of its authors [2][3].

To me the politics of the author(s) of the original or current version
of the Contributor Covenant don’t play much of a role in prefering it as
a practical guiding document for this community.  (I don’t know the
author.)

I think I see how it could be seen as “punitive”, but I don’t share this
assessment.  We all want what’s best for the project and the people who
currently work on or consider working on it — to me the emergence of the
GKCG is more evidence that this is true.  I hope that seeing these
similarities in intent more than the differences in implementation will
allow you to overcome your feeling of reluctance to contribute to Guix
(and other projects that have decided to adopt a CoC).

--
Ricardo

Re: Promoting the GNU Kind Communication Guidelines?

[Mathieu Lirzin]

Hello Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

>> Mathieu Lirzin <mthl@gnu.org> skribis:
>>
>>> Following the announcement made by RMS regarding the new GNU Kind
>>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
>>> developpers in particular its maintainers would agree to adopt it in
>>> place of the current Code of Conduct (CoC)?
>>
>> Speaking for myself: no.  I think the GKCG fails to address important
>> issues, such as defining what’s acceptable and what’s not as well as
>> clear processes to address this.
>
> [Apologies for the delay; I’m currently traveling.]

No need to apology, your response is still prompt. :-)

> Adding to what Ludovic wrote, I also would not want to replace the
> current proven Contributor Covenant with the recently emerged GKCG.
> Using *both* of them would not be useful, I think, as I find our current
> CoC to be sufficient; using *only* the GKCG and dropping the existing
> CoC would be a mistake in my opinion, as our CoC describes a process
> which the GKCG does not.

AIUI the GKCG is an attempt to reconcile people of the GNU hackers
community which is has been fragmented by the CoC debate.

In order to reconcile, each “camp” has to make some tradeoffs.  Since
you are a CoC proponent, it is normal that you feel that the GKCG is not
as “good” as the CoC.  However I would really appreciate if you (and
Ludo) could seriously consider the GKCG “downsides” as an acceptable
tradeoff to help uniting GNU Hackers and move the GNU project as a whole
(not just the Guix project) towards what you consider the “right”
direction in the “harassment free” path.

>>> Adopting the GKCG instead of a CoC would help attracting people
>>> (like me) who agree to use a welcoming and respectful language which
>>> encourages everyone to contribute but are reluctant in contributing
>>> to any project following a CoC due to its punitive nature and the
>>> politics of its authors [2][3].
>
> To me the politics of the author(s) of the original or current version
> of the Contributor Covenant don’t play much of a role in prefering it as
> a practical guiding document for this community.  (I don’t know the
> author.)

Have you consider that it doesn't play a role because you basically
share similar political ideas as the author(s) without knowing/caring?
This is not intended as a critic, but just as an opportunity for you to
consider that your own political bias (which we humans all have) is not
universal and that maybe other “respectable” persons might not share it.

> I think I see how it could be seen as “punitive”, but I don’t share this
> assessment.  We all want what’s best for the project and the people who
> currently work on or consider working on it — to me the emergence of the
> GKCG is more evidence that this is true.  I hope that seeing these
> similarities in intent more than the differences in implementation will
> allow you to overcome your feeling of reluctance to contribute to Guix
> (and other projects that have decided to adopt a CoC).

As explain above, I don't think the CoC and GKCG has the same intent.
If it were the case that Guix choose to ignore this opportunity to
reconcile, I am sorry to say that my reluctance to contribute to Guix
would not diminish.

Thanks for you answer.

-- 
Mathieu Lirzin
GPG: F2A3 8D7E EB2B 6640 5761  070D 0ADE E100 9460 4D37

Re: Promoting the GNU Kind Communication Guidelines?

[George Clemmer]

Hello

Ricardo Wurmus <rekado@elephly.net> writes:

> Hello Mathieu,
>
>> Mathieu Lirzin <mthl@gnu.org> skribis:
>>
>>> Following the announcement made by RMS regarding the new GNU Kind
>>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
>>> developpers in particular its maintainers would agree to adopt it in
>>> place of the current Code of Conduct (CoC)?
>>
>> Speaking for myself: no.  I think the GKCG fails to address important
>> issues, such as defining what’s acceptable and what’s not as well as
>> clear processes to address this.
>
> [Apologies for the delay; I’m currently traveling.]
>
> Adding to what Ludovic wrote, I also would not want to replace the
> current proven Contributor Covenant with the recently emerged GKCG.
> Using *both* of them would not be useful, I think, as I find our current
> CoC to be sufficient; using *only* the GKCG and dropping the existing
> CoC would be a mistake in my opinion, as our CoC describes a process
> which the GKCG does not.
>
> Committing to a process to deal with grievances is a very desirable
> feature of our current CoC that I don’t want to give up.  As one of the
> people who shares responsibility for dealing with incidents of
> harassment or misunderstandings, this helps me do a better job.
>
> Even so, I encourage people to continue to engage in fostering kind
> communication in the channels of the Guix project, something that this
> community by and large does very well.
>
>>> Adopting the GKCG instead of a CoC would help attracting people (like
>>> me) who agree to use a welcoming and respectful language which
>>> encourages everyone to contribute but are reluctant in contributing to
>>> any project following a CoC due to its punitive nature and the politics
>>> of its authors [2][3].
>
> To me the politics of the author(s) of the original or current version
> of the Contributor Covenant don’t play much of a role in prefering it as
> a practical guiding document for this community.  (I don’t know the
> author.)
>
> I think I see how it could be seen as “punitive”, but I don’t share this
> assessment.  We all want what’s best for the project and the people who
> currently work on or consider working on it — to me the emergence of the
> GKCG is more evidence that this is true.  I hope that seeing these
> similarities in intent more than the differences in implementation will
> allow you to overcome your feeling of reluctance to contribute to Guix
> (and other projects that have decided to adopt a CoC).

The responses above seem consistent with why CoC mightq appeal to
maintainers. But as a Guix user and occasional contributor, I find GKCG
more welcoming and more useful. For me, RMS' rationale is compelling:

    The idea of the GNU Kind Communication Guidelines is to start
    guiding people towards kinder communication at a point well before
    one would even think of saying, "You are breaking the rules."  The
    way we do this, rather than ordering people to be kind or else, is
    try to help people learn to make their communication more kind.

It is really the either-or situation implied by the discussion above?

What would be wrong with adding GKCG and keeping CoC?

- George

Re: Promoting the GNU Kind Communication Guidelines?

[Gábor Boskovits]

Hello

George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. okt. 26., P, 1:04):
>
> Hello
>
> Ricardo Wurmus <rekado@elephly.net> writes:
>
> > Hello Mathieu,
> >
> >> Mathieu Lirzin <mthl@gnu.org> skribis:
> >>
> >>> Following the announcement made by RMS regarding the new GNU Kind
> >>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
> >>> developpers in particular its maintainers would agree to adopt it in
> >>> place of the current Code of Conduct (CoC)?
> >>
> >> Speaking for myself: no.  I think the GKCG fails to address important
> >> issues, such as defining what’s acceptable and what’s not as well as
> >> clear processes to address this.
> >
> > [Apologies for the delay; I’m currently traveling.]
> >
> > Adding to what Ludovic wrote, I also would not want to replace the
> > current proven Contributor Covenant with the recently emerged GKCG.
> > Using *both* of them would not be useful, I think, as I find our current
> > CoC to be sufficient; using *only* the GKCG and dropping the existing
> > CoC would be a mistake in my opinion, as our CoC describes a process
> > which the GKCG does not.

I belive that if there are voices who would like to have them both, there is
actually no problem with using both. The current CoC is in fact sufficient, but
if having the GKCG also makes people feel better I am not opposed to adopt it.

> >
> > Committing to a process to deal with grievances is a very desirable
> > feature of our current CoC that I don’t want to give up.  As one of the
> > people who shares responsibility for dealing with incidents of
> > harassment or misunderstandings, this helps me do a better job.
> >
> > Even so, I encourage people to continue to engage in fostering kind
> > communication in the channels of the Guix project, something that this
> > community by and large does very well.
> >
> >>> Adopting the GKCG instead of a CoC would help attracting people (like
> >>> me) who agree to use a welcoming and respectful language which
> >>> encourages everyone to contribute but are reluctant in contributing to
> >>> any project following a CoC due to its punitive nature and the politics
> >>> of its authors [2][3].
> >
> > To me the politics of the author(s) of the original or current version
> > of the Contributor Covenant don’t play much of a role in prefering it as
> > a practical guiding document for this community.  (I don’t know the
> > author.)
> >
> > I think I see how it could be seen as “punitive”, but I don’t share this
> > assessment.  We all want what’s best for the project and the people who
> > currently work on or consider working on it — to me the emergence of the
> > GKCG is more evidence that this is true.  I hope that seeing these
> > similarities in intent more than the differences in implementation will
> > allow you to overcome your feeling of reluctance to contribute to Guix
> > (and other projects that have decided to adopt a CoC).
>
> The responses above seem consistent with why CoC mightq appeal to
> maintainers. But as a Guix user and occasional contributor, I find GKCG
> more welcoming and more useful. For me, RMS' rationale is compelling:
>
>     The idea of the GNU Kind Communication Guidelines is to start
>     guiding people towards kinder communication at a point well before
>     one would even think of saying, "You are breaking the rules."  The
>     way we do this, rather than ordering people to be kind or else, is
>     try to help people learn to make their communication more kind.
>
> It is really the either-or situation implied by the discussion above?
>
> What would be wrong with adding GKCG and keeping CoC?
>

I think this can be done, I feel nothing wrong with it.

> - George
>

It is also quite obvious what the maintainers feel missing from
GKCG, so it also might be possible to improve on the current
GKCG and make some of the features of CoC available, like:
1. Explicitly defining acceptable and not acceptable behaviour
(maybe by providing a liked document for that for flexibility and
easier adoptation)
2. Explicitly define a process to deal with issues
(this can also be a linked doument)
One way to do this easily would be to provide the current CoC as the
linked document
defining these. Later we could improve on this.
WDYT?

Best regards,
g_bor

Re: Promoting the GNU Kind Communication Guidelines?

[Alex Griffin]

Adopting both actually does nothing for those who take issue with the CoC, since between the 2 documents the stricter one must take precedence in order to mean anything at all.

-- 
Alex Griffin

On Thu, Oct 25, 2018, at 9:43 PM, Gábor Boskovits wrote:
> Hello
> 
> George Clemmer <myglc2@gmail.com> ezt írta (időpont: 2018. okt. 26., P, 1:04):
> >
> > Hello
> >
> > Ricardo Wurmus <rekado@elephly.net> writes:
> >
> > > Hello Mathieu,
> > >
> > >> Mathieu Lirzin <mthl@gnu.org> skribis:
> > >>
> > >>> Following the announcement made by RMS regarding the new GNU Kind
> > >>> Communication Guidelines (GKCG) [1], I would like to know if the Guix
> > >>> developpers in particular its maintainers would agree to adopt it in
> > >>> place of the current Code of Conduct (CoC)?
> > >>
> > >> Speaking for myself: no.  I think the GKCG fails to address important
> > >> issues, such as defining what’s acceptable and what’s not as well as
> > >> clear processes to address this.
> > >
> > > [Apologies for the delay; I’m currently traveling.]
> > >
> > > Adding to what Ludovic wrote, I also would not want to replace the
> > > current proven Contributor Covenant with the recently emerged GKCG.
> > > Using *both* of them would not be useful, I think, as I find our current
> > > CoC to be sufficient; using *only* the GKCG and dropping the existing
> > > CoC would be a mistake in my opinion, as our CoC describes a process
> > > which the GKCG does not.
> 
> I belive that if there are voices who would like to have them both, there is
> actually no problem with using both. The current CoC is in fact sufficient, but
> if having the GKCG also makes people feel better I am not opposed to adopt it.
> 
> > >
> > > Committing to a process to deal with grievances is a very desirable
> > > feature of our current CoC that I don’t want to give up.  As one of the
> > > people who shares responsibility for dealing with incidents of
> > > harassment or misunderstandings, this helps me do a better job.
> > >
> > > Even so, I encourage people to continue to engage in fostering kind
> > > communication in the channels of the Guix project, something that this
> > > community by and large does very well.
> > >
> > >>> Adopting the GKCG instead of a CoC would help attracting people (like
> > >>> me) who agree to use a welcoming and respectful language which
> > >>> encourages everyone to contribute but are reluctant in contributing to
> > >>> any project following a CoC due to its punitive nature and the politics
> > >>> of its authors [2][3].
> > >
> > > To me the politics of the author(s) of the original or current version
> > > of the Contributor Covenant don’t play much of a role in prefering it as
> > > a practical guiding document for this community.  (I don’t know the
> > > author.)
> > >
> > > I think I see how it could be seen as “punitive”, but I don’t share this
> > > assessment.  We all want what’s best for the project and the people who
> > > currently work on or consider working on it — to me the emergence of the
> > > GKCG is more evidence that this is true.  I hope that seeing these
> > > similarities in intent more than the differences in implementation will
> > > allow you to overcome your feeling of reluctance to contribute to Guix
> > > (and other projects that have decided to adopt a CoC).
> >
> > The responses above seem consistent with why CoC mightq appeal to
> > maintainers. But as a Guix user and occasional contributor, I find GKCG
> > more welcoming and more useful. For me, RMS' rationale is compelling:
> >
> >     The idea of the GNU Kind Communication Guidelines is to start
> >     guiding people towards kinder communication at a point well before
> >     one would even think of saying, "You are breaking the rules."  The
> >     way we do this, rather than ordering people to be kind or else, is
> >     try to help people learn to make their communication more kind.
> >
> > It is really the either-or situation implied by the discussion above?
> >
> > What would be wrong with adding GKCG and keeping CoC?
> >
> 
> I think this can be done, I feel nothing wrong with it.
> 
> > - George
> >
> 
> It is also quite obvious what the maintainers feel missing from
> GKCG, so it also might be possible to improve on the current
> GKCG and make some of the features of CoC available, like:
> 1. Explicitly defining acceptable and not acceptable behaviour
> (maybe by providing a liked document for that for flexibility and
> easier adoptation)
> 2. Explicitly define a process to deal with issues
> (this can also be a linked doument)
> One way to do this easily would be to provide the current CoC as the
> linked document
> defining these. Later we could improve on this.
> WDYT?
> 
> Best regards,
> g_bor
>