An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Summary: The adoption of a distribution-wide Code of Conduct (CoC) helps to describe the social contract by which communication takes place on the various communication channels offered by Arch Linux. This document describes the current CoC, its purpose and location and how to interact with it.
Best, David
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Note that visiting the above link to make a comment would require agreeing to the Terms of Service, which includes the document under discussion. However, the RFC process does allow discussion external to the merge request, so people should feel free to respond elsewhere.
I do not disagree with Arch having *a* code of conduct. I disagree with Arch formally adopting *this* code of conduct. As I stated in [1], I find the current document to be extremely long. This is mostly due to explaining points in a level of detail that I consider condescending to the community. For example, I'm not sure a word other than condescending can be used to describe explaining in great detail what a troll is to a technical Linux distribution community.
I do not think Arch should formally adopt *this* code of conduct.
[1] https://lists.archlinux.org/pipermail/arch-dev-public/2021-July/030474.html
Regards, Allan
On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Note that visiting the above link to make a comment would require agreeing to the Terms of Service, which includes the document under discussion. However, the RFC process does allow discussion external to the merge request, so people should feel free to respond elsewhere.
I do not disagree with Arch having *a* code of conduct. I disagree with Arch formally adopting *this* code of conduct. As I stated in [1], I find the current document to be extremely long. This is mostly due to explaining points in a level of detail that I consider condescending to the community. For example, I'm not sure a word other than condescending can be used to describe explaining in great detail what a troll is to a technical Linux distribution community.
I do not think Arch should formally adopt *this* code of conduct.
[1] https://lists.archlinux.org/pipermail/arch-dev-public/2021-July/030474.html
Regards, Allan
I think it's important to move forward here and I really like that David has been keeping the ball rolling for so long. We've also blocked for a really long time on getting a proper set of documents for GDPR compliance in the form of ToS and the Privacy Policy.
I don't think it's condescending. If anything, the level of detail things are explained in make it easier to refer to this document alone when pointing our digressions as opposed to having to refer to external resources. The length doesn't appear to be unreasonable to me but I see how it could be improved.
However, I think it's somewhat necessary to get _something_ in place here as a CoC. Having something (even perhaps something that you think has some need of shortening) is certainly better than no CoC at all! As a compromise, I suggest perhaps pulling more detailed content (such as the stuff that you deem to be condescending) into foot notes so that the main body of the document will become a bit more focused and less explanatory. Would that work for you?
You appear to generally be agreeing to the overall do's and don'ts (as your MR's [0] overall points are about the same). I therefore would like to implore you to roll with this version for now and then improve upon it as a direct follow up.
We have to be careful not to burn out David here with too much controversy as when that happens, no one will be here to pick up this topic and there won't be any CoC at all.
Cheers, Sven
[0] https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/1...
On 7/10/21 1:41 am, Sven-Hendrik Haase via arch-dev-public wrote:
On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Note that visiting the above link to make a comment would require agreeing to the Terms of Service, which includes the document under discussion. However, the RFC process does allow discussion external to the merge request, so people should feel free to respond elsewhere.
I do not disagree with Arch having *a* code of conduct. I disagree with Arch formally adopting *this* code of conduct. As I stated in [1], I find the current document to be extremely long. This is mostly due to explaining points in a level of detail that I consider condescending to the community. For example, I'm not sure a word other than condescending can be used to describe explaining in great detail what a troll is to a technical Linux distribution community.
I do not think Arch should formally adopt *this* code of conduct.
[1] https://lists.archlinux.org/pipermail/arch-dev-public/2021-July/030474.html
Regards, Allan
I think it's important to move forward here and I really like that David has been keeping the ball rolling for so long. We've also blocked for a really long time on getting a proper set of documents for GDPR compliance in the form of ToS and the Privacy Policy.
I don't think it's condescending. If anything, the level of detail things are explained in make it easier to refer to this document alone when pointing our digressions as opposed to having to refer to external resources. The length doesn't appear to be unreasonable to me but I see how it could be improved.
Let look at the section for trolling:
--start-- A “troll” is a person who misuses their forum freedoms to intentionally disrupt, cause controversy, incite an argument, and/or receive negative attention by deliberately posting provocative content. The term may also be used as a verb, to refer to the act of posting such content, or as a noun, to refer the content itself.
Trolls can be deceitful and frequently use indirect expressions of hostility through ambivalence and implicit messages as a method of covertly insulting, intimidating, or inciting a person or persons for their own sadistic pleasure. They often pick their words very carefully and are therefore able to defend their masked attempts at creating unrest, redirecting the blame onto the community and its supposed failure to understand them properly. Trolling is prohibited. --end--
I find that super long, to the point where the message becomes unclear. Simply "No trolling" is effective, and unambiguous.
For some reason that is one on the six similar length sections under "Respect" and not with the seven overly long examples in "Examples of unwanted behaviour". This again highlights that the document is too long as it appears the authors lose track of appropriate sections for each point.
However, I think it's somewhat necessary to get _something_ in place here as a CoC. Having something (even perhaps something that you think has some need of shortening) is certainly better than no CoC at all! As a compromise, I suggest perhaps pulling more detailed content (such as the stuff that you deem to be condescending) into foot notes so that the main body of the document will become a bit more focused and less explanatory. Would that work for you?
It does not work for me. I don't set a bar too high for what I consider to be acceptable for Arch - avoiding perfect being the enemy of good and all - but I find the currently proposed Code of Conduct to be a poor reflection on the quality of the distribution.
You appear to generally be agreeing to the overall do's and don'ts (as your MR's [0] overall points are about the same). I therefore would like to implore you to roll with this version for now and then improve upon it as a direct follow up.
Note the currently proposed Code of Conduct would directly violate the CoC from my MR that contains the following:
Use concise and clear language
The Arch Linux distribution includes people from all over the world, with varying English skills and available time. Concise, clear communication saves everyone time and reduces misinterpretation.
We have to be careful not to burn out David here with too much controversy as when that happens, no one will be here to pick up this topic and there won't be any CoC at all.
This is a very poor excuse to move forward with a substandard document. If only one person in a team of dozens sees this as important enough to work on, perhaps it is not important.
Allan
On 2021-10-08 09:44:56 (+1000), Allan McRae via arch-dev-public wrote:
On 7/10/21 1:41 am, Sven-Hendrik Haase via arch-dev-public wrote:
On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Note that visiting the above link to make a comment would require agreeing to the Terms of Service, which includes the document under discussion.
FTR: This has been the case and *is* the case for the wiki, the forums, the mailing list and the IRC.
However, the RFC process does allow discussion external to the merge request, so people should feel free to respond elsewhere.
It does allow that, but we are now in the "Final Comment Period" [1] and not in the discussion period [2] anymore. Therefore it would be nice to not fragment discussion, by doing it on this mailing list, where only a subset of the staff can interact with it.
I do not think Arch should formally adopt *this* code of conduct.
That is your right and we may disagree on that.
You appear to generally be agreeing to the overall do's and don'ts (as your MR's [0] overall points are about the same). I therefore would like to implore you to roll with this version for now and then improve upon it as a direct follow up.
I support what Sven wrote.
Please improve upon your existing merge request for the Code of Conduct [4]. It has been open for two months, with no further work done on it, although there have been questions raised.
I generally don't like bringing up any "could have"'s and "should have"'s; however, your MR precedes the RFC and could have been the "current version".
Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful.
This form of communication is very ineffective and draining and I urge you to stop doing that.
Best, David
[1] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/9bfa7561a500a2d4e527b376b... [2] https://gitlab.archlinux.org/archlinux/rfcs/-/blob/9bfa7561a500a2d4e527b376b... [3] https://gitlab.archlinux.org/archlinux/service-agreements [4] https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/1...
On 8/10/21 6:01 pm, David Runge wrote:
On 2021-10-08 09:44:56 (+1000), Allan McRae via arch-dev-public wrote:
On 7/10/21 1:41 am, Sven-Hendrik Haase via arch-dev-public wrote:
On 06.10.21 12:47, Allan McRae via arch-dev-public wrote:
On 27/9/21 4:33 am, David Runge via arch-dev-public wrote:
An RFC has now entered Final Comment Period. In 14 days, discussion will end and the proposal will either be accepted, rejected or withdrawn:
https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/6
Please visit the above link for discussion.
Note that visiting the above link to make a comment would require agreeing to the Terms of Service, which includes the document under discussion.
FTR: This has been the case and *is* the case for the wiki, the forums, the mailing list and the IRC.
I'm fairly sure I did not have to formally agree to that document when I joined the forum, wiki, mailing list, etc, as it was several years before the Code of Conduct was written. At no point since then have I been required to formally agree to this document (except currently logging into gitlab), particularly given the distribution has not formally adopted the CoC. Hence this RFC.
However, the RFC process does allow discussion external to the merge request, so people should feel free to respond elsewhere.
It does allow that, but we are now in the "Final Comment Period" [1] and not in the discussion period [2] anymore. Therefore it would be nice to not fragment discussion, by doing it on this mailing list, where only a subset of the staff can interact with it.
If you can set my account to be able to log into github without agreeing to the document I disagree with, then I will move my discussion to where you request.
I am concerned that having already established I would not agree to the terms while logging into gitlab, that you suggest that gitlab should be the only place to discuss these terms. I will assume you are not trying to stifle an objection to your proposal, but rather did not consider the impression given by your request.
Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful.
You started the RFC as I went on holiday and closed it before I was back. It was open for 9 days. This is why there is a two week post discussion period built into the RFC process to ensure there is adequate time for everyone to comment. I would consider that suspicious timing, but I will assume good faith here and put it down to coincidence.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to.
Additionally, accusing me of being condescending and disrespectful in your first reply to this thread shows a complete lack of good faith in your approach to these discussions, and breaches the Respect section of your proposed Code of Conduct. This is also not the first time you have responded in such a way to disagreement with your opinions. I expect you to hold yourself to a higher standard.
This form of communication is very ineffective and draining and I urge you to stop doing that.
No. I will not stop advocating for changes to improve the distribution. Or equally stating objections to adopting changes that reflect poorly on the distribution.
And I believe adopting the Code of Conduct in its current form reflects poorly on the distribution.
Allan
On Fri, Oct 08, 2021 at 07:24:58PM +1000, Allan McRae via arch-dev-public wrote:
On 8/10/21 6:01 pm, David Runge wrote:
Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to.
I'm not sure why you stopped reading after that part. The next section specifies that it's a living document and changes can be merged going forward.
"The Code of Conduct is a living document that may change over time. Changes are applied by merge request towards the `Service Agreements repository https://gitlab.archlinux.org/archlinux/service-agreements/`_. Any contributions follow the repository's contribution guidelines."
Which should satisfy your current problem with the document as-is. We can amend and fix it at a later point regardless. Your current issues with the document isn't a good enough reason to block this process, and we can work it out at a later point.
Hi Allan,
Too many things are being touched on here, and it's become a stagnant discussion where little progress has been made.
Firstly, you are correct that the current GitLab login requires you to accept the CoC. In an attempt to remedy this situation, given the current software constraints and the risk of being seen as condescending (although that is not my intention), let's try the following. I've gone ahead and downloaded a copy of the latest-to-date version of the CoC RFC and the CoC documents and attached them to this email. I'm sure you are aware that you should be able to prepare specific comments and then use `git format-patch` to sign any patch you wish applied, then submit them over email. The patches could later be applied with your signature to the git repo. All of which can be done without interacting with GitLab. I do not believe there are any other relevant outstanding technological hurdles in your way at the moment. Thus, ensuring that no one is trying to stifle any objections to anyone's proposal.
As for the lengths of some CoC sections you disagree with, I believe the above method will suffice in proposing their amendment in detail.
Please, keep in mind that the CoC RFC is not about amending the current CoC but towards its distribution-wide adoption. That simply means that the new and amended version after your MR is the one that is going to be enforced distribution-wide.
Note the currently proposed Code of Conduct would directly violate the CoC from my MR that contains the following:
Use concise and clear language
The current CoC RFC only links to the current CoC document and adopts it across the distribution. In no way can this be considered that the current CoC is violating any potential future version of itself. Nor can it be interpreted that the current CoC RFC is somehow preventing future amendments to the CoC.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to.
Furthermore, having the sentence "is hereby officially adopted in its current form" in the RFC means that when the RFC is merged, that would be the act of adopting it. It does not make it impossible to amend the CoC document itself. Nor does it prevent other documents from superseding it at a later date. It could just as easily be updated in place, replaced or retired by a follow-up RFC. I think that's the whole point of RFCs.
To me, this completely resolves the situation by arriving at the same outcome that you desire but perhaps not in the chronological order you intend. I do feel that the chronological order is of little importance to the end goal of having a distribution-wide CoC.
However, I do fully believe the CoC can be improved upon. But I do not think filibustering its adoption will accomplish that. We have to start somewhere. I think a lot of people share the opinion that this RFC CoC is the place to start. And the act of adopting distribution wide it will also stimulate more people into making it better.
Finally, and I would really like to avoid a quarrel over this, about your last argument:> If only one person in a team of dozens sees this as important enough to
work on, perhaps it is not important.
I'm sure you know better than most that Arch Linux comprises a relatively small set of people working on multiple projects each. Statistically, that would leave many people being the only person working on any one thing. I'd hate to learn that you are of the opinion that such work is not important. I'd assume you meant something else. That is, of course, not mentioning the self-defeating nature of that argument, given you are, to my knowledge, the only person working at the moment to prevent the RFC in question from being adopted.
I'd like to say, and I'm sure many will agree, that yours and David's work is truly important and the number of people doing it should not diminish it.
In this light, I hope we can come to a compromise that would get things moving again in a constructive direction towards us having a distribution-wide CoC.
On 8/10/21 9:31 pm, Morten Linderud via arch-dev-public wrote:
On Fri, Oct 08, 2021 at 07:24:58PM +1000, Allan McRae via arch-dev-public wrote:
On 8/10/21 6:01 pm, David Runge wrote:
Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to.
I'm not sure why you stopped reading after that part. The next section specifies that it's a living document and changes can be merged going forward.
"The Code of Conduct is a living document that may change over time. Changes are applied by merge request towards the `Service Agreements repository <https://gitlab.archlinux.org/archlinux/service-agreements/>`_. Any contributions follow the repository's contribution guidelines."Which should satisfy your current problem with the document as-is. We can amend and fix it at a later point regardless. Your current issues with the document isn't a good enough reason to block this process, and we can work it out at a later point.
That would apply if I thought the current version was good enough for formal adoption. However, I think the current version is unacceptable.
A
On 8/10/21 9:39 pm, Konstantin Gizdov via arch-dev-public wrote:
Firstly, you are correct that the current GitLab login requires you to accept the CoC. In an attempt to remedy this situation, given the current software constraints and the risk of being seen as condescending (although that is not my intention), let's try the following. I've gone ahead and downloaded a copy of the latest-to-date version of the CoC RFC and the CoC documents and attached them to this email. I'm sure you are aware that you should be able to prepare specific comments and then use `git format-patch` to sign any patch you wish applied, then submit them over email. The patches could later be applied with your signature to the git repo. All of which can be done without interacting with GitLab. I do not believe there are any other relevant outstanding technological hurdles in your way at the moment. Thus, ensuring that no one is trying to stifle any objections to anyone's proposal.
Thanks for providing the files. I have no need to change any of the RFC - the RFC text would be fine if the Code of Conduct document was suitable. If a suitable version of the CoC was adopted, we would need to adjust the RFC to point at that version.
Also, I had already provided suggested CoC changes in the following merge request - it remained unfinished while I released pacman-6.0.1:
https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/1...
Note that I am presently objecting to the current CoC, not championing a specific alternative. I also was sent a patch today with the verbosity of the CoC greatly reduced, but keeping the structure mostly the same. I can provide that to the list if you wish. The change needed further work but that overall approach would also be acceptable.
<snip>
To me, this completely resolves the situation by arriving at the same outcome that you desire but perhaps not in the chronological order you intend. I do feel that the chronological order is of little importance to the end goal of having a distribution-wide CoC.
That assumes I consider the "current" CoC as acceptable for distribution wide adoption. I find the current version unacceptable, and thus the chronological order does matter.
<snip>
I'm sure you know better than most that Arch Linux comprises a relatively small set of people working on multiple projects each. Statistically, that would leave many people being the only person working on any one thing. I'd hate to learn that you are of the opinion that such work is not important. I'd assume you meant something else.
I did mean something else - the context of the reply is important. My statement was in response to the comment that if the current person spearheading the change stopped, then "no one will be here to pick up this topic". That would be a measure of its importance, but I also suspect to be an exaggeration in an attempt to push agreement.
Allan
On Fri, Oct 08, 2021 at 09:40:24PM +1000, Allan McRae via arch-dev-public wrote:
On 8/10/21 9:31 pm, Morten Linderud via arch-dev-public wrote:
On Fri, Oct 08, 2021 at 07:24:58PM +1000, Allan McRae via arch-dev-public wrote:
On 8/10/21 6:01 pm, David Runge wrote:
Starting a discussion about the length and form of the Code of Conduct *after* not interacting with the own changes to the Code of Conduct that would fix it, *after* not interacting with the RFC that wants to establish the CoC distribution-wide during its comment period and also *after* not interacting with the changes that were done last to the CoC (which in fact you gave the initial idea for and were informed about its progress multiple times) by Jonas and I, but instead complained about *after the fact*, to me, quite frankly at this point feels nothing short of condescending and disrespectful.
The RFC does not give the option of an edited version of the Code of Conduct being adopted. The RFC states that the Code of Conduct "is hereby officially adopted in its current form". Hence the RFC is about adopting the *current* version of the Code of Conduct, which I object to.
I'm not sure why you stopped reading after that part. The next section specifies that it's a living document and changes can be merged going forward.
"The Code of Conduct is a living document that may change over time. Changes are applied by merge request towards the `Service Agreements repository <https://gitlab.archlinux.org/archlinux/service-agreements/>`_. Any contributions follow the repository's contribution guidelines."Which should satisfy your current problem with the document as-is. We can amend and fix it at a later point regardless. Your current issues with the document isn't a good enough reason to block this process, and we can work it out at a later point.
That would apply if I thought the current version was good enough for formal adoption. However, I think the current version is unacceptable.
You still have your open Merge Request you can work on after this RFC has been accepted. Or do you want us to pause this RFC until your rewrite is complete? Do you have any expectations when you will have more time to work on it?
On 08/10/2021 15:33, Allan McRae via arch-dev-public wrote:
On 8/10/21 9:39 pm, Konstantin Gizdov via arch-dev-public wrote:
Firstly, you are correct that the current GitLab login requires you to accept the CoC. In an attempt to remedy this situation, given the current software constraints and the risk of being seen as condescending (although that is not my intention), let's try the following. I've gone ahead and downloaded a copy of the latest-to-date version of the CoC RFC and the CoC documents and attached them to this email. I'm sure you are aware that you should be able to prepare specific comments and then use `git format-patch` to sign any patch you wish applied, then submit them over email. The patches could later be applied with your signature to the git repo. All of which can be done without interacting with GitLab. I do not believe there are any other relevant outstanding technological hurdles in your way at the moment. Thus, ensuring that no one is trying to stifle any objections to anyone's proposal.
Thanks for providing the files. I have no need to change any of the RFC
- the RFC text would be fine if the Code of Conduct document was
suitable. If a suitable version of the CoC was adopted, we would need to adjust the RFC to point at that version.
Would it suffice if the RFC was changed to point at a specific branch, let's say "current" and then whatever CoC is later located at the top of that branch would be the one the RFC is pointing to, hence enforced?
Also, I had already provided suggested CoC changes in the following merge request - it remained unfinished while I released pacman-6.0.1:
https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/1...
Note that I am presently objecting to the current CoC, not championing a specific alternative. I also was sent a patch today with the verbosity of the CoC greatly reduced, but keeping the structure mostly the same. I can provide that to the list if you wish. The change needed further work but that overall approach would also be acceptable.
I don't mind how you submit the patch. It was purely suggested as a way to mitigate a tech hurdle you pointed out. You are free to submit it as you wish.
However, your line of reasoning above looks somewhat unfair to everyone else. Yes, there are many if's and would've-been's, but we are here and we are discussing the adoption of a distribution-wide CoC. It could later be updated and improved as needed and that is not in the debate. But the act of adopting a CoC is separate and that is at stake. Otherwise, your attempt at blocking its adoption because you don't like the CoC, even though it is mostly in force in several places already, looks like filibustering this specific RFC.
<snip>
To me, this completely resolves the situation by arriving at the same outcome that you desire but perhaps not in the chronological order you intend. I do feel that the chronological order is of little importance to the end goal of having a distribution-wide CoC.
That assumes I consider the "current" CoC as acceptable for distribution wide adoption. I find the current version unacceptable, and thus the chronological order does matter.
No, it does not assume that at all. In fact, it specifically excluded your agreement with the CoC itself at the moment. It only included the possibility of updating it afterwards.
<snip>
I'm sure you know better than most that Arch Linux comprises a relatively small set of people working on multiple projects each. Statistically, that would leave many people being the only person working on any one thing. I'd hate to learn that you are of the opinion that such work is not important. I'd assume you meant something else.
I did mean something else - the context of the reply is important. My statement was in response to the comment that if the current person spearheading the change stopped, then "no one will be here to pick up this topic". That would be a measure of its importance, but I also suspect to be an exaggeration in an attempt to push agreement.
That changes nothing. As already said, we do not have infinite supply of people to supplement someone deliberately exhausting them. And I don't think we should be suggesting to everyone that anyone is allowed to simply go through as many people as they like just to get their way. Each of us is here because we are willing to do this. That is a precious resource and should not be handled so carelessly, I would think.
Allan
On 9/10/21 7:17 pm, Konstantin Gizdov via arch-dev-public wrote:
<snip>
Would it suffice if the RFC was changed to point at a specific branch, let's say "current" and then whatever CoC is later located at the top of that branch would be the one the RFC is pointing to, hence enforced?
No. That would make little difference, because as soon as the RFC is accepted, the version of the CoC I find to be of an unacceptable standard would be adopted.
If the RFC was changed to "Arch will adopt a CoC to be determined at a later date", with details of how the final CoC would be decided, that would be acceptable (though rather pointless I think). Or if the CoC was improved before accepting the current RFC, that would also be acceptable.
However, your line of reasoning above looks somewhat unfair to everyone else. Yes, there are many if's and would've-been's, but we are here and we are discussing the adoption of a distribution-wide CoC. It could later be updated and improved as needed and that is not in the debate. But the act of adopting a CoC is separate and that is at stake. Otherwise, your attempt at blocking its adoption because you don't like the CoC, even though it is mostly in force in several places already, looks like filibustering this specific RFC.
The code of conduct can be updated later. But I consider it unacceptable now.
Adopting substandard policy for the sake of adopting policy swiftly is not a consideration I am willing to entertain. I do not want Arch to adopt a substandard policy document, hence my objection.
To me, this completely resolves the situation by arriving at the same outcome that you desire but perhaps not in the chronological order you intend. I do feel that the chronological order is of little importance to the end goal of having a distribution-wide CoC.
That assumes I consider the "current" CoC as acceptable for distribution wide adoption. I find the current version unacceptable, and thus the chronological order does matter.
No, it does not assume that at all. In fact, it specifically excluded your agreement with the CoC itself at the moment. It only included the possibility of updating it afterwards.
Again, if the RFC is accepted, Arch adopts the CoC at the defined commit. I do not think that version should be adopted because it is substandard. Just because you can improve something later, does not make it acceptable now.
You don't release a prototype with many issues just because you want to release something with the hope it may get improved in the future. You wait until the prototype is of an acceptable standard for release.
I want to adopt a distribution wide Code of Conduct, but am objecting to moving forward with one I consider unacceptable.
<snip>
That changes nothing. As already said, we do not have infinite supply of people to supplement someone deliberately exhausting them. And I don't think we should be suggesting to everyone that anyone is allowed to simply go through as many people as they like just to get their way. Each of us is here because we are willing to do this. That is a precious resource and should not be handled so carelessly, I would think.
I am not deliberately exhausting a person. My comments have been purely about the RFC and would be the same regardless of who proposed it. I am objecting to a change that I consider of an unacceptably low standard. As I would for any change I felt was of a similar standard.
I also expect my work to be held to a similar standard, and it was in a previous RFC (that RFC was withdrawn until it could be reworked into an acceptable form).
If holding work on Arch Linux to an acceptable standard is now considered detrimental, the distribution has far greater issues.
Allan
On 8/10/21 10:44 pm, Morten Linderud via arch-dev-public wrote:
On Fri, Oct 08, 2021 at 09:40:24PM +1000, Allan McRae via arch-dev-public wrote:
On 8/10/21 9:31 pm, Morten Linderud via arch-dev-public wrote:
Which should satisfy your current problem with the document as-is. We can amend and fix it at a later point regardless. Your current issues with the document isn't a good enough reason to block this process, and we can work it out at a later point.
That would apply if I thought the current version was good enough for formal adoption. However, I think the current version is unacceptable.
You still have your open Merge Request you can work on after this RFC has been accepted. Or do you want us to pause this RFC until your rewrite is complete? Do you have any expectations when you will have more time to work on it?
I am objecting to this RFC being accepted, as that would mean adopting a CoC I consider substandard to the point of being unacceptable. The ability to update it after does not change this situation.
If it is agreed that an edited CoC is needed for this RFC to be accepted, I can prioritise finishing my suggested edit, or equally help edit any other proposed variant.
Again, I'll note that my objection to this RFC is not tied to my specific submission. It is tied to the current version of the CoC being unacceptable. My edit may be considered equally unacceptable for adoption.
Allan
On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote:
I am objecting to this RFC being accepted, as that would mean adopting a CoC I consider substandard to the point of being unacceptable. The ability to update it after does not change this situation.
as far as I know the current version of CoC has been applied to other parts of the distribution for a long time. this rfc only makes this application visible and official.
thus, I think that the correct option is to separate the concept of consent to the use of CoC and the text of the CoC itself.
If it is agreed that an edited CoC is needed for this RFC to be accepted, I can prioritise finishing my suggested edit, or equally help edit any other proposed variant.
the problem is that I and, as far as I understand, other people participating in this thread see no problem with changing the text of CoC after the adoption of this RFC which just makes CoC an official part of our community, and also clearly describes how to change CoC's text.
Again, I'll note that my objection to this RFC is not tied to my specific submission. It is tied to the current version of the CoC being unacceptable. My edit may be considered equally unacceptable for adoption.
to be honest, I absolutely cannot understand why you think CoC is unacceptable. in my opinion, the problems with the size of the text and with its depth do not deserve such a low rating.
also, if it helps, I and a few other friends of mine, whose English is not so good, read the current version of CoC and did not find any problems with understanding it's text.
Allan
-- Sincerely, Alexander | Trusted User
On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote:
On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote:
I am objecting to this RFC being accepted, as that would mean adopting a CoC I consider substandard to the point of being unacceptable. The ability to update it after does not change this situation.
as far as I know the current version of CoC has been applied to other parts of the distribution for a long time. this rfc only makes this application visible and official.
I do not consider "it has been used elsewhere" a justifiable reason to officially adopt a policy document. If the document can not stand on its own merits, it should not be adopted.
thus, I think that the correct option is to separate the concept of consent to the use of CoC and the text of the CoC itself.
The RFC does not separate these. The RFC specifically states what CoC will be adopted on acceptance. The proposed CoC text is explicitly tied to the RFC. Hence my objection.
If it is agreed that an edited CoC is needed for this RFC to be accepted, I can prioritise finishing my suggested edit, or equally help edit any other proposed variant.
the problem is that I and, as far as I understand, other people participating in this thread see no problem with changing the text of CoC after the adoption of this RFC which just makes CoC an official part of our community, and also clearly describes how to change CoC's text.
As far as I can tell, no-one has disagreed that the CoC needs improved. But as you say, responses so far indicate that several team members are willing to accept a policy document even if it needs fixing. I believe the changes needed are so large that I am unwilling to accept adopting the current document.
Again, I'll note that my objection to this RFC is not tied to my specific submission. It is tied to the current version of the CoC being unacceptable. My edit may be considered equally unacceptable for adoption.
to be honest, I absolutely cannot understand why you think CoC is unacceptable. in my opinion, the problems with the size of the text and with its depth do not deserve such a low rating.
also, if it helps, I and a few other friends of mine, whose English is not so good, read the current version of CoC and did not find any problems with understanding it's text.
I am a scientist, so like to rely on actual measurements rather than anecdotes.
http://www.roadtogrammar.com/ CEFR Level: CEF Level C2 (highest category)
https://readabilityformulas.com/ Flesch Reading Ease scored your text: difficult to read. Gunning Fog scored your text: difficult to read.
I'm glad your friend's English ability is higher than they (you?) think it is.
Allan
On 09/10/2021 16:15, Allan McRae via arch-dev-public wrote:
On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote:
On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote:
I am objecting to this RFC being accepted, as that would mean adopting a CoC I consider substandard to the point of being unacceptable. The ability to update it after does not change this situation.
as far as I know the current version of CoC has been applied to other parts of the distribution for a long time. this rfc only makes this application visible and official.
I do not consider "it has been used elsewhere" a justifiable reason to officially adopt a policy document. If the document can not stand on its own merits, it should not be adopted.
I have not seen anyone else agreeing with you on the point that the document cannot stand on its own merits. Correct me if I'm wrong. (more on this point at the bottom of my email)
thus, I think that the correct option is to separate the concept of consent to the use of CoC and the text of the CoC itself.
The RFC does not separate these. The RFC specifically states what CoC will be adopted on acceptance. The proposed CoC text is explicitly tied to the RFC. Hence my objection.
Correct. And this is why we've all taken to heart your input and arguments, and tried to accommodate you with reasonable and actionable compromises. You've refused all of them.
If it is agreed that an edited CoC is needed for this RFC to be accepted, I can prioritise finishing my suggested edit, or equally help edit any other proposed variant.
the problem is that I and, as far as I understand, other people participating in this thread see no problem with changing the text of CoC after the adoption of this RFC which just makes CoC an official part of our community, and also clearly describes how to change CoC's text.
As far as I can tell, no-one has disagreed that the CoC needs improved. But as you say, responses so far indicate that several team members are willing to accept a policy document even if it needs fixing. I believe the changes needed are so large that I am unwilling to accept adopting the current document.
That is not correct. No-one has agreed that the CoC *needs* to be improved before this RFC is accepted. Even further. Some of us have only agreed that it could potentially be improved, but not that it definitely should or needs to. Furthermore, I do not think we all agree with the direction of that potential improvement either. Nothing is stopping anyone from making any large or small changes to the CoC document.
Again, I'll note that my objection to this RFC is not tied to my specific submission. It is tied to the current version of the CoC being unacceptable. My edit may be considered equally unacceptable for adoption.
to be honest, I absolutely cannot understand why you think CoC is unacceptable. in my opinion, the problems with the size of the text and with its depth do not deserve such a low rating.
also, if it helps, I and a few other friends of mine, whose English is not so good, read the current version of CoC and did not find any problems with understanding it's text.
I am a scientist, so like to rely on actual measurements rather than anecdotes.
I am a scientist too. So what?! I really would rather not have this sort of debate where we start to claim who we are instead of argue the points.
http://www.roadtogrammar.com/ CEFR Level: CEF Level C2 (highest category)
https://readabilityformulas.com/ Flesch Reading Ease scored your text: difficult to read. Gunning Fog scored your text: difficult to read.
I'm glad your friend's English ability is higher than they (you?) think it is.
You are judging the whole value, quality and perception of a document based on a single number computed by a formula. This is not scientific. It is actually frowned upon in science to reduce a whole bunch of metrics to a single number.
So let's give some more context to this. Yes, the Flesch readability score of the current CoC is about 38 +/- 3 depending on your choice of provider. That puts it at grade-12 or first-year-college reading level. However, the overall quality of the text in terms of its use of correct terms, value to reader and being informative is much higher. One such metric is the Grammarly quality score [1], based on multiple metrics (word count, number of unique words, number of rare words, number of sentences, avg. length of sentences, avg. reading time, avg. speaking time, etc.). On top of that, the Grammarly score is more broadly applicable because it is context aware due to using the latest in NLP [2] techniques able to pick up on meaning, direction, focus, clarity and more. The score puts the text at 84/100. Which is pretty good. Does that make me win the argument? No, it does not. Because again it's a single number. I can imaging this sort of thing can go on for very long, where each of us proposes our favourite test to prove our point. That's not going to solve any issues though.
This argument, as it is proposed, is pointless to the RFC in question because the CoC will never be perfect. Even if we get a higher score on readability and achieve 100/100 on some other scoring function, the CoC document would still be subject of improvement. Even then, we could just as easily change "our/the standard" and not be satisfied again. None of these metrics check how the CoC reflects on what we wish to say. No metrics can.
We are trying to create a policy document. The CoC is sufficient when it comes to doing its job of explaining the general and some specific points related to the way people should conduct themselves on our platform. I think most of us agree on that. However, in order to serve any such purpose, it needs to first be adopted and not endlessly delayed because it is perhaps too long or is not 5-grade-level readable.
The latter are not the main metrics we are optimising. Nor have we set any sort of standard for them, nor have we even agreed on the metrics we should use when judging such texts in the first place.
Allan
Resending PGP signed.
On 09/10/2021 16:15, Allan McRae via arch-dev-public wrote:
On 9/10/21 10:07 pm, Alexander Epaneshnikov wrote:
On Sat, Oct 09, 2021 at 09:17:05PM +1000, Allan McRae via arch-dev-public wrote:
I am objecting to this RFC being accepted, as that would mean adopting a CoC I consider substandard to the point of being unacceptable. The ability to update it after does not change this situation.
as far as I know the current version of CoC has been applied to other parts of the distribution for a long time. this rfc only makes this application visible and official.
I do not consider "it has been used elsewhere" a justifiable reason to officially adopt a policy document. If the document can not stand on its own merits, it should not be adopted.
I have not seen anyone else agreeing with you on the point that the document cannot stand on its own merits. Correct me if I'm wrong. (more on this point at the bottom of my email)
thus, I think that the correct option is to separate the concept of consent to the use of CoC and the text of the CoC itself.
The RFC does not separate these. The RFC specifically states what CoC will be adopted on acceptance. The proposed CoC text is explicitly tied to the RFC. Hence my objection.
Correct. And this is why we've all taken to heart your input and arguments, and tried to accommodate you with reasonable and actionable compromises. You've refused all of them.
If it is agreed that an edited CoC is needed for this RFC to be accepted, I can prioritise finishing my suggested edit, or equally help edit any other proposed variant.
the problem is that I and, as far as I understand, other people participating in this thread see no problem with changing the text of CoC after the adoption of this RFC which just makes CoC an official part of our community, and also clearly describes how to change CoC's text.
As far as I can tell, no-one has disagreed that the CoC needs improved. But as you say, responses so far indicate that several team members are willing to accept a policy document even if it needs fixing. I believe the changes needed are so large that I am unwilling to accept adopting the current document.
That is not correct. No-one has agreed that the CoC *needs* to be improved before this RFC is accepted. Even further. Some of us have only agreed that it could potentially be improved, but not that it definitely should or needs to. Furthermore, I do not think we all agree with the direction of that potential improvement either. Nothing is stopping anyone from making any large or small changes to the CoC document.
Again, I'll note that my objection to this RFC is not tied to my specific submission. It is tied to the current version of the CoC being unacceptable. My edit may be considered equally unacceptable for adoption.
to be honest, I absolutely cannot understand why you think CoC is unacceptable. in my opinion, the problems with the size of the text and with its depth do not deserve such a low rating.
also, if it helps, I and a few other friends of mine, whose English is not so good, read the current version of CoC and did not find any problems with understanding it's text.
I am a scientist, so like to rely on actual measurements rather than anecdotes.
I am a scientist too. So what?! I really would rather not have this sort of debate where we start to claim who we are instead of argue the points.
http://www.roadtogrammar.com/ CEFR Level: CEF Level C2 (highest category)
https://readabilityformulas.com/ Flesch Reading Ease scored your text: difficult to read. Gunning Fog scored your text: difficult to read.
I'm glad your friend's English ability is higher than they (you?) think it is.
You are judging the whole value, quality and perception of a document based on a single number computed by a formula. This is not scientific. It is actually frowned upon in science to reduce a whole bunch of metrics to a single number.
So let's give some more context to this. Yes, the Flesch readability score of the current CoC is about 38 +/- 3 depending on your choice of provider. That puts it at grade-12 or first-year-college reading level. However, the overall quality of the text in terms of its use of correct terms, value to reader and being informative is much higher. One such metric is the Grammarly quality score [1], based on multiple metrics (word count, number of unique words, number of rare words, number of sentences, avg. length of sentences, avg. reading time, avg. speaking time, etc.). On top of that, the Grammarly score is more broadly applicable because it is context aware due to using the latest in NLP [2] techniques able to pick up on meaning, direction, focus, clarity and more. The score puts the text at 84/100. Which is pretty good. Does that make me win the argument? No, it does not. Because again it's a single number. I can imaging this sort of thing can go on for very long, where each of us proposes our favourite test to prove our point. That's not going to solve any issues though.
This argument, as it is proposed, is pointless to the RFC in question because the CoC will never be perfect. Even if we get a higher score on readability and achieve 100/100 on some other scoring function, the CoC document would still be subject of improvement. Even then, we could just as easily change "our/the standard" and not be satisfied again. None of these metrics check how the CoC reflects on what we wish to say. No metrics can.
We are trying to create a policy document. The CoC is sufficient when it comes to doing its job of explaining the general and some specific points related to the way people should conduct themselves on our platform. I think most of us agree on that. However, in order to serve any such purpose, it needs to first be adopted and not endlessly delayed because it is perhaps too long or is not 5-grade-level readable.
The latter are not the main metrics we are optimising. Nor have we set any sort of standard for them, nor have we even agreed on the metrics we should use when judging such texts in the first place.
Allan
I had a long reply to the Konstantin's comments, but I deleted it. I find the email repeatedly takes statements out of context, or states I have made claims I clearly have not, and uses this to draw unsubstantiated conclusions. This makes it difficult to reply in a manner I consider fitting for interactions in this distribution. However, if responses to individual points are particularly wanted, I hereby offer to provide them on request.
Instead of replying to the email I will summarise my position in a clear concise manner, and will likely not reply further to this thread unless directly requested to. *Do not take the lack of further replies as agreement.*
My stance on the RFC is: - We need a Code of Conduct (CoC), and I agree with the entire RFC except the link to the commit with the proposed CoC. - I contend the proposed CoC is overly long, particularly in the description of each of the offenses, to the point where I find it condescending and not showing respect to the community of a technical Linux distribution. - The writing in various sections of the proposed CoC is overly complex, and the understanding of the expectations would be enhanced by fixing this. - The document is also poorly organised. - Overall, I think the current CoC is below the standard that has been historically set for official contributions to Arch Linux and would be a poor reflection on the distribution if officially adopted. - The RFC should not be adopted until an improved CoC is included.
I do recognise the arguments made to accepting the CoC as is, then making changes in the future. However, I will add one further comment based on Konstantin's reply:
Some of us have only agreed that it could potentially be improved, but not that it definitely should or needs to. Furthermore, I do not think we all agree with the direction of that potential improvement either.
This statement indicates the ability to change the CoC after acceptance of the RFC is no guarantee that we will not be stuck with the current CoC. This represents the clearest reason not to take a compromise and accept what I consider a substandard document.
Allan
On 10/10/2021 17:47, Allan McRae via arch-dev-public wrote:
I had a long reply to the Konstantin's comments, but I deleted it. I find the email repeatedly takes statements out of context, or states I have made claims I clearly have not, and uses this to draw unsubstantiated conclusions. This makes it difficult to reply in a manner I consider fitting for interactions in this distribution. However, if responses to individual points are particularly wanted, I hereby offer to provide them on request.
Instead of replying to the email I will summarise my position in a clear concise manner, and will likely not reply further to this thread unless directly requested to. *Do not take the lack of further replies as agreement.*
My stance on the RFC is:
- We need a Code of Conduct (CoC), and I agree with the entire RFC
except the link to the commit with the proposed CoC.
You were given the option to amend this link and you blatantly refused it. *mark*
- I contend the proposed CoC is overly long, particularly in the
description of each of the offenses, to the point where I find it condescending and not showing respect to the community of a technical Linux distribution.
That is your opinion and we welcome it. However, part of the respect a lot of our users and staff deserve is a document to lean against to protect them and allow them to work more effectively.
- The writing in various sections of the proposed CoC is overly
complex, and the understanding of the expectations would be enhanced by fixing this.
It is complex to a 12-grade or 1st year undergraduate level as previously discussed. This is fine, given above you talk about a "community of a technical Linux distribution". We, as a distribution, advertise on most our welcoming pages exactly the expected capabilities of an Arch Linux user. Those expectation are quite high: "The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems." [1]
- The document is also poorly organised.
That's the first I hear about it.
- Overall, I think the current CoC is below the standard that has been
historically set for official contributions to Arch Linux and would be a poor reflection on the distribution if officially adopted.
I think a poorer reflection on the official image of Arch Linux is not having an official CoC of any kind. And when it comes to CoC standards in Arch Linux, we currently have none. We are attempting to correct this.
- The RFC should not be adopted until an improved CoC is included.
I believe it has been made clear that most of us do not agree with that point. And you've also refused to amend the link as discussed. (Refer to *mark*)
I do recognise the arguments made to accepting the CoC as is, then making changes in the future. However, I will add one further comment based on Konstantin's reply:
Some of us have only agreed that it could potentially be improved, but not that it definitely should or needs to. Furthermore, I do not think we all agree with the direction of that potential improvement either.
This statement indicates the ability to change the CoC after acceptance of the RFC is no guarantee that we will not be stuck with the current CoC. This represents the clearest reason not to take a compromise and accept what I consider a substandard document.
Nothing is guaranteed, such is life (c'est la vie). There is no guarantee that a fringe asteroid won't destroy the Earth 5 minute from now. But blank statements like that tell us nothing about the likelihood of such an event of actually happening.
I think we've all made it clear that the CoC will be looked at again and again. The CoC is specified explicitly as a fluid document that will continue to improve and adjust for the better. This is everyone's intention. This has been pointed out several times. I'd say the likelihood of improving the CoC in the future is completely reasonable. Furthermore, I believe you are quite invested in that too. So I am not worried that it will get done.
Allan
On 10/10/21 16:47, Allan McRae via arch-dev-public wrote:
- Overall, I think the current CoC is below the standard that has been
historically set for official contributions to Arch Linux and would be a poor reflection on the distribution if officially adopted.
- The RFC should not be adopted until an improved CoC is included.
I do recognise the arguments made to accepting the CoC as is, then making changes in the future. However, I will add one further comment based on Konstantin's reply:
Some of us have only agreed that it could potentially be improved, but not that it definitely should or needs to. Furthermore, I do not think we all agree with the direction of that potential improvement either.
This statement indicates the ability to change the CoC after acceptance of the RFC is no guarantee that we will not be stuck with the current CoC. This represents the clearest reason not to take a compromise and accept what I consider a substandard document.
I agree we should be mindful about what we accept and officially adopt but i strongly disagree the current version of the document is literally unacceptable.
We don't need to reach perfect before we can adopt anything at all in fear of not keeping up to our standards. Applying an evolutionary process to this part of our distro as well is fine, as long as we have a solid foundation. A lot of different areas of our distro that reached a top notch state and what we are known for are only this good because we "got shit done" and improve along the way. Our wiki evolved over time to one of the best (or actually the best) source for various Linux topics because pages have iteratively improved and not kept back until they were deemed irrefutably perfect. We also reached a top notch state in reproducible builds as well and today are ahead -- because we created a solid foundation and had the ability to adapt to new conditions and requirements quickly.
If we are concerned about how this may reflect on our distro, we should be a lot more concerned that we lose ourselves in details and are unable to adopt a CoC as a solid foundation mostly because of phrasing. This would frankly reflect a lot worse on our distro compared to adopting a contentwise solid document and accept future simplification proposals. Before this section may be picked out of context, I back-reference my first section here about requiring a mindful adoption: I strongly believe the current version is a good foundation that can be used to move forward without harming our reputation and standards as feared.
cheers, Levente
arch-dev-public@lists.archlinux.org