Code of Conduct or whatever

Meta Moderation
1

I'm aware this is likely to be uncomfortable, but bear with me for a bit. Hopefully, a timeout of 1.5 years is enough to have a normal conversation about this.

So, reflecting on my own behavior and having remembered about Cannot comment anymore · Issue #27244 · NixOS/nixpkgs · GitHub and https://github.com/NixOS/nixpkgs/issues/27711 and the censored/deleted thread on this discourse named "Censorship issues" (Message-ID: <topic/1218@discourse.nixos.org>) by @Coretemp, I started to wonder, just for future reference, what exactly was the "tipping point" before the ban of 0xABAB?

I looked over a bunch of comments and reviews by 0xABAB archived in my Maildir and, while sometimes harsh, I could not find a single one that was not on point (including intersections with your truly in nixos: remove duplicate `wrapperDir` PATH addition · Pull Request #24703 · NixOS/nixpkgs · GitHub, at which I myself look back with humor, not with spite, btw).

Was it pbkbfd: Use getdelim instead of fgets · Issue #27258 · NixOS/nixpkgs · GitHub? From which point on 0xABAB's comments in that thread become unacceptable?

As another instance, I suppose "Another instance of a negative conversation in a Pull Request: #26924" Cannot comment anymore · Issue #27244 · NixOS/nixpkgs · GitHub especially noted by @Profpatsch refers to https://github.com/NixOS/nixpkgs/pull/26924#issuecomment-314026957\. But what exactly is the problem with that comment (except for the fact that the author got "annoyed by the unsolicited disparaging comments about the software that [he was] packaging", which, for me, was actually kinda surprising, since 0xABAB, in my opinion, didn't even say anything too harsh in that instance)?

So,

- Shouldn't there be at least a warning mechanism for stuff like this? Some discussion beforehand? It would be nice to know that some "disparaging comments" are not welcome before getting banned for them. E.g. should I fear for my safety if I were to ever mention something disparaging about PulseAudio in NixOS org again?

- How should the appeals be made? The only similar mechanism we have at the moment is RFCs. So, I would think, to get an appeal you would have to make an RFC, which is both ridiculous and technically impossible if you are already banned from the organization.

- What should be the acceptable level of harshness? Smugness? Any guidelines? Which culture should be a reference point? Having lived is several countries I'm painfully aware that cultures differ widely on the acceptable level of direct criticism. E.g. it is normal to get a harsh straight-in-your-face criticism of your work in Russia and Post-Soviet states (and in scientific peer-review, and on anonymous message boards, etc), while in a similar situation in Western Europe and US you are likely to get an "okay" in person and then silently ignored from that point on.

A related historical note from https://en.wikipedia.org/wiki/Socrates:

[...] One of Socrates's purported offenses to the city was his position as a social and moral critic. Rather than upholding a status quo and accepting [...], Socrates questioned the collective notion of [...] that he felt was common in [...] during this period. Plato refers to Socrates as the "gadfly" of the [...] (as the gadfly stings the horse into action, so Socrates stung various [...]), insofar as he irritated some people with considerations of justice and the pursuit of goodness. [...]

Socrates, as history teaches us, was executed for his "annoying" criticism. Should NixOS organization follow Athens in regard to harsh critics (i.e. "let's shoot the messenger!") or is the consensus somewhere else?

Note that I'm not saying that there's no fault in the conduct of any above-mentioned persons (including myself), but, personally, with respect to the above I wish everyone involved would have read and internalized GNU Kind Communications Guidelines - GNU Project - Free Software Foundation, especially

Please recognize that criticism of your statements is not a personal attack on you.

and

Please respond to what people actually said, not to exaggerations of their views.

on one side and

Please do not take a harsh tone towards other participants, and especially don't make personal attacks against them.

on the other.

As to the method of guidance towards these objectives, with respect to 0xABAB, I would have preferred something more gradual than a immediate complete ban (which still can be fixed, just saying). Because, personally, I think banning contributors that make valid technical points is counterproductive (which, btw, sometimes makes me wish GitHub reviews could be made anonymously, similarly to how the normal scientific peer-review is usually done).

Thoughts?

Ideally, I would like this issue to come to some consensus, which would then be formalized in some documentation, and the appeals process should probably become an RFC.

5 Likes
2

I’m sorry to say I don’t have the energy to properly reply to every point of your message. However, I will say this:

0xABAB was not suddenly banned, and instead was warned a few times and then banned. They had several posts where they were excessively rude to contributors, making insinuations about them, and not in good faith working to improve the work product. I’m not going to look them up, they’re not pleasant.

They also sent me some very unpleasant emails, saying things like:

Being nice to stupid people is something seems like an insurmountable task, because no matter how nice I am, they feel that deep down I think they are stupid idiots.

I think it’s just that you don’t like me telling that many of the ideas this group comes up with (see the RFCs) are actually approaching the level of mental retardation. Why can’t you act like a grown up and see that indeed all those ideas are stupid?

Do you think I want to volunteer my time only to be worked against by lesser people?

Do you really think other talented people don’t see the fuckups you make? Along with the epic fail that’s called your security project?

I’m happy to admit I mess up all the time. However, I’m quite certain this person does not belong in our community.

You ask about some guidelines, and while I can’t set community standards I can share my own. Some guidelines I try to follow are:

  • address the work which has been done, not the person
  • appreciate the person for having done the work
  • reply with kindness and graciousness, being flexible on minor nits, while remaining firm on the things I find most important.
17 Likes
3

Just $0.02 since one of my PRs was referenced above…

The root problem that I had is that when I sent a PR to nixpkgs it wasn’t clear to me what the process is for this to get merged. Who is going to review it? Is it my responsibility to consider their feedback and make my own decisions? Is some of the feedback a hard requirement to get my code merged and if so how do I identify those parts?

If I don’t know the answer to those questions, and I still want to get my code merged, then I’m kinda forced to jump through whatever hoops random people put in front of me in Github comments because I don’t know if they are gating requirements or not.

9 Likes
4

@oxij Assuming that there is no “NixOS community” but “NixOS is a side project of a cryptocurrency sub-community (iohk, tweag, serokell, …) which is an OSS project just by accident” could form a less paradoxical framework which provides explanation for many technical both management decisions which otherwise may look suboptimal.

2 Likes
5

There is definitely a lot of investment and use by cryptocurrency companies, but personally my day-job work is not funded by cryptocurrency work at all. There hasn’t been any shady going-ons that I know of. Additionally, I know we’ve been careful to not stack, say, the RFC steering committee with specific interests. I hope this isn’t a common opinion of how NixOS is managed, because I truly hope it never becomes true.

5 Likes
6

«Side project of cryptocurrency» subcommunity sounds an oversimplification (says someone with the first accepted patch to Nixpkgs predating any publically observables signs of Bitcoin by more than a year).

It might be true that cryptocurrency community is (more or less by definition) more accepting to unusual technical solutions to problems other communities try to solve by organisational measures. Dunno, I am not there.

But there are other special interests succesfully tending their own patches in Nixpkgs.

I do think that on the entire-system management front there is a strong skew towards servers, and those servers tend to be of a kind where «destroy 24 hours after incoming SSH» is more or less a reasonable policy. This has its drawbacks.

I think non-interference properties of Nix make it easier for Nix* to require less coordination for day-to-day progress (and survive problems with ever reaching consensus).

I personally think that Nix* is good at being a project first, turning around the code, and not a community that happens to write some code. This has its benefits.

3 Likes
7

I’d like to eventually see some kind of code of conduct if someone seriously puts one forward and we have people willing to enforce it. I’m not sure anyone’s willing to endure it though. I’d also support an appeals process, and maybe even a warning process (as long as ultimate steps can still be taken immediately after the warning when the undesirable behaviour continues) at the very least as a way to avoid accusations or implications of a (one) person doing something with supreme prejudice and without justification (which as far as I know has never ever happened.)

I also think it’s important to be explicit about never letting technical merits be an excuse for lax standards in communication. I strongly disagree that this is in any way a counterproductive position, and I strongly believe that the reality is the exact opposite.

As for the example in question, for calibration, while the linked PR discussion is indeed one of the very mild examples from that person, I still consider it far, far worse than what we should ever accept.

9 Likes
8

Yes, the heavy vendor lock to expensive AWS, up to hardcoding it to Nix (together with claimilng that it is too expensive to hold debugging info there) is one of those technical decisions. Or removing kernel-4.4 a year before its scheduled EOL. Those decisions are made having a particular use case in mind (not to say “a particular deployment”) without any RFC.
And then there is a visible split of the contributor groups to “those who are on mainline NixOS” (all the “cryptographers”) and “those who have forked and contribute by backporting” (triton, me, @oxij, Mayflower, …)

2 Likes
9

I think I see what you’re saying, about lack of attention to some use cases, with some tunnel-vision on others. I can’t disagree with that. I am hoping a functional RFC process (something we definitely did not have before – hopefully we have one now) improves this.

Replying to the specific point about Linux 4.4, it was removed in:

commit 9f3f575ab3eb4cd6b5f8de20e6f1a5374fedef2c
Author: Robin Gloster <mail@glob.in>
Date:   Fri Aug 11 19:09:58 2017 +0200

    linux_4_4: remove
    
    Support ends in Feb 2018

in preparation for the stable release, where 4.4 would no longer be supported in the course of that release. That hasn’t been so uncommon – it is ugly to have to maintain software ourselves, especially such security-critical software.

However, after that commit it was put back because upstream extended support:

commit 517606d1d4872c3b8b1a42796d572a7420fe1489
Author: Franz Pletz <fpletz@fnordicwalking.de>
Date:   Mon Oct 30 13:55:46 2017 +0100

    Revert "linux_4_4: remove"
    
    This reverts commit 9f3f575ab3eb4cd6b5f8de20e6f1a5374fedef2c.
    
    Support from upstream has been extended to Feb 2022.

An interesting point (related to the visible split you mention) is these two commits were made to NixOS directly, by people who work for Mayflower.

I made an edit deleting the stuff about the kernel because it was not really relevant to your previous comment, but then you commented in reply to it… so I put it back.

1 Like
10

Nevertheless, they do not use NixOS’s master. GitHub - mayflower/nixpkgs: Nix Packages collection “is 10618 commits ahead, 17841 commits behind NixOS:master.”. Should we count it as part of NixOS community? Or Triton which diverged even more? Or SLNOS?
My point is there is smaller community and a broader one. Returning to the topic start - people in the smaller have “ban” button and (only) people on the broader wonder why they do use it, while people in the smaller have too much to do besides NixOS and might agree on thoughts like “What if a Cardano investor see topics with 0xABAB?”

11

@volth

Yes, the heavy vendor lock to expensive AWS, up to hardcoding it to Nix (together with claimilng that it is too expensive to hold debugging info there) is one of those technical decisions.

For some use cases, some other providers seem to have equal support… But yes, there is no consistent policy of anything, some things happen to be merged at some points in time.

Or removing kernel-4.4 a year before its scheduled EOL. Those decisions are made having a particular use case in mind (not to say “a particular deployment”) without any RFC.

There is a ton of kernel versions, a complicated story about very-long-term stables, no consistent policy about versions in Nixpkgs, and I think I can say that the RFC process is still not fully operational even now (when we push a technical RFC about code inside Nixpkgs with technical amendments through the process, this example will be an important part of the full process — I hope we get there soon)

I also meant some things where I cannot imagine any use case that dictates the choice that was made… Like the exact semantics of

And then there is a visible split of the contributor groups to “those who are on mainline NixOS” (all the “cryptographers”) and “those who have forked and contribute by backporting” (triton, me, @oxij, Mayflower, …)

Given that the NixOS Stable 19.03 release manager is at Mayflower (and many other committers are), I would say that the split has more interesting dynamics than you describe.

Actually, the main developer of Triton also has Nixpkgs write access. Triton did a lot of cleaning up, in many cases by abandoning use cases Nixpkgs master supports (and I don’t think anything cryptocurrency-related benefits from cross-compiling to MIPS)

(you not being a committer is a bit weird, actually — but apparently proactively proposing commit access almost never happens, while the threshold for granting requested access is way below your experience and contributions; I guess if you permit me to remind people on your behalf, I can make sure that permission is treated as a commit access request and not lost)

I have a feeling that once people care about something cross-cutting, they start forking. Or just fully replacing large parts.

Me myself — I commit Common Lisp stuff on master (because it doesn’t really suffer from whatever I disagree with), and try to keep an eye on LibreOffice etc., but I switched away from NixOS to my own bootscripts because it became just simpler.

My point is there is smaller community and a broader one. Returning to the topic start - people in the smaller have “ban” button and (only) people on the broader wonder why they do use it.

Well, one could also argue that people in the broader community are less likely to keep track of discussions in Nixpkgs that are not even closely related to their actual interests.

I still think, judging from observation: all the bans in the NixOS org follow the pattern «first, annoy a lot of people by personal attacks and declaring that the situation is not difference in priorities and lack of care for many other cases (as you correctly note) but just the project’s current priorities in some area being absolutely and globally worthless; second, explicitly refuse to pay attention to a few warnings; third, oops».

There are some decisions around Nix* that I find really unfortunate, but any specific ban has yet to be one of those.

(The bans are also quite rare)

@srhb

I still consider it far, far worse than what we should ever accept.

In a way, there is no «just right» — your «too late» and @volth’s «too early» seem to intersect. And there are limitations of inability to use GitHub for communicating with a banned user, and that we already have quite a few people — who are perfectly polite themselves — discuss if the ban was done too early…

I also think it’s important to be explicit about never letting technical merits be an excuse for lax standards in communication.

We-ell. There are many questions and they are intertwined. Demonstrating technical merit relevant to the project usually means committing effort to useful contributions. That makes it easier for other project members to assume some amount of good faith. Otherwise the assumption of good faith runs out much faster.

I do think that the likelihood of good faith is a useful and important factor for decisions

3 Likes
12

@volth well, that wasn’t very helpful to the conversation for sure.

To stay on topic, maybe we can start by clarifying some guidelines for the Discourse forum explicitly.

For the record, here is the current list of admins:

We currently have 0 suspended accounts and 1 silenced account (a spam account).

Historically we have suspended a single account for a period of one month.

Tentative Code of Conduct for Discourse

The goal of this place is to promote discussions and collaborations around Nix and NixOS topics. We want this to be a friendly place where new members can feel safe asking questions. This is the place where you should be happy to go if you are stuck and don’t know how to proceed next.

In that light, there are certain behaviors that are not conducive to good discussions and should be frowned upon. When words are written, it’s good etiquette to also think of the reader and how they might perceive your words.

Here are some guidelines for the discussions:

  • Try to keep a thread on topic. Please be respectful of the person that started the topic. If you have other things to say, create your own thread!

  • Attack ideas but not persons. The person is not going to change if you attack them, and the discussion is hard to recover after that. Take a break instead.

  • Being logically or technologically right doesn’t excuse any bad behavior.

  • Avoid unnecessary negative emotions; hate, fear, uncertainty; this takes a toll on everybody. Negative emotions are powerful and take a lot of energy not to react to negatively in return. It’s everybody’s responsibility not to fail and reply hate with hate.

  • Don’t try and assume too much about what people write. We have different cultures and ways of thinking. If you get emotionally hurt, assume that they meant well and move on.

  • It’s fine to be grumpy or to rant a bit some times. Rants can actually give new ideas to explore.

  • It’s great not to agree on everything. It would be boring otherwise.

  • Try to keep an open mind.

  • Invest in your writing. This is not Twitter. Try to formulate your ideas as clear as possible. Be precise. Use as many words as you need, but not more.

Our goal is to have conversations and policing is also bad for having open conversations. Which is a conundrum because if we don’t police bad actors, then it also prevents conversation.

For now the rule is that if the group of admins perceive that a certain individual has a net negative effect on the forum then they will be asked to review the above list and try and reflect in how they could improve future communication. We will point them exactly to which item they have failed in private. If it’s not possible to reach them in that regard, they will be suspended for one month.

We understand that not everybody is fluent in English, has different cultures and that miscommunication can happen.

How does that sound? I hope that it might alleviate any fear to be suddenly blocked.

It’s basically encoding what happened during our last block. The person was doing pretty much all of the above items and wasn’t acknowledging that this was a problem. Instead the blame was always put on others. After multiple warnings and days or work lost because of the distraction we decided to put a temporary block in place.

Just thinking back at the event it was very disruptive, I hope that it doesn’t happen again.

10 Likes
13

E.g. it is normal to get a harsh straight-in-your-face criticism of your work in Russia and Post-Soviet states (and in scientific peer-review, and on anonymous message boards, etc)

As a someone from Russia, I can say there are different kinds of harshness.

For example:

The reason Pharo crashes with newer compilers is because newer compilers tend to exploit C semantics, and in particular undefined behavior, better.

This is somewhat reasonable.

What would happen if there was a space? (This is a rhetorical question, since you clearly have no idea how to write a shell script. Oh, and for the love of $DEITY, please test your code before you say more stupid things.)

This is not.

3 Likes
14

As for who gets banned and for what, it seems like there is no problem right now. There is (hopefully) no doubt the ban of 0xABAB was absolutely reasonable. At least after reading how he responded to the warnings given to him. So if there would’ve been a short guideline telling that people will be warned directly (e.g. per mail) and banned if they don’t change, this Post here would’ve probably been closed in a single answer.

And like @lukego, I also had the problem some times that I didn’t know what I have to do in order for a PR to get merged. I’m very glad I only got very nice feedback on my PR’s and I could just fix the issues to get somebody merge it at some point. But I’m sure getting a harsh feedback at the beginning could’ve made me turn away from NixOs.
I guess we could add those four points in short to the contributionguideline at https://github.com/NixOS/nixpkgs/blob/6dce69e47536568700951a71e417a9c93f8c9448/.github/CONTRIBUTING.md

  • how different mechanisms like a PR work (maybe there are more mechanisms that could be explained?)
  • what the different authorities are (contributor, maintainer, etc.) and what their “rights” and responsibilities are
  • do’s and don’ts (a do is already described by telling how a PR should look. Maybe link to the CoC of @zimbatm )
  • how to get help

I’m aware that there are some RFC’s which will improve the PR process (e.g. [RFC 0030] Formalize review workflow by timokau · Pull Request #30 · NixOS/rfcs · GitHub which has sadly been closed for now) and making sure those RFCs will be well documented might already be enough.

I also realise there are already documentations like Nixpkgs 23.11 manual | Nix & NixOS but they don’t really answer those four points (and in my opinion such a massive onepager was and is still quite overwhelming sometimes, but this is probably personal preference).

1 Like
15

@volth well, that wasn’t very helpful to the conversation for sure.

In my opinion, discussions of community dynamics sometimes benefit from knowing what impressions of comunity dynamics exist in community. If we want people not to have some impressions, don’t we need to know what we are trying to clarify in the first place?

We currently have 0 suspended accounts and 1 silenced account (a spam account).
Historically we have suspended a single account for a period of one month.

Well, I think bans were discussed in context of GitHub. (But anyway, thanks for transparency).

On Discourse the question was more about post hiding (but now I also wonder about the expecations about moderatorial editing the posts…)

Tentative Code of Conduct for Discourse

Is the plan to replace completely the guidelines linked from the registration flow?

  • Attack ideas but not persons. The person is not going to change if you attack them, and the discussion is hard to recover after that. Take a break instead.

Judging from what happenned on GitHub, I would also say something along the lines of:

«
Priorities and values differ. If it is possible to have respectful and mutually useful collaboration despite differing priorities, it is better than fighting over values.
»

  • Being logically or technologically right doesn’t excuse any bad behavior.

To me, that seems out of place before enumeration of behaviours to avoid.

  • Avoid unnecessary negative emotions; hate, fear, uncertainty;

I would say «avoid expressing and doyour best to avoid causing». Having emotions is not an action/conduct.

  • Try to keep an open mind.

I would move the part about «being right doesn’t excuse being rude» here:

«
Try to keep an open mind. If you are given reasons to change you mind consider whether you are indeed wrong about something. On the other hand, being right is not an excuse for bad behaviuour.
»

Use as many words as you need, but not more.

I think this part of the request is often associated with an even higher level of investment into writing than we want to ask here. We want to have a respectful and technically sound and efficient but somewhat transient conversation here; perfectly measured phrases can wait until the explanation is added to the manual, in my point of view.

16

So I think it’s time I have to chime in here, mind that I speak for myself, but I very much guess @fpletz and @lheckemann will share my opinions.

Just to get some facts straight about our so-called “fork”:

  • We “forked” (as in Github fork) nixpkgs before overlays existed
  • It exists for, firstly getting code from us merged into NixOS/nixpkgs (this way we can jointly work on PRs, without the need of giving access to people on personal forks)
  • secondly our workflow started by having mayflower/nixpkgs master tracking nixos/nixpkgs master and rebasing our changes on top semi-regularly (once every 1-2 weeks)

In the past we first changed to merging in NixOS/nixpkgs master, as that made life with conflicts easier, and then, at roughly the time when first I and then @fpletz were release managers, we started to merge in the latest release branch instead of master in order to dogfood the release. We’ve kept this workflow now over the past ~2 years and always start to switch to the new release branch soon after it’s branched off in order to help stabilising the upcoming release. The mayflower/nixpkgs master branch is also mainly used for machines we run in production, actually I personally use it on my laptop, but I know that a number of people at Mayflower, for their personal machines and home servers etc. only use NixOS/nixpkgs branches or channels.

(This explains the high number of commit difference to NixOS/nixpkgs master as that comparison is inherently irrelevant)

If we had had the possibility of using overlays at the time we started, we probably wouldn’t have this fork as-is. One thing, we also do, is backporting things “prematurely” to our master branch (still mind that this is based on release-18.09 currently). Just a week ago I backported the changes for the k8s refactoring which hasn’t even been merged into NixOS/nixpkgs in order to allow us to thoroughly test it in for us realistically scenarios.

We always try to contribute everything back to NixOS/nixpkgs as we strongly believe that is where our code should ultimately live! We are not remotely interested in maintaining a proper fork in any way, that would only make our life far more difficult and we have actually started to move code diverging from NixOS/nixpkgs into our overlay and modules at mayflower/nixexprs in order to reduce the diff we currenly have, with the ultimate goal to at some point have no relevant code in mayflower/nixpkgs except for backports which will eventually land in a release branch anyway. (e.g. the mailman3 module/drvs we wrote have been moved to mayflower/nixexprs, because they are far to hacky and with random patches to upstream code flying around, that currently make it impossible to get that into nixos/nixpkgs.)

Also we have tickets in our internal issue tracker, tracking the differences remaining in mayflower/nixpkgs that should be upstreamed to nixos/nixpkgs.This sadly doesn’t always happen as soon as we’d like as they often contain hacks, tailored to our specific use case that cannot simply be committed to nixos/nixpkgs and we also sometimes have to work on customer projects, because as most of you will guess, even our company has to earn money somehow.

Now to counter all the but’s, I’d like to emphasise that all of us try to give things back to the NixOS community, we very strongly believe in Open Source and in participating in projects we use and believe in! I hope this should be clear from the work we regularly do for NixOS, currently @fpletz being in the security team, @lheckemann as one of the release managers for 19.03 and 19.09 and me trying to help in bringing the RFC process back to life with RFC 36 and now participating in the RFC Steering Committee, being former release managers and a few other Mayflower employees “merely” working on maintaining packages, fixing bugs etc. who will probably won’t even be noticed as mayflower employees most of the time.

Obviously we are providing NixOS consulting and support, but our aim and vision is not to make money with NixOS, but rather we want to have the possibility for us to have a budget with which we can work on improving NixOS and the whole ecosystem around it and do more open source work. And obviously even work we get paid for will be open source if possible (depending on the customer).

9 Likes
17

@suhr

As a someone from Russia, I can say there are different kinds of harshness.

Well, let’s actually analyze what was actually written.

For example:

The reason Pharo crashes with newer compilers is because newer compilers tend to exploit C semantics, and in particular undefined behavior, better.

This is somewhat reasonable.

That quote is not even close to being harsh, IMHO. It just states facts. IMHO, the problem, if any, is in the next sentence

Pharo programmers used fork without understanding what it does (next to some other out of bounds issue being present).

Because how did 0xABAB know that? Did he live with Pharo’s programmers in the same house? Consult them? Unlikely. Had he provided some proof of that sentence, I would have absolutely no claims against that comment.

What would happen if there was a space? (This is a rhetorical question, since you clearly have no idea how to write a shell script. Oh, and for the love of $DEITY, please test your code before you say more stupid things.)

This is not.

Internally, I substituted that with

What would happen if there was a space? (This is a rhetorical question, since you clearly have not tested what you wrote above, please test your code before you say more stupid things.)

which with that applied, IMHO, became very reasonable. It would have been perfectly OK for me if it were formulated this way in the original.

IMHO, the problem with the original is

since you clearly have no idea how to write a shell script

part, which, given I’m trying give constructive comments on the topic is a factually incorrect statement (true, I might have had some of a “wrong idea”, but clearly not “no idea”), and a bit of a personal attack. The $DEITY part I don’t really feel too strongly about.

The rest of the conversation is similar:

@oxij So, now you are saying that tooling which is as old as UNIX itself has changed semantics as opposed to the simpler explanation that in 1998 you didn’t know what you were doing (something which is ostensibly true in 2017)? Bold, very bold.

opposed to the simpler explanation that in 1998 you didn’t know what you were doing

Correct, I was a child. I totally remember having bash issues with variable substitution and spaces, but it was 1998, I was a child, and I don’t remember what I did exactly. For some weird shit I remember doing I have an explanation (e.g. not knowing ^C exists), for some I still don’t.

something which is ostensibly true in 2017

But that statement is factually incorrect given my previous comment, also a bit of a personal attack.

And so on for the rest of the conversation.

IMHO, the problem with that conversation there was that 0xABAB ignored my explanations of how I came to the original conclusion

I got bitten by not having enough quotes in bash enough times to prefer adding more than strictly required.

ignored my technical arguments “well, yeah, sure, I have not tested that bit and my perception of the old bash seems to be factually wrong, sorry about that, thanks for pointing that out, but if the semantics were to change I would not be surprised, because it does change from time to time” (which is the short version of most of the stuff I wrote there) and “it won’t hurt to have quotes there anyway, let’s stop the bike-shedding” and continued to combine small bits of personal attacks into what turned into an ugly conversation.

The

You should learn to recognize a superior force when you meet one.

bit was actually funny, IMHO. (I do recognize that it was probably meant literally, but not being lazy to do your research does make a “super power”, kind of, so “superior force” it is kind of funny.)

Btw, the outcome of a similar analysis of my own statements regarding the relationship between NixOS and PulseAudio had been this: I shall not use words with negative connotations applicable to people to describe a perceived state of things, emotionally charged readers will ignore the complete statements and parse the writing using from those words alone; emotionally charged readers will ignore any otherwise valid arguments; anyone can become emotionally changed when confronted with inconvenient facts.

[I.e., while, I don’t think I made any false statements in those conversations (including, about people; to those involved: yes, including, go read the original statements as they are, not as you remember them), I could have made the issue much nicer if I had internalized something like RMS’s “Kind Communication Guidelines” before (which he wrote much later, but it doesn’t excuse me, of course).]

What to do with my “smugness” I still have no idea. Hence, still

Any guidelines?

@srhb

I’d like to eventually see some kind of code of conduct if someone seriously puts one forward and we have people willing to enforce it.

It is “enforce” part I’m mostly worried about. People involved in software development are usually nerds, and nerds are usually very opinionated. Enforcement by highly opinionated people usually turns into ostracizing for wrongthink, or, worse, inquisition.

Even after everything that was said about 0xABAB I’m not sure that the way was he was banned was totally okay. Sure, his demerits and all of that, but the conversation in Cannot comment anymore · Issue #27244 · NixOS/nixpkgs · GitHub says to me that he was not properly warned. The fact that @vcunat at the time did not know that 0xABAB was banned is also surprising, to say the least.

I.e. I think that, at the very least, “the last warning” and the bans themselves must be public. In particular, you can’t appeal a ban if you don’t know why was you banned in the first place. Nor can you make any conclusions and fix your conduct. Nor can others easily find what is considered not acceptable in this community and learn without triggering the system.

I also think it’s important to be explicit about never letting technical merits be an excuse for lax standards in communication.

I might disagree depending on the definition of “lax standards”. I think straight-in-your-face criticism must not be outlawed, in fact, I think, it should be encouraged. To me, the lack of straight-in-your-face criticism means “lax standards”, not the other way around.

The universe does not care about your particular culture. Straight-in-your-face criticism is the only way this universe makes any progress: be it evolution (“Hey, you suck! You are dead! You won’t have any more children! Ha! Straight in your face, individual!”), or anonymous peer review in scientific research.

[Btw, I think the Western culture is actually regressive on the latter point, that became “science” in the West was known as “alchemy” before the invention of anonymous peer-review, even today everything that does not go via proper anonymous peer-review (like a lot of medical research, for instance) usually sucks. Which is why the science in the West actually progresses when encumbering “influential” scientists die (a problem that would be much less of an issue if sciences were actually publicly funded, not via some government bureaucracy allocating funds by looking at some nonsense numbers, btw, but still). Apparently, same problem exists in the East, with the “losing your face” tradition and stuff. But, apparently, this was not a big problem in the Soviet Union (at least in the falsifiable technical fields acceptable by Marxist-Leninist ideology, Marxist-Leninist humanities sucked even more than humanities suck everywhere else), where negative peer-reviews were actually frequently signed by their authors, and being straight-in-your-face destroyed at “kandidat’s” (Ph.D) defense was a fairly common thing (and, apparently, still is in Russia and Post-Soviet states in most actually working “dissertation committees”). Yes, I know I am oversimplifying a bit, but still.

Note that such a system actually combines the merits straight-in-your-faceness of anonymous peer-review with the institution of reputation, which can be useful (as it can be harmful). I don’t know of a simpler system that can implement both, everything I know of seems to require pseudonyms anyway.

(Which is yet another reason why ML’s are preferable to GitHub, IMHO. An anonymous review to ML is easy to implement, anonymous review to GitHub PR is not.)]

18

Because how did 0xABAB know that? Did he live with Pharo’s programmers in the same house? Consult them?

Well, if code looks like people did not have a single idea how use something properly, they probably indeed didn’t.

which with that applied, IMHO, became very reasonable

The very point of code review is to improve the code. Not feeding your ego by telling how stupid or ignorant other people are.

“This will break on a first whitespace” is short, clear, and conducts the goal of code review.

1 Like
19

The reason Pharo crashes with newer compilers is because newer compilers tend to exploit C semantics, and in particular undefined behavior, better.
This is somewhat reasonable.
That quote is not even close to being harsh, IMHO. It just states facts. IMHO, the problem, if any, is in the next sentence

I also don’t see any harshness here, even harshness to the code (let alone personal).

Even after everything that was said about 0xABAB I’m not sure that the way was he was banned was totally okay. Sure, his demerits and all of that, but the conversation in Cannot comment anymore · Issue #27244 · NixOS/nixpkgs · GitHub says to me that he was not properly warned. The fact that @vcunat at the time did not know that 0xABAB was banned is also surprising, to say the least.

I would say there are three separate questions.

Were the warnings given reasonably, were the warnings interpreted correctly, and how much global coordination we want.

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.

I.e. I think that, at the very least, “the last warning” and the bans themselves must be public.

Maybe it is a good idea to discuss whether short bans (24h–7d) are something we want to support as a policy (the last warning would come with a relatively short ban to make it completely clear; maybe shorter bans could be used when requests for calm don’t help in a discussion).

A central list for reasons-of-ban (the full details could actually be better to have as a mailing list, to avoid incentives to troll the opponent into getting into a public shaming list) might help; although in that case I would also support the list of non-minor forced edits of posts/comments.

I also think it’s important to be explicit about never letting technical merits be an excuse for lax standards in communication.

I might disagree depending on the definition of “lax standards”. I think straight-in-your-face criticism must not be outlawed, in fact, I think, it should be encouraged. To me, the lack of straight-in-your-face criticism means “lax standards”, not the other way around.

To annoy everyone: as we are trying to separate various classes of comments, I would support straight-in-your-code criticism, and we could use «straight-in-your-face» for criticism loaded with implications about the person (and discourage that).

and being straight-in-your-face destroyed at “kandidat’s” (Ph.D) defense was a fairly common thing (and, apparently, still is in Russia and Post-Soviet states in most actually working “dissertation committees”). Yes, I know I am oversimplifying a bit, but still.

Write me off-list (7c6f434c@mail.ru as usual) if you want to discuss how much of oversimplification everything in that paragraph is…

20

I was last able to follow (almost) all nixos.org conversations several years ago; now it’s just impossible to me and I read only a small fraction, and e.g. on IRC I’m very rare… so I wouldn’t give much weight to me not knowing of such things.

1 Like