[arch-dev-public] Formal Objection to Adopting the Code of Conduct

[Allan McRae]

On 5/9/21 11:12 am, Giancarlo Razzolini wrote:
> Em setembro 4, 2021 12:17 Allan McRae via arch-dev-public escreveu:
>>
>> The CoC was adopted on the forum, because that is where it was developed
>> as the pet project of an admin at the time.  And then spread to the
>> support channels, which were all run by teams that historically had no
>> say in Arch development (I note this has changed recently).  So a CoC
>> has never been *formally* adopted to cover the whole distribution.  At
>> least I can find no mailing list thread either on this list, or the
>> private developer mailing list that formalised the adoption of these
>> rules.
>>
> 
> It was formally adopted, regardless of how many times you claim it wasn't.
> I want to point out, specially, the CoC is of extreme relevance to the
> support
> channels, so, even if your perception was that it was not formal, that's
> mostly
> it, a perception.

To be formally adopted by the distribution, there would need to be a
discussion among the governing body (which was (is?) the distribution
developers) where they agree to adopt it.  No such discussion has taken
place.

It has been adopted by various support fora teams, which have
historcially run with relative independence from the main distribution.

>> Also, the Code of Conduct has changed many times across this period
>> without any oversight. This includes what has been done recently on
>> gitlab - what proportion of the Arch staff approved changes committed
>> into that repository?  Has a vote of any sort been held to ensure
>> changes were agreed upon by Arch staff (being our current governing
>> body)?
>>
> 
> Most of the changes made, were to improve ambiguous wording or to
> clarify where
> wording was not clear enough. It goes without saying that, on an ideal
> world, a
> CoC shouldn't even be needed. However, we live in an imperfect world,
> and the need
> for a CoC emerges from that.

It seems adding an entire enforcement section was "ambiguous wording".
 An enforcement policy that adds powers to the project leader that are
beyond their defined role.  An enforcement policy that was agreed to
after formal discussion with all involved parties?

If the CoC document had been formally adopted as you claim, there should
have been much wider discussion about adding this section once its
wording had been determined. Because a formal policy can not be changed
without approval from the governing body.

>> The argument this is in gitlab is not enough. I have commented on merge
>> requests and even submitted my own merge requests, and am listed as a
>> member of the project (Reporter), and have received no emails about
>> changes being made.  This is not a formal oversight of CoC changes up
>> until it is formally adopted.
>>
> 
> The CoC was widely used across the distribution long before we even had
> gitlab. Or
> even before it was on any VCS form.

Widely used does not mean formally adopted.  We had a written policy
about posting pictures of cats on various web pages during server
maintenance that was widely used for many years.  That was not
considered a formal policy.  The fact that "policy" was deleted from the
DeveloperWiki without discussion is a clear indication that being widely
used is not enough to consider something as formally adopted policy.

> We have plenty of informal stuff that was elevated to processes on Arch,
> but you
> seem to have found issue with the CoC. Just because something was self
> governed
> doesn't mean it's not part of the distro.

And were those process that were elevated to being formal policy done
with wider discussion, and knowing what the final wording was before
adopting these policies formally?

I remember all topics listed in the policies section of the
DeveloperWiki being discussed (although I can not remember agreement on
that Bash Coding Style policy!)

> I think the CoC has been around long enough for, if it was really an
> issue, you would
> have raised this objection a long time ago. The fact this is being
> raised on the verge of
> some service changes, tells me that, either you were not aware of the
> CoC before, or,
> you had no objections to it being used before, as long as it was not
> used on the services
> you think are relevant. I have already agreed with you that we will need
> some council/governance
> in the future, but we shouldn't halt everything until we do. So, I think
> your objections are
> noted, but I don't think we should form the council/governance body
> *right now*. It goes without
> saying that, when (not if) we have such body, they can make any changes
> to the CoC they see fit,
> as long as it's approved by the staff.

No - I disagree with a CoC being formally adopted without due process
and oversight.  That is my issue.  We clearly disagree of the formal
status of the CoC across the whole distribution in the past.

I think the fact the current version has been sent to lawyers to check
wording speaks volumes on a clear change of status towards formally
adopting this as policy.  Hence the timing of my objection.


Either the CoC was already a formal document and changes were made by a
small number of staff with limited oversight from the governing body -
in this case we need to revert to the last formal version and all
changes need formally agreed on.  Or it was not an official document and
we need to discuss formally adopting it.

So I see this issue can be addressed by the current governing body (the
Developers, preferably with input from all staff) in at least two ways:

1) There is a discussion and agreement around the formal adoption of the
CoC.

or

2) There is an agreement that the CoC was already official, AND a
discussion and agreement around the changes that were made since import
into the service agreement repo.

Effectively these are the same discussion.

Allan