LWN: Comments on "The kernel's code of conduct, one week later"

The kernel's code of conduct, one week later

demoryw — Sun, 14 Oct 2018 16:36:37 +0000

While it is important to define our terms, I wonder if taking a narrow view of who can be community member is a good idea. Why limit who can participate? Isn’t one of the prime motivators for the Code of Conduct to be more inclusive?

I believe a good code of conduct has more to do with common human desires and social norms, for example, respect. Explicitly excluding people, while a very human reaction, may not be the best course of action.

Authority

codeofdrama — Thu, 04 Oct 2018 09:27:58 +0000

Here's an idea I had yesterday. State publicly what standard of conduct, you would like to be held to. That is, encourage others to let you know, when you haven't met your own standard. Write down this standard of conduct, or reuse an existing one, and link to it in your e-mail signature, Twitter profile, or other places, where people can easily find it. For example:

"I attempt to hold myself in all interactions on this medium to the <a href="https://example.com/codeofconduct.html">Example Standard Code of Conduct</a>."

As long as it's not in conflict with community standards, I think this could be an even more powerful way to signal intent, especially if this standard is higher than the community one.

What do you think?

bug tracker fragmentation

johannbg — Thu, 04 Oct 2018 07:27:37 +0000

If bugzilla aint that bad then there is no excuse for kernel and all it's sub-communities not using it but I personally dont recommend it. Today's requirements are so much more then an simple bug tracker.

The kernel's code of conduct, one week later

cpitrat — Thu, 04 Oct 2018 07:20:37 +0000

The reason why your first comment was ambiguous is that it didn't explain why you still had doubt (i.e why one should prefer the Debian CoC to the DRM one). Your second comment fixes that.

Said crudely, your first comment looked like a troll whereas your second looks like an argument.

As for why, I'd be tempted to say the NIH syndrome probably played a bit: Linus (and other people involved in the decision) are more familiar with the DRM folks than with the Debian's one. They had direct feedback on this CoC, not on the others. Not all decisions are necessarily rational ...

bug tracker fragmentation

marcH — Thu, 04 Oct 2018 07:03:53 +0000

Bugzilla is practically inexistent in the experience I described.

The tracker software certainly plays a role but not the most important role in my experience. How you configure and use it matters much more. it's a bit like programming languages: you can write bad code in any of them. It's just easier with some.

bug tracker fragmentation

johannbg — Thu, 04 Oct 2018 06:09:47 +0000

Through my life I have come across my share of various bug trackers and worked maintaining one for several years, which hosted over 1000 projects of mixed match of being software projects to request tracker, literally creating, and tailoring workflows to individual company and government structure,their departments, different teams to make those companies more efficent,meet their sla, generate reports etc.

I have seen unimaginable horror in this regard so much horror that I propably should make freedesktop.org my next draining the type ocean project and contribute to it's migration/restoration ( that is if it will ever get over it's identity crisis ) ;)

Anyway I understand the pain you are getting at but what you describe here is failure of the tool and or those that are administrating it, which is the cause of the fragmentation so simply switch out bugzilla for something better. . .

bug tracker fragmentation

marcH — Thu, 04 Oct 2018 03:43:23 +0000

- I've seen a number of bug tracker "bridges" in operation and heard of a few more. They were all mostly dysfunctional and universally hated. A well designed schema for a bug database models closely the workflows of the corresponding team. Different teams work differently and bridging different schemas leaves users constantly wondering what exact information does the bridge lose and under which conditions.

- I can hardly see any value anyway in a unique bug tracker for the kernel - which again is a huge collection of many different projects. Why would the developers of some wifi driver care about bugs in some other random audio driver? Why would have to constantly filter out noise from other components? Why would they have to restrict themselves to a common and minimal schema? Why would they have to deal with the significantly higher administration complexity, work and permissions?

The kernel's code of conduct, one week later

jubal — Wed, 03 Oct 2018 14:27:02 +0000

