9 Oct
2021
9 Oct
'21
9:17 a.m.
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/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. 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 -- Regards, Konstantin