The more I dig through kernel mailing list discussions, the more I think that we would do well to end the use of "NAK" entirely. It is an exercise of power that is hurtful to read and gets in the way of an actual discussion of how a patch needs to be improved. I have, in my maintainer role, never said "NAK" to a patch and plan to continue that way.

*Edited* since people are asking: NAK (or NACK) comes (I believe) from the ASCII negative-acknowledge character. In this context, is an abrupt way for a maintainer to reject a patch.

@corbet who use it: the reviewers or the person posting the patch for review?

@corbet I disagree profoundly. It's very important to prevent things that will cause issues from getting in to the kernel, and a simple no is not always clear enough. And it comes up rather more often thank you'd think.

I mean Kent's behaviour is beyond the pale on any level, if this is in any way calibrated to that - that is not what a nack should be.

I agree on trying to communicate effectively and nicely, and I know I get this wrong sometimes myself (I will occasionally respond to my own email apologetically after I realise I perhaps came across unintentionally harshly).

But if you have a scenario like mm where things get merged unless people say no, sometimes you need to make it _very_ clear.

You sometimes have cases where the submitter is stubbornly refusing to listen to reason or the conversation goes around in a circle as well which can be problematic.

I guess I'd say 'no NACK _without_ a reasonable justification + if the series can be recovered, some constructive feedback as to how to get to an acceptable point'.

@corbet Any specific example that triggered this?

@corbet fwiw, I tend to not use it unless the message really isn't getting across.

@brauner I'm digging through the whole Asahi Lina graphics driver story, but it's something I've often thought.

@corbet What is NAK?

@corbet yeah same, it just tends to be a signal for communication breakdown. usually because people are fixated on the specific patch and there's no discussions about the higher levels, like whether there's an actual problem, what the problem exactly is and isn't, then eventually what the design and architectural options are and which are good tradeoff choices, to finally maybe reach an actual patch.

still one of the best guides imo to do better https://sage.thesharps.us/2014/09/01/the-gentle-art-of-patch-review/

@corbet @brauner

I was going to reply to the original post that we generally try to avoid NAK in the drm subsystem, but then, uh oh.

I think it's something we strive for, anyway.

@corbet the other case tends to be overloaded maintainers who failed to write documentation they could point at, and instead continue to just NAK patches because that's less typing. in the short term only, it's definitely a lot more typing long term

@jwf NAK (or NACK) - negative acknowledge - is a curt way of saying that a patch will be rejected.

@jani @corbet @brauner I've sent mails (perhaps privately, I can't remember), stating any use of NAKs is not productive, and that I would cease pulling stuff from NAK senders unless the next set of patches they submitted were documentation on the area they NAK'ed patches in. We have gotten some documentation as a result.

@airlied @jani @corbet @brauner yeah we did get into this. it's just that damage done is visible forever, and improving documentation to the point where you can just paste a kerneldoc link where previously people felt like dropping a NAK takes a long time

@corbet (For a moment I convinced myself that in Monty Python and The Holy Grail there was a scene about the "Knights who say Nak" and that this was in reference to that)

@pkal Heh ... one could have a *lot* of fun playing with that idea...

@corbet Trying to follow, but I'm out of the loop on the meaning of the acronym. Can anyone fill me in? Thanks!

@corbet I got my first ever NAK today from one subsystem, that ended up causing a rewrite based on that, and the actual subsystem I'm fixing doesn't like that solution, so I'm going back to the first ever version :)

@corbet oh, and it was merely exposing a symbol but I guess they didn't like it "for some reason"

@corbet May I ask what NAK means?

@brauner @corbet I use it (sparingly) for innocent-looking but buggy patches, to make sure they are not applied by a maintainer who didn't get a morning coffee.

@brauner @corbet And in these days where not all emails may reach the maintainer's inbox ("Bounce probe for ..."): "b4 am" picks up NAKs, unlike weaker review comments.

@june @corbet If it’s similar to Wayland protocol discussion terminology, then it means “not acknowledge”. I think it’s basically a veto vote, but I could be wrong, as I haven’t looked at either the LKML (Linux kernel mailing list) or the Wayland protocol discussions a lot, so take it with a grain of salt.

