Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[David Runge via arch-dev-public]

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/9bfa7561a500a2d4e527b376bf6e2929276a9315/README.rst#L190-200
[2] 
https://gitlab.archlinux.org/archlinux/rfcs/-/blob/9bfa7561a500a2d4e527b376bf6e2929276a9315/README.rst#L151-156
[3] https://gitlab.archlinux.org/archlinux/service-agreements
[4] 
https://gitlab.archlinux.org/archlinux/service-agreements/-/merge_requests/14

-- 
https://sleepmap.de


signature.asc
Description: PGP signature

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Allan McRae via arch-dev-public]

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

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Morten Linderud via arch-dev-public]

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
`_. 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.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Konstantin Gizdov via arch-dev-public]

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.

-- 
Regards,
Konstantin



P.S.:
About the CoC itself, "concise" and "clear" are not synonyms and when it
comes to communication they are very hard to attain together lots of
times. In fact, it is precisely because Arch Linux reaches so many
people with different backgrounds and understanding of English around
the world that the balance between concise and clear is not so
straightforward to achieve. If we went the route of putting too much
emphasis on being concise, we would lose a lot of clarity as we would
depend on many different people understanding a tiny subset of terms and
their specific English connotations and interactions. So I think being a
bit more verbose will help more people actually truly understand the
core inten

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Allan McRae via arch-dev-public]

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
> `_. 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

[arch-dev-public] RFC: Rename the Trusted User role

[Konstantin Gizdov via arch-dev-public]

A new RFC (request for comment) has been opened here:

https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/7

Please visit the above link for discussion.

Summary:
It is shown in some cases that the Trusted User role naming leads to
some confusion and misunderstanding in broader contexts outside Arch
Linux. It is furthermore recently been discussed that it also led to
similar confusion among members of Arch Linux as well internally. This
RFC aims to remedy that with a better suited term to reflect more
accurately upon TUs' roles and responsibilities as well as their
position in the Arch Linux Organisation.

-- 
Regards,
Konstantin



OpenPGP_signature
Description: OpenPGP digital signature

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Allan McRae via arch-dev-public]

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/14

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.



> 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.



> 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

Re: [arch-dev-public] RFC Final Comment Period: Adoption of a distribution-wide Code of Conduct

[Morten Linderud via arch-dev-public]

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
> > `_. 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?

-- 
Morten Linderud
PGP: 9C02FF419FECBE16


signature.asc
Description: PGP signature