gamergate never died, apparently :-(

Authority

daniel — Wed, 03 Oct 2018 00:18:03 +0000

The Debian code of conduct succeeds very well at giving practical advice: https://www.debian.org/code_of_conduct
Link to kernel code of conduct for convenience: https://git.kernel.org/pub/scm/linux/kernel/git/stable/li...

I think the Debian code of conduct is a better document than the kernel code of conduct. However, the latter is far superior to the (flippantly named) code of conflict. It's progress.

In concrete terms, the Debian code of conduct describes specific desirable behavior under each generic heading. The kernel code of conduct only provides generic headings. On the other hand, the kernel code of conduct gives equal prominence to desirable and undesirable behavior, a point in its favor. For some reason not clear to me, the kernel code of conduct describes undesirable behavior more specifically than desirable behavior. It would be a stronger document if the language was more consistent.

So as an English composition or a teaching aid, I only give the code of conduct a C+. But as a positive statement of intent to promote a collegial working environment, A+.

The kernel's code of conduct, one week later

johannbg — Tue, 02 Oct 2018 23:14:51 +0000

You can achive the point you are making without having to fragment but using multiple systems to maintain the origin comes at higher time cost due to the added complexity it brings.

If we use bug trackers as an example you need a single bug tracker as an origin and that bug tracker can have as many other bug trackers as can be imagine for as long as those bug trackers perform bi-directional communication amongst themselves to maintain that origin.

For example if an report is created in bug tracker at point of origin it will also be created at all or just the relevant sub-community bug tracker instance ( depending how this is setup ), any creation, state change,comment etc from the bug tracker at sub-community will also create,update etc report at the origin ( or pull/push model like used in dvs could be used ) .

The above is not fragmentation.

Fragmentation occures when there exist no bi-directional communication between bug trackers so if an report is created at origin the reporter is directed somewhere else to another bug tracker to create report there.

In addition to that, fragmentation exist in most peoples perception of time ( often used as false justification for having seperated instances from the origin, like seperated bug trackers ), in which it manifests itself by people putting more value on their time compared to others ( often via roles like developer vs reporter or doctor vs nurse etc which creates even further fragmentation and inevitable conflict ) when in fact we ( as in the entire human race ) are bound by the same amount of time, defined by the average lifespan of an human being.

Authority

neilbrown — Tue, 02 Oct 2018 00:02:05 +0000

> and more of a teaching aid.

I'm in favour of a document which serves as a teaching aid. I don't think the current CoC looks much like one.

I sometimes do volunteer work with children. The organizers include lots of training (some of it is a legal requirement) relating to providing a safe environment.
This is training for people who's intentions are good, but may have limited experience.
Things that stick in my mind are:
- "a side hug is a safe hug"
- "never be alone with a child"

These things may seem overly cautious, but when you don't know what another person's background is, it really is better to have simple rules like this than you always think it is safe to rely on your own judgement.

In the kernel community we might easily be interacting with people who have very different experiences and expectations and values that we do. Just saying that doesn't help a lot. Giving practical wisdom, like the above, can.
This is why I like "Address the code, not the coder". It is certainly no guarantee, and sometimes it might seem excessively cautious. But like the above, it is simple, and it is safe.
A CoC that give practical advise like this - a bit like checkpatch, but for human interactions - could be very valuable.

The kernel's code of conduct, one week later

ms-tg — Mon, 01 Oct 2018 18:06:52 +0000

> > There's this whole alternative universe to call you. Duh

> Would you please stop that. Just stop it.

Fascinating -- haven't we all just now observed a *real-world* example, right here in the comments of LWN, of the sorts of interactions that all of this discussion about the CoC have centered around?

From my observation of this discussion, I have the following questions:

(a) Is it abuse to extrapolate, in response to another poster's alternate history, "ad absurdum" alternate history?
(b) Is it abuse if, in doing so, one off-handedly refers to the other poster as a "genocidal monster", and expecting the context of an obvious, but not explicitly stated "ad absurdum" comment to excuse the insult as good humor?
(c) Is it abuse if, in such an exchange, one poster feigns to not understand such a context in order to render the other's comment as abuse? Did such feigning just occur, or was there a genuine misunderstanding of intent (possibly on my own part)?
(d) Is it abuse to repeatedly imply that the other has not read your comment, when a more generous interpretation would assume that they were responding to it?

After all the discussion had on the CoC -- I'd really love to see how the principles aspired to can be applied to this exchange?

The kernel's code of conduct, one week later

daniel — Mon, 01 Oct 2018 00:48:39 +0000

Linus needed to accept that embedding a bespoke tool astride the kernel development workflow was not going to end well. That point was controversial at the time, but with the clarity of historical perspective it is now settled fact. Instead of accepting that reality, Linus continued on the course of pushing the proprietary workflow further into the faces of those community members who could not accept it.

For the record, I was not the first to take exception to this ongoing encroachment. As I dimly recall, a group of us were discussing the Bitkeeper issue on the the #kernelnewbies channel, and I had taken the position that I could live with it, so long as I would be able to function as a kernel contributor without being forced to accept the Bitkeeper license. Then one of the channel members pointed out to me that Linus had just merged instructions for a "BK and Kernel Development Workflow" into the kernel source tree. It became immediately apparent that all of us who disagreed with the proprietary license were now well on the way to becoming second class citizens. That was a significant fraction of the community. I hope that you can see why I felt the need to do something.

Let me forestall the counterargument that I should really have been busy developing an alternative to Bitkeeper, as Linus suggested. I was doing exactly that, and I was not the only one. But I could not possibly have completed that work soon enough to present something usable to Linus, to stave off the looming disaster. And there were significant doubts about whether he would respond just by moving the goal posts in any case. Trying to read Linus's mind is a thankless task. In the end, Linus showed us how to do it: you need to be Linus. Then you just code up a quick prototype to show how you want it done and a team of talented coders descends on it to make it a reality.

As I said, we could have done the same in 2002 instead of 2005. It might have lacked the elegance of Monotone's content hashes but it would have done the same thing. The global distributed workflow that needed to be supported was already well understood, it already existed.

Maybe the result would have been even better than Git. Maybe it would have had cleaner commands, maybe it would have supported rename properly, who knows. That is speculation. But it is far from speculative to assert that we had the talent and manpower to do it. There was only one key ingredient missing: resolve from Linus.

If Linus had understood my message to him at the time, history would have taken a different and better course. I succeeded in getting his attention, but failed to convince him.

I hope that clarifies the historical context.

The kernel's code of conduct, one week later

daniel — Sun, 30 Sep 2018 23:49:43 +0000

I'm going to follow your lead and run away now. I composed a longish and potentially interesting post that would have gone here, then posted it to "drafts".

The kernel's code of conduct, one week later

nix — Sun, 30 Sep 2018 09:25:24 +0000

FWIW I would definitely have done nothing because my reaction to social conflict is to run away. (I'm not saying *this* would have been the right thing to do, either, but it would have had the same net effect on the path of future events, i.e. none to speak of.)

The kernel's code of conduct, one week later

nix — Sun, 30 Sep 2018 09:20:50 +0000

I... don't see how moving the BK documentation out of the kernel tree would have done all that, frankly, but I wasn't paying attention at the time so I probably missed some context.

Authority

daniel — Sun, 30 Sep 2018 01:19:00 +0000

Yes, +1 to you and Neil. But good conduct doesn't just happen, it requires individual effort. It is not something we are born with, at least, not most of us, but rather it is something we learn. Maybe it would be helpful to understand the Code of Conduct as less of a rule book and more of a teaching aid.

The kernel's code of conduct, one week later

bfields — Sat, 29 Sep 2018 20:57:32 +0000

For what it's worth, I think a lot of the language quoted from Linus and others was often intended that way.

When people are angry they sometimes go over the top in an odd attempt to soften the blow by taking it to the point of silliness. But that often backfires.

I think as a rule if you're angry or arguing with someone, it's better not to be insulting, even as a joke. They're probably not in a mood to get the joke.

This is an odd case, though, as it seemed so obviously silly from the start.

The kernel's code of conduct, one week later

mjblenner — Sat, 29 Sep 2018 14:02:16 +0000

While that's all true, the <<I'm specifically not calling you [insulting term]>> thing is really not cool.
(A specific example from an Australian Senator sticks in my mind)

The kernel's code of conduct, one week later

corbet — Sat, 29 Sep 2018 13:35:47 +0000

Daniel, the post was really just an amusing way of saying "we can't really know what would have happened had the kernel community not gone with BK". It was not meant, as far as I can tell, to be abusive in any way; surely you don't think anybody is really calling you a "genocidal monster"? The OP was just having fun running a fantasy to an extreme conclusion.

The kernel's code of conduct, one week later

daniel — Sat, 29 Sep 2018 09:17:50 +0000

> There's this whole alternative universe to call you. Duh

Would you please stop that. Just stop it.

The kernel's code of conduct, one week later

Cyberax — Sat, 29 Sep 2018 08:47:27 +0000

> Who is "we"? I thought that you are I and the rest of us were "we".
There's this whole alternative universe to call you. Duh. Since you're so fond of imagining what would have happened.

> You missed a lot of the story, did you even read my original post? I doubt you did. And please stop trying to be funny, it is entirely inappropriate in this context. Abuse is often cast in the form of a joke. I didn't get it.
Yes I have. Why do you assume that people don't read stuff?

In the original thread you've made a move that was absolutely and utterly disrespectful to core developers, like not even CC-ing Jeff Garzik (the doc author) when submitting their removal patch. Nice touch that.

So you got disrespect in return. Perfectly understandable.

> Perhaps you just need to decompress. My suggestion: go see what happened in the US capitol today. There are parallels.
Yes. But not the ones you're implying.

The kernel's code of conduct, one week later

daniel — Sat, 29 Sep 2018 07:36:40 +0000

> It would be interesting to have more info about the history of Git.

Well, I don't want to write a book about it right here and now. Most interested observers know that Linus got the idea of content hashing and other important ideas from Monotone:

https://lkml.org/lkml/2005/4/6/121

The main problem with Monotone was performance. Linus knew what to do about that. Monotone was the brainchild of Graydon Hoare. Incidentally, so is Rust. Quite the prolific, largely unsung inventor.

I knew Graydon from my time at Red Hat, where we both worked for Red Hat and met from time to time in the Toronto offices of the former Cygnus. Around that time, I was also casting around for a good design model for a distributed revision control system, as an alternative to Bitkeeper. I found Monotone, some months before the drama unfolded resulting in Linus's post above. Then, Monotone had no concept of directories, it only had a flat forest of objects with each content-hashed object indexed under the full path name.

One day in some dim hallway, possibly at Red Hat headquarters during a conference, I buttonholed Graydon and launched into a polemic about what I thought needed to be done to Monotone to make it truly useful. That was basically, elaborate the metadata design so that directories are objects too. Graydon initially found the idea offensive compared to what he perceived as his simpler and purer approach, but the next time I saw him, he informed me that he had in fact changed Monotone's metadata design along those lines, and Monotone's manifest was born. This is essentially what Linus found when he discovered Monotone a short time later.

Forgive me if I have erred slightly in some details, that was thirteen years ago. Graydon would probably be able to help me with this. Until now, he and I were the only two who knew this detail.

The story of how Git came to be is a whole lot more complicated than that. The real hero of the story is Andrew Tridgell, who set his brilliant mind to work on creating an open source Bitkeeper client. Though he did not intend it, a fact I can attest to from first hand knowledge, this work set in motion the chain of events that culminated in the author of Bitkeeper himself forcing Linus to do the right thing, and stop forcing the Linux kernel community to depend on a proprietary tool. Everybody knows the rest of the story, but these early events remain shrouded as a bit of a mystery.

For his efforts, Andrew (Tridge as we know him) was hounded out of the Linux kernel community in a most unseemly way. Linus should put that on his list of unfinished business that he needs to apologize for.

The kernel's code of conduct, one week later

daniel — Sat, 29 Sep 2018 06:53:43 +0000

May I also draw your attention to the main payload of my longish post above:

> How would you have done it better? I would like to know.

Honest question. What would you have done? Nothing, perhaps?

The kernel's code of conduct, one week later

daniel — Sat, 29 Sep 2018 06:48:39 +0000

> What else can we call you?

Who is "we"? I thought that you are I and the rest of us were "we". Rhetoric such as yours above is a textbook example of the exact opposite of collegial behavior.

Besides that, the words you attempt to put in my mouth, the analogy you attempt to draw, is wildly wrong. Please go back, read, understand. You missed a lot of the story, did you even read my original post? I doubt you did. And please stop trying to be funny, it is entirely inappropriate in this context. Abuse is often cast in the form of a joke. I didn't get it.

Perhaps you just need to decompress. My suggestion: go see what happened in the US capitol today. There are parallels.

The kernel's code of conduct, one week later

patrick_g — Sat, 29 Sep 2018 06:06:49 +0000

> this would be an appropriate moment to draw attention to the fact that the design of Git is not purely due to Linus. It is in large part due to Graydon Hoare, and partly due to me also, thought I doubt that Linus know that. Graydon does.

Could you please explain? It would be interesting to have more info about the history of Git.

The kernel's code of conduct, one week later

Cyberax — Sat, 29 Sep 2018 04:44:22 +0000

> You appear to have made your post without reading mine. I always wanted something like Git, after I came to understand the nature of distributed revision control. I played a significant part in achieving it. This is in no way consistent with your post.
I read it. It distinctly lacks any actual alternatives to BK. I was kinda following SVN development at that time (running pre-1.0 builds and all that) and I was looking at other VCSes. There was nothing really competitive with BK for decentralized development.

> Did you really just call me a genocidal monster? That would make you completely out of step with the notion of treating your colleagues with respect, and indeed, with reality. Perhaps you might wish to retract that.
Well, you've just doomed a whole alternative universe to a life under the totalitarian control of Microsoft. What else can we call you?

The kernel's code of conduct, one week later

daniel — Sat, 29 Sep 2018 01:22:56 +0000

You appear to have made your post without reading mine. I always wanted something like Git, after I came to understand the nature of distributed revision control. I played a significant part in achieving it. This is in no way consistent with your post.

Did you really just call me a genocidal monster? That would make you completely out of step with the notion of treating your colleagues with respect, and indeed, with reality. Perhaps you might wish to retract that.

Authority

rgmoore — Fri, 28 Sep 2018 23:53:22 +0000

I personally don't think we need a good "code of conduct" nearly as much as we need good "conduct".

I think it's helpful to have both. It's obvious that the people at the top of an organization serve as role models for the people further down, so good conduct by Linus will have a tremendously beneficial effect. But it's also useful for everyone to know what conduct is good and what is bad beyond that. Explicitly spelling out what is expected of community members should help to reinforce the leaders' modeling that behavior-- provided, at least, that the leaders actually follow their own rules.

The kernel's code of conduct, one week later

Cyberax — Fri, 28 Sep 2018 23:34:13 +0000

> In an alternate universe, Linus accepted my patch, the Bitkeeper documentation was moved out of the kernel source to some web page as I suggested, and we began to build Git in 2002 instead of 2005.
In another alternative universe Linux would have tried to use CVS and the just-released newfangled SVN to manage the source code. The strain of maintaining it would have alienated more and more developers, also taking a lot of developer time.

The continuous developer problems would have caused Linux to stagnate. Eventually companies like the nascent Google lost all the interest in it. By the end of 2004 most of Google servers were migrated to Microsoft Solaris (as Sun was acquired by Microsoft). Unfortunately, that allowed MS to exert significant pressure on Google and prevent them from displacing Microsoft on the Web.

From that everything else was inevitable. And so by 2020 only one large software company remained in the world, reigning over most of the industry with an iron fist.

Thank you for ruining the life of a whole alternative universe, you genocidal monster.

Authority

nix — Fri, 28 Sep 2018 21:53:43 +0000

> Especially as the kernel *already* had a CoC, in the form of the "code of conflict".
> Normally when some old code is removed and replaced by something else there is always an explanation in the changelog of *why* it was done.

The mechanism used to introduce this was clearly a bit of a CoC-up.

The kernel's code of conduct, one week later

daniel — Fri, 28 Sep 2018 21:48:34 +0000

> you were trying to remove the documentation on how to contribute to the kernel using BitKeeper from the kernel tree *while the kernel still used BitKeeper* and you were surprised that people thought that you had an agenda in doing so?

I notice that you did not call me a "hypocritical bastard" or a "wanker", nor ascribe any particular religion to me. Thank you. Linus and the other respondent could have managed the same, but apparently felt no compunction to do so at the time.

It is true that I had an agenda, I do not dispute that. I do dispute that my agenda was religious, or anything less than in the best interest of the whole community. My agenda was to prevent the community from splitting down the middle. Sadly, I failed. Linus failed. We all failed, and three years of avoidable disharmony ensued.

In an alternate universe, Linus accepted my patch, the Bitkeeper documentation was moved out of the kernel source to some web page as I suggested, and we began to build Git in 2002 instead of 2005. You could argue that we did not know how to build Git at the time, and I will argue that we were smart enough to do it even then. Maybe it would not have involved content hashes, who knows. In any case, this would be an appropriate moment to draw attention to the fact that the design of Git is not purely due to Linus. It is in large part due to Graydon Hoare, and partly due to me also, thought I doubt that Linus know that. Graydon does.

The Bitkeeper fiasco did not come about because of somebody being "controversial". It came about because of the very predictable collision between community and private interests. Not everybody recognized the inevitability of this at the time, but some did. Those voices were shouted down, and should not have been.

You could argue that my approach was overly dramatic. So how would you have gotten Linus's attention? How would you have done it better? I would like to know. Maybe, with 20-20 hindsight, we could of avoided a further three years of wasteful drama, including the unfortunate departure of respected and valuable contributors.

One thing you cannot argue is that my post was ill-intentioned. Anyway, thank you for not calling me a "bastard". I would also thank you not to denigrate my contribution to the community in this regard.

The kernel's code of conduct, one week later

flussence — Fri, 28 Sep 2018 16:21:43 +0000

Shoo, umarell.

The kernel's code of conduct, one week later

nix — Fri, 28 Sep 2018 12:38:16 +0000

Uhhh... you were trying to remove the documentation on how to contribute to the kernel using BitKeeper from the kernel tree *while the kernel still used BitKeeper* and you were surprised that people thought that you had an agenda in doing so? I mean, *obviously* you had one: someone with no agenda wouldn't have tried to do that in the first place.

The fact that the kernel was eventually forced away from BitKeeper because of precisely the sort of thing you were worried about doesn't mean that trying to remove the documentation about using BitKeeper from the kernel tree while it was still in active use was a sensible way to go about it. You were *trying* to be controversial. Obviously this narked people off, just as you clearly meant it to.

Authority

Thomas — Fri, 28 Sep 2018 09:01:22 +0000

> I personally don't think we need a good "code of conduct" nearly as much as we need good "conduct".
> People often copy what they see stronger people modeling.
> Compassion and forgiveness go a lot further than rules and regulations.

Hear, hear!

Thanks for adding common sense.

The kernel's code of conduct, one week later

marcH — Fri, 28 Sep 2018 07:14:31 +0000

> the German constitution says that when both federal and state law are applicable but contradictory, federal law wins

The US approach is different, it's based on smoking weed.

Couldn't resist, sorry.

https://en.wikipedia.org/wiki/Removal_of_cannabis_from_Sc...

The kernel's code of conduct, one week later

marcH — Fri, 28 Sep 2018 07:09:16 +0000

> It's not as if empathy towards specific individuals and reasonable skepticism about statistics in scientific papers were mutually exclusive. Both are to be encouraged

Yes but maybe not exert the latter *when* the former is expected?

The kernel's code of conduct, one week later

marcH — Fri, 28 Sep 2018 07:02:45 +0000

> Fragmentation in whole is bad so you dont want to have guidelines/rules/coding standards/documentation/bug trackers etc per sub-community and scattered across the internet because then for example you start waisting current and potential contributors time.

Fragmentation is bad; one size doesn't always fits all either. The kernel is big. Different (mandatory) coding standards for different components does waste time, whereas different bug trackers does not much and it can have some benefits.

The kernel's code of conduct, one week later

k8to — Fri, 28 Sep 2018 06:05:21 +0000

To use "SJW" is to attack sanity by forcing the dialogue to be about a fictional combatant.

You really need to review who you're associating yourself with and what ideas you're supporting, becuase they're not good.

The kernel's code of conduct, one week later

airlied — Fri, 28 Sep 2018 04:18:17 +0000

Whomever is posting repeated crap to lkml about the GPL under sock puppet email addresses doesn't seem to fit the SJW profile you've created of attackers, but that person is clearly attacking the Linux kernel, and is doing it from the shadows.

If this is a corporate takeover, please demonstrate the people you think will end up in charge?

though just go buy a tinfoil at and live the life you clearly dream about, also are you an active kernel contributor? how can you be a loyalist if not?