Re: Promoting the GNU Kind Communication Guidelines?

[Gábor Boskovits]

Hello

George Clemmer <address@hidden> ezt írta (időpont: 2018. okt. 26., P, 1:04):
>
> Hello
>
> Ricardo Wurmus <address@hidden> writes:
>
> > Hello Mathieu,
> >
> >> Mathieu Lirzin <address@hidden> 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