Code of Conduct or whatever

The most recent GitHub ban was technically public (I can give a world-viewable link to the statement by a person with org admin access that the ban occurred), but some people didn’t notice.

Well, actually, this is a good point to discuss @coretemp situation then.

From what I could find in my Maildir, it seems to have started with nix copy uses too much memory · Issue #1681 · NixOS/nix · GitHub by @coretemp, which, IMHO, is absolutely reasonable, I agree that closing an issue without any comment in response to a question is rude.

True, the question itself nix copy uses too much memory · Issue #1681 · NixOS/nix · GitHub was formulated a bit rudely, something like “ping” would have been enough, IMHO, but the way the issue was silently closed in response was also rude, IMHO.

This was then followed by nix copy uses too much memory · Issue #1681 · NixOS/nix · GitHub by @domenkozar, which I can totally read as “You want to know if and when this was fixed? Do the research yourself or pay someone to provide support, we are not required to do this for free.” Which is factually correct. But, well … I wouldn’t call this “nice” either.

Then, there was “Nix/Nixpkgs/NixOps maintenance plan” https://discourse.nixos.org/t/nix-nixpkgs-nixops-maintenance-plan/1204/1 (Message-ID: topic/1204@discourse.nixos.org) by @Coretemp which started with

All I see are good PRs that stay open for months. One of the reasons I don’t write patches is because there is a line of about 1000
PRs that need to be closed in all these projects combined.

The rest of the conversation was also pretty reasonable, IMHO (I, too, was frustrated by the slowness of Nixpkgs PR merged before, but then I changed my git workflow to make “many patchsets in the queue” scenario easier and added some automation, now things look better, but what to do with “hanging” not-quite-ready PR’s is a good question still, but that’s offtopic here). Then @domenkozar wrote

As someone who has been contributing to Nix for about 5 years, I have to say such posts only demotivate me and I have zero
motivation right now to help you out, sorry. I will say a few words about this post.

[…]

What I do not understand is how you think insulting people that have contributed thousands of hours is actually not the destruction
of human capital? The fact that registration was open for more than half a year and you blame organizers for your slow acting
(note, attendee limit was known from the day that conference was announced), shows much you really value self-criticism that you’re
asking us for.

The thing that I’m interested about is discussing at NixCon after reading this post is CoC and how we treat each other and set the
standards straight. Please consider this as my expression of frustration over such non-constructive posts and that I’m not OK with
them.

and then censored the whole thread by saying

I realize I also have violated the guidelines themselves, so as per FAQ - NixOS Discourse I suggest we lock/close
this thread as nothing good can come out of this.

I think this was an overreaction.

Which triggered “Censorship issues” https://discourse.nixos.org/t/censorship-issues/1218/1 (Message-ID: topic/1218@discourse.nixos.org) by @Coretemp, which, again, was censored…

I can totally see why @coretemp was frustrated by this point.

Then, there was commit access · Issue #50889 · NixOS/nixpkgs · GitHub which, again, should have been less charged, IMHO, but given the above censorship of thread that discussed governance I can understand where this was coming from.

Which was followed by commit access · Issue #50889 · NixOS/nixpkgs · GitHub. I have no idea why was this the “last warning” already, I seem to have no other in-between interactions between @coretemp and @domenkozar in my Maildir.

Which then triggered Threats from @domenkozar · Issue #51078 · NixOS/nixpkgs · GitHub with all that ensured.

Up to that issue @domenkozar was at least as much at fault as @coretemp. Actually, I think, more, because nix copy uses too much memory · Issue #1681 · NixOS/nix · GitHub is as much passive-aggressive as commit access · Issue #50889 · NixOS/nixpkgs · GitHub, and given the fact that @domenkozar censored @coretemp’s threads, and especially since @domenkozar had owner rights to NixOS org which he threatened to use against @coretemp out of the blue. “With great power comes great responsibility.”

True, Threats from @domenkozar · Issue #51078 · NixOS/nixpkgs · GitHub was an overreaction by @coretemp. But I can totally see why @coretemp thought he was bullied by @domenkozar by that point. What seems to be a permanent ban of @coretemp, IMHO, is, to say the least, is not fair. Especially given the fact that @coretemp was contributing A. Whole. Lot. before.

So, shouldn’t @coretemp by unbanned by now?

