We appear to be reaching the point where a formal code of conduct will be officially adopted.
What is that I hear you say? We have had a Code of Conduct for a long time? And you are incorrect.
The history of the Code of Conduct is poorly documented. But it started out as a forum guidelines written by one of the forum admins. As far as I can ascertain, this document had no input from the project leadership. At some stage this was moved to the wiki and became titled as a Code of Conduct as more general points were added to cover aspects of Arch beyond the forums.
At no point has this code of conduct ever been formally adopted by the distribution. In fact, our distribution has no constitution detailing what the purpose of this distribution is and how it will be governed. So there is no formal process for officially adopting a Code of Conduct.
Why does this matter now? The Code of Conduct is moving from being a random wiki page, to a "binding" document that users must agree to in order to access our services. Before this can happen, Arch Linux needs to adopt a formal governance structure in order to approve such a binding change.
Take a look at other distributions governance structures and constitutions: https://www.debian.org/devel/constitution https://docs.fedoraproject.org/en-US/council/
I formally object to adopting a formal Code of Conduct until we have a clear governance structure who can develop the policies and procedures that are formally needed to enforce a Code of Conduct. Currently the Code of Conduct states the Project Leader is responsible for enforcement, although that is not listed as one of their duties as approved when developing the Project Leader election procedure: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader This once again demonstrate the lack of formal governance within the distribution. We can not proceed with a Code of Conduct (or the Terms of Service and Privacy Policy), until a formal governance structure and procedures are developed to approve such documents.
Again, until such a governance structure has been developed, I formally object to the official adoption of the Code of Conduct.
Kind regards, Allan
Em setembro 4, 2021 9:36 Allan McRae via arch-dev-public escreveu:
We appear to be reaching the point where a formal code of conduct will be officially adopted.
Hmm, it was a long time ago. It's pointed out on all the support channels.
What is that I hear you say? We have had a Code of Conduct for a long time? And you are incorrect.
Not really.
The history of the Code of Conduct is poorly documented. But it started out as a forum guidelines written by one of the forum admins. As far as I can ascertain, this document had no input from the project leadership. At some stage this was moved to the wiki and became titled as a Code of Conduct as more general points were added to cover aspects of Arch beyond the forums.
As far as I know both Aaron, which was the leader when the CoC was introduced, and Levente, not only knew about the CoC, but were fine with it.
At no point has this code of conduct ever been formally adopted by the distribution. In fact, our distribution has no constitution detailing what the purpose of this distribution is and how it will be governed. So there is no formal process for officially adopting a Code of Conduct.
The CoC was adopted by all the support channels.
Why does this matter now? The Code of Conduct is moving from being a random wiki page, to a "binding" document that users must agree to in order to access our services. Before this can happen, Arch Linux needs to adopt a formal governance structure in order to approve such a binding change.
Why it needs "formal governance"?
Take a look at other distributions governance structures and constitutions: https://www.debian.org/devel/constitution https://docs.fedoraproject.org/en-US/council/
Both Debian and Fedora have thousands of contributors, we have about a hundred formal staff, plus many volunteers that help on the support channels. I'm not saying we shouldn't have formal documents (we're headed that way), just saying I don't think we need a constitution, yet.
I formally object to adopting a formal Code of Conduct until we have a clear governance structure who can develop the policies and procedures that are formally needed to enforce a Code of Conduct. Currently the Code of Conduct states the Project Leader is responsible for enforcement, although that is not listed as one of their duties as approved when developing the Project Leader election procedure: https://wiki.archlinux.org/title/DeveloperWiki:Project_Leader This once again demonstrate the lack of formal governance within the distribution. We can not proceed with a Code of Conduct (or the Terms of Service and Privacy Policy), until a formal governance structure and procedures are developed to approve such documents.
Again with the assertion that we cannot proceed without governance. The "why" is missing. Don't get me wrong, I think we will inevitably have some sort of council. But I don't see the need for one *right now*. Nor do I think we should block everything until we do.
Again, until such a governance structure has been developed, I formally object to the official adoption of the Code of Conduct.
Again, it was adopted for a long time now.
Regards, Giancarlo Razzolini
On 5/9/21 12:02 am, Giancarlo Razzolini wrote:
Em setembro 4, 2021 9:36 Allan McRae via arch-dev-public escreveu:
We appear to be reaching the point where a formal code of conduct will be officially adopted.
Hmm, it was a long time ago. It's pointed out on all the support channels.
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.
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)?
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.
As far as I know both Aaron, which was the leader when the CoC was introduced, and Levente, not only knew about the CoC, but were fine with it.
When Aaron was actually active, the CoC was a thread on the forum. Even throughout the period Aaron was a mostly inactive leader, it was never elevated to a distribution wide document.
The rules for the Project Leader that were established when Levente was elected do not give him the ability to approve a CoC. This is done by the development team, with the Project Leader intervening with lack of consensus. BTW, those rules state the Project Leader is the Arch legal representative, so I assume the lawyering of these documents went through him, or the formal approval of representative took place on the internal mailing lists.
Again with the assertion that we cannot proceed without governance. The "why" is missing.
The creation and adoption of binding official policies needs oversight. Without a proper governance structure to be responsible for maintaining and enforcing such documents there is a lack of accountability. Our current informal governance structure involving all developers (or even all staff) could be used for now to do this. It is likely a smaller elected body would be more efficient going forward.
To be clear, I do not object to there being an Arch Code of Conduct. That is necessary.
I object to the current one being extended beyond the informal adoption by various Arch services to being a formal distribution document without a "governing body" approving the *final* wording.
Allan
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.
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.
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.
When Aaron was actually active, the CoC was a thread on the forum. Even throughout the period Aaron was a mostly inactive leader, it was never elevated to a distribution wide document.
It was though. And there's even a thread from 2019 where the CoC was evoked and Aaron was called to give his input on a dispute.
The rules for the Project Leader that were established when Levente was elected do not give him the ability to approve a CoC. This is done by the development team, with the Project Leader intervening with lack of consensus. BTW, those rules state the Project Leader is the Arch legal representative, so I assume the lawyering of these documents went through him, or the formal approval of representative took place on the internal mailing lists.
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.
The creation and adoption of binding official policies needs oversight. Without a proper governance structure to be responsible for maintaining and enforcing such documents there is a lack of accountability. Our current informal governance structure involving all developers (or even all staff) could be used for now to do this. It is likely a smaller elected body would be more efficient going forward.
At least now you gave a reasoning. I already agreed we will eventualy have a council/governing body. However, trying to stop things from going forward because your perception of the CoC never being "officialized", is not good.
To be clear, I do not object to there being an Arch Code of Conduct. That is necessary.
I understood that your objection was not against the CoC, and I want to think that anyone reading this understands you're not opposed to the CoC.
I object to the current one being extended beyond the informal adoption by various Arch services to being a formal distribution document without a "governing body" approving the *final* wording.
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.
Regards, Giancarlo Razzolini
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
On 9/5/21 04:38, Allan McRae via arch-dev-public wrote:
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:
- There is a discussion and agreement around the formal adoption of the
CoC.
or
- 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.
I think at this point it isn't really leading anywhere to try to argue who is exactly right about the status quo. What does matter more is how we want to proceed to get the changes official -- this is where i agree that it kind of is the very same discussion/procedure this should go through to either get the changes or the overall thing in place.
Using a clear procedure for the current and future changes does not only make sense because this is a distro wide formal document, but also as this is implicitly part of the service agreement and changes will hence need to be propagated to all users actively.
We've talked about this in a small working group for a while and came to two action points partially related but independent from each other:
1) Use the RFC process to adapt the CoC document in its current form:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
This RFC formalizes the current CoC changes as well as defines how to proceed with changes in terms of transparency (visibility across the staff) as well as implications for the terms of service.
2) Adaption of the Arch Mediation Program
This program has been discussed for a while now. The time has come to take it forward and propose a concrete RFC that can be reviewed and adapted including a procedure to nominate and vote on mediators.
This is related to the CoC, but can live independently. In case former got adapted, this would lead to a small change in the CoC escalation paragraphs including the mediators as an official layer.
Thanks for bringing up this discussion and making those changes rock solid.
cheers, Levente
arch-dev-public@lists.archlinux.org