@corbet @pkal Are you sure it's not the Knights who write C?
C!

@june @corbet "negative acknowledgement", a curt way to reject a patch

@corbet @brauner can I have a link to that?

@marnanel @brauner The case that brought this to mind is https://lwn.net/ml/all/cd788ccf-0cf1-85d5-1bf8-efc259bd7e11@amd.com/

...more details on LWN shortly...

@sima @airlied @jani @corbet @brauner This is also something I'm simmered about in other areas. It seems like "NAK" gets easily abused (not just in Linux, but in other projects that have a similar process), and almost every example I've seen of it has resulted in a sour ending for all parties involved.

I find myself wondering if the NAK power should be actively eliminated in projects where it has resulted in an overly negative view of engaging with the project.

@Conan_Kudo @airlied @jani @corbet @brauner for me that generalizes to one of the most important lessons I've learned as a leader of some project or area

the more power you have, whether formal or informal doesn't really matter, the harder it is to actually use it. a big hammer is a very blunt instrument, and so the longer I do this, the more I just drop suggestions and help dig through tricky corners and get the consensus engineering started, but rarely ever finish to a solid conclusion

@sima @airlied @jani @corbet @brauner This makes sense to me. There are many areas where I have tremendous "power" (or at least the appearance of it), so I take great pains to demonstratively *not* use it. Contributors seem to appreciate that a lot, because the end result is that they feel valued across the board.

@Conan_Kudo @sima @airlied @jani @corbet @brauner Personally, the notion of using a "NAK" only makes sense if you see the project as your own property you want to protect from allegedly "wrong ideas".

So once you start to treat a project as a collaborative space with equal footing for everybody, it makes no sense to "NAK" anymore, because you recognized that you are not the owner, you are merely a manager of various contributors and make sure that people get their stuff done and to provide help

@karolherbst @Conan_Kudo @sima @airlied @corbet @brauner

Also, gatekeeper vs. guide.

@jani @karolherbst @Conan_Kudo @airlied @corbet @brauner yeah ...

and right at this moment I'm pondering whether I should type up a comment, or not, as subsystem maintainer

deleted a draft twice already

@sima @jani @Conan_Kudo @airlied @corbet @brauner You can always ask others for advise if you are not happy with your drafts, but you should know that already 🙃

But anyway, I'm sure others are willing to help with those kind of responses.

@karolherbst @jani @Conan_Kudo @airlied @corbet @brauner oh sure

the question I'm pondering is how much should I talk about what has happened the past years in private discussions, or whether that's going to cause more damage than good

@sima @jani @Conan_Kudo @airlied @corbet @brauner oh you meant here in this discussion? Ah yeah...

@karolherbst @jani @Conan_Kudo @airlied @corbet @brauner nah like either as an lwn comment or maybe I should warm up the blog engine and draft some proper text

put the energy into commenting on a related rfc patch instead for now, felt more useful

@corbet

I do think NAK has a strong negative connotations which one need to beware of. Guiding contributors in a more gentle way is a better way.

At the same time, NAK can be a needed failsafe which may need to be used when the contributor's, should we dare say, arrogance, is in the way for an improved and better change. Some times a maintainer will need to draw a clear line of what is an acceptable change and not.

It's also needed to be careful to not be too gentle when rejecting a proposed change. Wrapping a rejection into too many soft words and phrases can do equal damage - that the contributor gets uncertain what's wrong and without a clear path forward. Contributors do deserve better than that too.

I often think coding itself is the easy part. It's handling people and expectations which is the biggest challenge in collaboration.

@corbet Proposing NAKs-per-day as a core community health metric

@vegard @corbet how long did it take you to make this graph? 😳

@Aissen @corbet Not long enough -- I just realized the Y ticks are funky and not well rounded. Take with a grain of salt... (edit: fixed now)

@vegard @corbet Yes, getting healthier all the time

@vegard @corbet Also I already have a workaround

No, sorry this patch is not at
All acceptable. If you
Could, I'd appreciate it if you would
Kindly go away.

@Aissen @vegard @corbet wait that sounds negative, are you nacking the graph??

@vegard @corbet This probably needs some kind of normalization. The number of patches/contributors/maintainers is not constant over time.