All in all, firstly, I’m very much displeased by the fact that this discourse is censored so much. Sure, Maildir saves everything, but the fact that I can’t link to those threads is concerning. Secondly, similarly I don’t like the fact that related GitHub issues are frequently permanently locked to committers only. This makes things hard to discuss before or just after everything blows up.

Thirdly, I hope everyone can see the urgent need for a separate system of appeals to fix overreactions like this as soon as possible in the future. @coretemp, as far as I can see, was banned both from GitHub org and this discourse. Where should have he made an appeal himself?

1 Like

Well, actually, this is a good point to discuss @coretemp situation then.

Keep in mind that by that time some people were already annoyed by repeated small things like https://github.com/NixOS/nixpkgs/issues/46915#issuecomment-423478057

All I see are good PRs that stay open for months. One of the reasons I don’t write patches is because there is a line of about 1000
PRs that need to be closed in all these projects combined.

The immediately adjacent sentences are a bit worse than these two. As I said, it was

From what I could find in my Maildir, it seems to have started with nix copy uses too much memory · Issue #1681 · NixOS/nix · GitHub by @coretemp, which, IMHO, is absolutely reasonable, I agree that closing an issue without any comment in response to a question is rude.

Especially given the fact that @coretemp was contributing A. Whole. Lot. before.

I have a suspicion, that both cases interact with an unrelated problem. As we sometimes have troubles reacting to PRs, let alone reacting to all the issues, issues are more or less considered «cheap». This means that not much bad is needed to make an issue be perceived as net-negative. And it is not universally felt as rude to close an issue silently if a fix has been indeed committed. Etc.

I am not sure if I perceive this correctly. I am also not sure whether, if this is true, we can have any plan on this. It might be useful to find out and recognise the current situation, though.

This makes things hard to discuss before or just after everything blows up.

Well, after things blow up, continuing it runs a high risk of making things even worse.

coretemp currently is not banned here. I believe they were suspended for about 3 days, and after that sent a couple direct messages to a Discourse admin that were personal attacks, so we suspended their account for 1 month. That suspension has been over for a while now.

This is why I usually don’t participate in mailing lists and discussion forums.

Apart from a few very reasonable comments in here: don’t you people have more productive things to do than to dissect the exact wording of some irrelevant issue/PR months ago?

Even these four lines felt long to write.

6 Likes

@Profpatsch Indeed, not reflecting on anything would be very convenient.

2 Likes

Hi everyone!

I hope the reason we are all here is to make nixos a great project. That’s my working assumption.

This thread was opened by asking to review the circumstances around the banning of one particular person, some time ago, in a different forum. The matter was answered directly. (Furthermore, there have been evolutions in this project to make these matters clearer and easier to understand, afaict.)

Then, unfortunately, this thread was derailed by insinuations and by attempts to forensically analyze past exchanges. As productive measures, these are doomed: The former by their very nature, and the latter because this is not a court. We do not have all the evidence.

If anyone is worried about the fairness and clarity of the nixos project, I hear you. This is a struggle in any project. Consider this: the community is a open source project, just like the codebase is an open source project. Share your ideas for how to improve it! There are a lot of good ideas swirling around in the greater internet, and we have the power to adopt them, or to innovate our own.

-b

6 Likes

(Furthermore, there have been evolutions in this project to make these matters clearer and easier to understand, afaict.)

As the most useful information for the long term that such thread can produce is a list of possible measures to take and their merits, I think if you tell specifically «I feel X has changed because of Z, and it improved clarity» it would be quite useful. (Saying explicitly «these are good things, could we have more of them» sometimes do magic in coordination problems, even if not always)

We do not have all the evidence.

We do not have some of the private emails sent to admins after the ban, although we know they existed and I do believe they indeed contained personal attacks.

I think any further details about these emails would not be relevant, though.

As for the rest of the evidence — I believe those of us who subscribe to the ML mode have it in the inboxes.

And how much editing of the public version of the conversation record is desirable is one of the topics in question…

Share your ideas for how to improve it!

Note that the discussion of details of old precedents are used as a justification for relevance of some of the proposals.

Simple in my opinion.


(source)

Stay above Ad Hominem and you’re golden.

10 Likes

Sorry for necro bumping the thread. But also giving awareness that this has been a long standing issue.

There is now an RFC to create a CoC [RFC 0114] Code of Conduct for NixOS Community by jonringer · Pull Request #114 · NixOS/rfcs · GitHub.

Hopefully this will make unsatisfactory resolutions less common.

5 Likes