From mboxrd@z Thu Jan 1 00:00:00 1970 From: Alex Griffin Subject: Re: Promoting the GNU Kind Communication Guidelines? Date: Fri, 26 Oct 2018 16:25:43 -0500 Message-ID: <1540589143.374044.1556128712.057186A2@webmail.messagingengine.com> References: <87k1m852yc.fsf@gnu.org> <8736sv7iex.fsf@gnu.org> <87va5q5nq7.fsf@elephly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:59508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG9c7-0003QF-OG for guix-devel@gnu.org; Fri, 26 Oct 2018 17:25:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG9c3-0001Wz-LO for guix-devel@gnu.org; Fri, 26 Oct 2018 17:25:51 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:52633) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG9c3-0001Vs-7J for guix-devel@gnu.org; Fri, 26 Oct 2018 17:25:47 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 2C4D3CCD for ; Fri, 26 Oct 2018 17:25:44 -0400 (EDT) In-Reply-To: List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: guix-devel@gnu.org 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 orde= r to mean anything at all. --=20 Alex Griffin On Thu, Oct 25, 2018, at 9:43 PM, G=C3=A1bor Boskovits wrote: > Hello >=20 > George Clemmer ezt =C3=ADrta (id=C5=91pont: 2018. okt.= 26., P, 1:04): > > > > Hello > > > > Ricardo Wurmus writes: > > > > > Hello Mathieu, > > > > > >> Mathieu Lirzin skribis: > > >> > > >>> Following the announcement made by RMS regarding the new GNU Kind > > >>> Communication Guidelines (GKCG) [1], I would like to know if the Gu= ix > > >>> 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=E2=80=99s acceptable and what=E2=80=99= s not as well as > > >> clear processes to address this. > > > > > > [Apologies for the delay; I=E2=80=99m 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 curr= ent > > > 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. >=20 > 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 sufficien= t, but > if having the GKCG also makes people feel better I am not opposed to adop= t it. >=20 > > > > > > Committing to a process to deal with grievances is a very desirable > > > feature of our current CoC that I don=E2=80=99t 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 (li= ke > > >>> 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 poli= tics > > >>> of its authors [2][3]. > > > > > > To me the politics of the author(s) of the original or current version > > > of the Contributor Covenant don=E2=80=99t play much of a role in pref= ering it as > > > a practical guiding document for this community. (I don=E2=80=99t kn= ow the > > > author.) > > > > > > I think I see how it could be seen as =E2=80=9Cpunitive=E2=80=9D, but= I don=E2=80=99t share this > > > assessment. We all want what=E2=80=99s best for the project and the = people who > > > currently work on or consider working on it =E2=80=94 to me the emerg= ence of the > > > GKCG is more evidence that this is true. I hope that seeing these > > > similarities in intent more than the differences in implementation wi= ll > > > 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? > > >=20 > I think this can be done, I feel nothing wrong with it. >=20 > > - George > > >=20 > 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? >=20 > Best regards, > g_bor >=20