The kernel's code of conduct, one week later
It is worth starting with one important point that last week's article failed to mention: the new code of conduct is not actually new to the community as a whole. In particular, the DRM (graphics) subsystem adopted the freedesktop.org code of conduct in April 2017. This code, like the code for the kernel as a whole, is derived from the Contributor Covenant text. There have not been any problems of note arising from the use of this code in that subsystem to date. Your editor has been told that the DRM community's successful use of this code was a direct contributor to Torvalds's choice of this particular code as a starting point for the kernel.
One area of concern in the public discussion has been over the prohibition
of the posting of "private information", explicitly including email
addresses. Some maintainers read that as a prohibition against including
tags in patches, most of which contain such addresses. Some, like
Signed-off-by or Reviewed-by, are provided by the person involved and
should be relatively uncontroversial. Others, like Cc or Reported-by, are
likely to be added by a developer or maintainer. Unsurprisingly,
maintainers do not like the idea of unwittingly violating the code simply
by doing their jobs. Mauro Carvalho Chehab has argued this
point, saying: "We should solve this quickly, as otherwise maintainers may need to postpone
asking for pulling from any branches on trees that contain patches with
such tags
".
Those who have looked at the issue seem to be under the impression that, by posting an email to a public list, one has "published" one's own email address and it is no longer private information. This appears to be true even under some of the stricter privacy legislation found around the world. So the use of these addresses in patch tags would not appear to be problematic. Still, the prohibition as expressed in the code appears to be better suited to projects using online hosting sites rather than email for their patch flow. At some point, it would probably make sense to amend the code to clarify the intended rules.
Another area of concern is that the code places the responsibility for
enforcement on all maintainers. There are now numerous kernel maintainers
who never asked for this responsibility, and who lack a clear idea of what
they are actually responsible for. As Shuah Khan put
it: "I have to not only worry about the quality of code and
technical aspects, but also be responsible for behavior of individuals I
might not have any control or sway over
". Khan is not alone in
wondering what this requirement actually means for maintainership going
forward.
Those questions will be harder to answer. In a community as large as the kernel, the responsibility for enforcing the rules must necessarily be distributed across the maintainers. It is not up to one person (or some sort of elected board) to ensure that patches live up to the coding style rules or have proper signoffs. The same will have to be true for the kernel's conduct standards. But if the responsibility for calling out abusive behavior lies solely on the shoulders of the maintainers, it is easy to predict that maintainer turnover will increase in the future. If the community truly wants to be a more welcoming place, it will have to be up to all members to encourage each other toward better behavior when it is needed.
In truth, that encouragement is all that is needed a great deal of the time, and anybody can do it. If the more repressive measures envisioned in the code of conduct are invoked with any sort of frequency, something will have gone badly wrong. With any luck at all, most maintainers will never see anything requiring more than an admonition and a request for more attention in the future. For those who do run into something worse, the project as a whole will need to provide resources and support. Consulting with the Technical Advisory Board is one such resource, but it is likely to be insufficient.
There have been some suggestions for changes to the code of conduct already, and more are sure to come. The code is almost certain to evolve to better fit the kernel community, but the process by which that evolution can happen has not been worked out — or even thought about much. Future changes will require discussion and widespread acceptance; they cannot just be applied like the current code was.
In summary, there are a lot of questions, and many of the answers have yet to be worked out. Getting there will take some time. It seems likely that there will be significant discussion of the topic at the Maintainers Summit in October, but there may not be many hard answers coming from there. After 27 years, we still haven't finished bashing the kernel into shape; the code of conduct and its associated processes should come together rather more quickly than that, but some patience may still be required.
Finally, it is worth being aware of the fear, uncertainty, and doubt (FUD) attacks against the kernel community that the code has brought about. Some developers feel better about the code than others at this point, but their concerns are expressed in a rather different manner than the various trolling messages that have appeared on linux-kernel, and which have seemingly been taken seriously by the mainstream press. We are not in that much trouble, and we do not, for example, have actual developers asserting a hypothetical right to revoke the GPL licensing from their contributions.
Reading some of those emails (not to mention some of the unpleasant stuff
found on the wider Internet), it's hard not to feel that our community is
under attack from the outside. Hopefully those people will soon get bored
and go back to trying to stir up trouble elsewhere. To the extent that we
can encourage their departure by not responding to obvious trolling emails,
the better off we will be. As a community, we are far stronger than those
who would seek to tear us apart.
| Index entries for this article | |
|---|---|
| Kernel | Development model/Developer conduct |
Posted Sep 26, 2018 19:04 UTC (Wed)
by Tara_Li (guest, #26706)
[Link] (6 responses)
Is "our community" solely the kernel developer community? Or do the users' concerns have some weight on this matter?
Posted Sep 26, 2018 19:21 UTC (Wed)
by randomguy3 (subscriber, #71063)
[Link]
(1) if I'm a potential developer, it may well impact whether I become a developer in reality,
(2) if I think it will have a significant impact on the software itself (which is fairly unlikely - there are projects with smaller contributor bases where the community has completely split in two and yet the code base has survived and even flourished) or
(3) if there are serious ethical or reputational considerations (does it go against my or my culture's norms to the extent I don't wish to be associated with or support it in any way?)
I think a code of conduct would have to be pretty unusual to trigger (2) or (3) for most people.
Posted Sep 26, 2018 19:22 UTC (Wed)
by Paf (subscriber, #91811)
[Link]
Posted Sep 26, 2018 20:01 UTC (Wed)
by halla (subscriber, #14185)
[Link]
Of course not.
Posted Sep 26, 2018 20:39 UTC (Wed)
by johannbg (guest, #65743)
[Link]
All rules/guidelines are only applicable within that specific community so users will have to partake or engage in someform with that community to have any weight on the matter or fall under it's community rules or guidelines.
So if you as an user are in some form of active engagement with an community like some communication with the community ( through some of the communities official communication channels ) then you have effectively become a member of said community since you are providing ( contributing ) positive or negative feedback into it's environment.
So to put this into perspective.
if an user is sharing his opinion in some random corner on the internet or over coffee with his or her best friend he has no weight in the matter but if the user shares it with the community through any of it's community channels, the user has some weight in the matter since the user is engaging with the community thus has become it's member.
Posted Sep 27, 2018 13:34 UTC (Thu)
by kaesaecracker (subscriber, #126447)
[Link]
This is my personal opinion, you are free to disagree.
Posted Oct 14, 2018 16:36 UTC (Sun)
by demoryw (guest, #127897)
[Link]
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.
Posted Sep 26, 2018 19:45 UTC (Wed)
by Curan (subscriber, #66186)
[Link] (3 responses)
Posted Sep 26, 2018 20:03 UTC (Wed)
by halla (subscriber, #14185)
[Link] (2 responses)
Posted Sep 27, 2018 15:49 UTC (Thu)
by Curan (subscriber, #66186)
[Link] (1 responses)
NB: If I wanted to, I could feel offended by your comment, since one possible way to read it, is, that you're suggesting a severe lack of reading comprehension on my part. Now, if I apply the Debian CoC this problem goes away since I will then assume good faith and assume you might not have worded this perfectly. Under the CoC adopted by the kernel I could call this an "insulting comment".
I will apply the Debian CoC and say, that my original comment could have been more explicit in this regard. Even though the latter way of reading my comment might be the more obvious one, if one assumes, that I actually read the article I commented on (ie. if one assumes good faith).
Posted Oct 4, 2018 7:20 UTC (Thu)
by cpitrat (subscriber, #116459)
[Link]
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 ...
Posted Sep 26, 2018 19:49 UTC (Wed)
by johannbg (guest, #65743)
[Link] (13 responses)
This raise the question...
Is it not a bad thing if each sub-community has it's own set of rules/guidelines which may or may not exist in the parent community or may lead to contradiction ( or exemption ) to an existing one in the parent community which can lead to confusion ( similar to the inherent mess that the state laws are in the states )?
Posted Sep 26, 2018 23:18 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (10 responses)
Posted Sep 26, 2018 23:42 UTC (Wed)
by johannbg (guest, #65743)
[Link] (9 responses)
Posted Sep 26, 2018 23:57 UTC (Wed)
by airlied (subscriber, #9104)
[Link] (8 responses)
If you mean around other rules, well we have got coding standards and other rules we expect. Linus wrote git but not every subsystem maintainer uses it (akpm) and not every subsystem maintainer uses it consistently. Unilateral action is hard, but in some cases makes sense and can be done.
Posted Sep 27, 2018 17:38 UTC (Thu)
by johannbg (guest, #65743)
[Link] (7 responses)
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. A time that most communities either dont have or cannot afford.
Posted Sep 27, 2018 19:11 UTC (Thu)
by jani (subscriber, #74547)
[Link]
Due to the freedesktop.org infrastructure the DRM subsystem was de facto operating under the freedesktop.org code of conduct anyway, so formalizing it in DRM subsystem documentation was a natural progression. (And even so, more than two dozen acks by maintainers and developers were sought before committing.)
Posted Sep 28, 2018 7:02 UTC (Fri)
by marcH (subscriber, #57642)
[Link] (5 responses)
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.
Posted Oct 2, 2018 23:14 UTC (Tue)
by johannbg (guest, #65743)
[Link] (4 responses)
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.
Posted Oct 4, 2018 3:43 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (3 responses)
- 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?
Posted Oct 4, 2018 6:09 UTC (Thu)
by johannbg (guest, #65743)
[Link] (2 responses)
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. . .
Posted Oct 4, 2018 7:03 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
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.
Posted Oct 4, 2018 7:27 UTC (Thu)
by johannbg (guest, #65743)
[Link]
Posted Sep 27, 2018 3:04 UTC (Thu)
by summentier (subscriber, #100638)
[Link] (1 responses)
True, but there is a simple way to fix this: have the global Linux C.o.C. take precedence whenever there is a conflict. Ideally, the global C.o.C. would set some ground rules, and then the communities could expand on or clarify if necessary.
(Because you mention federal vs. state law: the above is basically the way the legal system is set up in Germany -- the German constitution says that when both federal and state law are applicable but contradictory, federal law wins.)
Posted Sep 28, 2018 7:14 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
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...
Posted Sep 26, 2018 20:02 UTC (Wed)
by simosx (guest, #24338)
[Link]
The purpose of the CoC is that if bad behavior is during the development of the kernel, there is a process to take care of it and people would not have to deal with it. That you would view the unfortunate bad behavior but you would be confident it will be dealt with.
Posted Sep 26, 2018 20:39 UTC (Wed)
by zblaxell (subscriber, #26385)
[Link] (23 responses)
I am wondering how enforcement of the code of conduct could work given the way the Linux kernel works. As any mail administrator knows, it's not like you can stop people from sending abusive comments (or advertising or anything else) via email. LKML is a magnet for gigabytes of undesirable content, much of which we never see because it gets eaten by giant spam filters.
Other projects have central points of failure^H^H^H^H^H^H^H^H control where e.g. an abusive user's account can be deactivated. In Linux, nobody has accounts in the first place, and nobody is interested in changing that.
> if the responsibility for calling out abusive behavior lies solely on the shoulders of the maintainers, it is easy to predict that maintainer turnover will increase in the future
Maintainers can ignore the abusive behavior, ask nicely for the abuse to stop, stop inviting abusers to conventions and social events, or escalate to public authorities. They most likely do a lot of that already given the aforementioned total absence of accounts and access controls.
People who run mailing lists, archives, bug trackers, and similar facilities may now be obligated to do extra filtering work. Anyone who controls access to something like github or kernel.org now has additional justifications for banning abusive people (on top of the usual spam and resource misuse mitigation they already have to implement). Since there are many more spammers than abusive contributors, the extra workload imposed by the CoC should be negligible there.
In the extreme, "ignoring abusers" could extend to rejecting patches which, although correct and necessary, are authored or tagged by designated abusive persons. That's no big deal for patches that have not been pulled (being too abusive tends to prevent that anyway), but if it's applied extremely, literally, and retroactively, it could mean removing reiserfs from the kernel. That scares people because it's the same problem as with patents--code is not acceptable because of who wrote it, not because of any issue with the code itself.
While I'm all for removing reiserfs from the kernel, it's because reiserfs is slow and buggy and nobody should be using it for new deployments, not because reiserfs contains code written by at least one known murderer. I don't expect reiserfs to be removed as a result of the CoC because it was co-written and has been maintained by non-murderers for some years now, and the code is useful and does not promote an ideology (it used to, but that was edited out years ago).
Statistically, any project with as many contributors as Linux should expect to have patches from 0.9 to 1.8 murderers (depending on distribution of nationality). What we have now is a document that says their pull requests may be ignored, and maybe their use of the Reviewed-By tag will be ignored, and they may have a slightly harder than average time trying to get attention on mailing lists.
The CoC means very different things for an abusive contributor (one who submits patches via email and can be simply spambucketed) and an abusive maintainer (one who selects which patches are pulled, and must in turn be selected by a higher-level maintainer, and ultimately transitively accepted by Greg or Linus). The interior nodes of the maintainer tree are where the impact is most likely to be significant, as that's where the "person is/is-not going to be a contributor today" decision gets made.
Posted Sep 26, 2018 22:02 UTC (Wed)
by rengolin (guest, #48414)
[Link] (20 responses)
I don't think the problem is with the community at large, but how the maintainers themselves echo the abuse.
One thing is an irrelevant wannabe developer or a user shouting at the LKML, which will very likely be ignored by all.
Another completely different thing is maintainers (of any capacity) telling people they should not have been born because of their seemingly "bad code".
I hate bad code as much as the next guy, but I can understand that the definition is mostly a normalisation process by peer review of trusted developers.
I have seen *really* bad code in the kernel, done by a top-level maintainer, have complained about and been told it would stay. I didn't need to abuse said developer in any way, and years later, I've been told the code has been cleaned.
In summary, most of the abuse is done by irrelevant people, which most ignore. But the really harmful abuse is done by relevant developers / maintainers, who have a huge amount of work to do, and little time to know where in the { "think outside the box" - "plain old bs" } spectrum every weird patch is.
I understand their predicament, I really do. I'm a maintainer myself (LLVM), but I realised speed != haste also when it comes to code review and weeding out bad code.
Being pragmatic is more constructive and effective than flat out refusing to talk / being abusive to "teach them a lesson". Refusing to accept patches is not nice, but way nicer than being abusive.
If the CoC manages to fix that problem, however small it has become, it's a win. If it introduces new problems (which some do), then it needs revision.
Posted Sep 28, 2018 2:42 UTC (Fri)
by daniel (guest, #3181)
[Link] (19 responses)
I will provide a concrete examplet. Here, Linus calls me a "hypocritical bastard with a religious agenda": https://lkml.org/lkml/2002/4/20/83
And here, a maintainer repeats it: https://lkml.org/lkml/2002/4/20/79
Did it hurt? You bet it did. It still does to this day. Never mind that three years later, the position I had taken which triggered that unseemly ad hominem attack, was proved correct.
Posted Sep 28, 2018 12:38 UTC (Fri)
by nix (subscriber, #2304)
[Link] (18 responses)
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.
Posted Sep 28, 2018 21:48 UTC (Fri)
by daniel (guest, #3181)
[Link] (17 responses)
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.
Posted Sep 28, 2018 23:34 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (12 responses)
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.
Posted Sep 29, 2018 1:22 UTC (Sat)
by daniel (guest, #3181)
[Link] (11 responses)
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.
Posted Sep 29, 2018 4:44 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (10 responses)
> 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.
Posted Sep 29, 2018 6:48 UTC (Sat)
by daniel (guest, #3181)
[Link] (6 responses)
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.
Posted Sep 29, 2018 8:47 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
> 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.
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.
Posted Sep 29, 2018 9:17 UTC (Sat)
by daniel (guest, #3181)
[Link] (1 responses)
Would you please stop that. Just stop it.
Posted Oct 1, 2018 18:06 UTC (Mon)
by ms-tg (subscriber, #89231)
[Link]
> 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?
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?
Posted Sep 29, 2018 13:35 UTC (Sat)
by corbet (editor, #1)
[Link] (2 responses)
Posted Sep 29, 2018 14:02 UTC (Sat)
by mjblenner (subscriber, #53463)
[Link]
Posted Sep 29, 2018 20:57 UTC (Sat)
by bfields (subscriber, #19510)
[Link]
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.
Posted Sep 29, 2018 6:53 UTC (Sat)
by daniel (guest, #3181)
[Link] (2 responses)
> How would you have done it better? I would like to know.
Honest question. What would you have done? Nothing, perhaps?
Posted Sep 30, 2018 9:25 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Sep 30, 2018 23:49 UTC (Sun)
by daniel (guest, #3181)
[Link]
Posted Sep 29, 2018 6:06 UTC (Sat)
by patrick_g (subscriber, #44470)
[Link] (1 responses)
Could you please explain? It would be interesting to have more info about the history of Git.
Posted Sep 29, 2018 7:36 UTC (Sat)
by daniel (guest, #3181)
[Link]
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.
Posted Sep 30, 2018 9:20 UTC (Sun)
by nix (subscriber, #2304)
[Link] (1 responses)
Posted Oct 1, 2018 0:48 UTC (Mon)
by daniel (guest, #3181)
[Link]
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.
Posted Sep 26, 2018 23:17 UTC (Wed)
by roc (subscriber, #30627)
[Link] (1 responses)
Like spammers, they create new accounts. Intentionally disruptive people are not a new problem, they are not specifically related to codes-of-conduct and they are something all projects, including the kernel, have always had to deal with. Deliberate flouters of codes-of-conduct are just another kind of intentionally disruptive person. (*Accidental* flouting can usually be resolved to everyone's satisfaction.)
It's very rare to have someone who is intentionally disruptive and also making some meaningful contribution. I've never seen a case at Mozilla where it would have been worth taking their contribution.
I think there is a good point to be made here, though: explicit or implicit codes-of-conduct do not, unfortunately, eliminate the need to be quite thick-skinned in very popular open-source projects. Firefox Bugzilla has always had a steady stream of new users showing up to throw abusive comments at developers. It sucks, but I guess it's not that different to other open online communities.
Posted Sep 27, 2018 5:20 UTC (Thu)
by k8to (guest, #15413)
[Link]
In this one though, this isn't a relevant consideration.
Posted Sep 26, 2018 22:05 UTC (Wed)
by psymin (guest, #127492)
[Link] (16 responses)
https://www.youtube.com/watch?v=nND3EYzIONg
Here is ESR's take:
http://esr.ibiblio.org/?p=8139
There are calls already to eject people from the community:
My opinion is that the worst part of this change is that it polices actions *outside* of the community itself. Look at what happened with Opal
https://github.com/opal/opal/issues/941
The person accused wasn't representing the project, but did have info in his twitter bio about it. Policing actions in this manner to suppress speech and/or eject people from the community is not a great idea.
Posted Sep 26, 2018 22:52 UTC (Wed)
by agrover (guest, #55381)
[Link] (12 responses)
Nope. Nope. Nope. This is questioning if someone with such views should be in a position of enforcing the CoC by virtue of being on the TAB.
Posted Sep 26, 2018 23:29 UTC (Wed)
by psymin (guest, #127492)
[Link] (7 responses)
Posted Sep 26, 2018 23:54 UTC (Wed)
by raof (subscriber, #57409)
[Link] (6 responses)
Posted Sep 27, 2018 0:05 UTC (Thu)
by agrover (guest, #55381)
[Link]
Posted Sep 27, 2018 0:07 UTC (Thu)
by psymin (guest, #127492)
[Link]
Posted Sep 27, 2018 9:24 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (3 responses)
AFAIK Ted Ts'o has expressed doubts about the statistics and methodology in some studies put forward in a discussion about rape incidence. How that implies that “he's unlikely to be sympathetic to a report by a woman suffering sexual harassment” is unclear to me. 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. And it is never wrong to be interested in the facts.
Posted Sep 27, 2018 14:38 UTC (Thu)
by k8to (guest, #15413)
[Link]
It's accurate, even if it's not initially obvious.
Posted Sep 27, 2018 17:17 UTC (Thu)
by johannbg (guest, #65743)
[Link]
Why is Ted supposed to be sympathetic and why is his credibility in question if he is not the accused in the matter?
Is he not allowed by community members to do his own research,form his own opinions based on his own beliefs and perceptions on these topics as any other, or are individuals perceptions supposed to be fixed on certain topic?
Also is not the TAB supposed to be neither biased or sympathetic to either party but review the facts since they are the judge,jury and potential ( career ) executioners over the accused individual?
And what if the individual is falsely accused? What happens to the accusee then?
Will the deciding and enforcing party set the record straight if the accused indvidual is being publicly
Posted Sep 28, 2018 7:09 UTC (Fri)
by marcH (subscriber, #57642)
[Link]
Yes but maybe not exert the latter *when* the former is expected?
Posted Sep 26, 2018 23:41 UTC (Wed)
by gus3 (guest, #61103)
[Link] (3 responses)
So, he resigned, rightfully claiming that, "under the present circumstances, I cannot be an effective leader." And I supported this move. I still do.
Brendan Eich endorsed intolerance, enforced not through a CoC, but rather with the force of law. I have no problem with his endorsement, but I can't reconcile that with any Free Software leadership position.
Posted Sep 27, 2018 5:26 UTC (Thu)
by k8to (guest, #15413)
[Link] (2 responses)
I just am unsure that there's a fundamental conflict, despite how much I am not excited about interacting as peers or leaders with someone who is willing to take such a drastic step.
As far as being a leader of a company, I feel rather differently. Company executives hold a great deal more power over their employees than free software project leaders do over contributors. I think it's totally reasonable that a leader who takes actions that strongly clash with the values of a company is questioned and possibly rejected by the employees.
Posted Sep 27, 2018 5:54 UTC (Thu)
by roc (subscriber, #30627)
[Link] (1 responses)
Posted Sep 27, 2018 11:10 UTC (Thu)
by gus3 (guest, #61103)
[Link]
Eich's endorsements hurt the Mozilla brand, by engendering conflict about Eich himself.
Posted Sep 27, 2018 2:32 UTC (Thu)
by psymin (guest, #127492)
[Link]
Posted Sep 27, 2018 3:02 UTC (Thu)
by timrichardson (subscriber, #72836)
[Link] (1 responses)
Posted Sep 27, 2018 15:36 UTC (Thu)
by jond (subscriber, #37669)
[Link]
Posted Sep 26, 2018 22:50 UTC (Wed)
by vadim (subscriber, #35271)
[Link] (15 responses)
I think there would be far less drama if he had stuck around to explain what exactly it means, how it will be enforced, how the different parts will be interpreted, and perhaps to make amendments and clarifications in response to feedback.
Without some authority to explain things, wild guesses and paranoia are starting to proliferate. Perhaps it would have been better to leave this matter until his return.
Posted Sep 27, 2018 0:30 UTC (Thu)
by corbet (editor, #1)
[Link] (14 responses)
Whenever you see "wild guesses and paranoia", it's good to look at the source and ask yourself if this stuff is really coming from inside the community. There is an awful lot coming from people who otherwise have nothing to do with the kernel.
Posted Sep 27, 2018 1:16 UTC (Thu)
by ruscur (guest, #104891)
[Link]
This isn't the type of thing that should be rushed, so I think a lot of the reason there is so much concern is because it *has* been rushed.
In any case, if anyone wants to lose some hope for humanity, take a look at the comments on GitHub, where Linux development does not take place, by a bunch of people largely unaware of that.
https://github.com/torvalds/linux/commit/8a104f8b5867c682...
Posted Sep 27, 2018 2:37 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (8 responses)
Posted Sep 27, 2018 12:10 UTC (Thu)
by mfuzzey (subscriber, #57966)
[Link] (1 responses)
I think it was a good thing that Linus announced that he intends to improve his "conduct", even though in reality, and especially in recent years, it has rarely been a problem (most of those pointing out his "poor conduct" keep repeating the same handful of cases - most of them years old).
However saying "I've been rude in the past, sorry, and will improve now" is one thing, as it only *directly* concerns Linus himself, though hopefully it will have beneficial trickle down effects.
Especially as the kernel *already* had a CoC, in the form of the "code of conflict".
Of course Linus *can* commit anything he likes to his tree but that's not the way things normally work so I think it's quite normal that people are surprised and a little concerned when that happens.
Posted Sep 28, 2018 21:53 UTC (Fri)
by nix (subscriber, #2304)
[Link]
The mechanism used to introduce this was clearly a bit of a CoC-up.
Posted Sep 28, 2018 9:01 UTC (Fri)
by Thomas (subscriber, #39963)
[Link] (4 responses)
Hear, hear!
Thanks for adding common sense.
Posted Sep 30, 2018 1:19 UTC (Sun)
by daniel (guest, #3181)
[Link] (3 responses)
Posted Oct 2, 2018 0:02 UTC (Tue)
by neilbrown (subscriber, #359)
[Link] (2 responses)
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.
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.
Posted Oct 3, 2018 0:18 UTC (Wed)
by daniel (guest, #3181)
[Link] (1 responses)
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+.
Posted Oct 4, 2018 9:27 UTC (Thu)
by codeofdrama (guest, #127444)
[Link]
"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?
Posted Sep 28, 2018 23:53 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
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.
Posted Sep 27, 2018 14:24 UTC (Thu)
by martin.langhoff (subscriber, #61417)
[Link] (2 responses)
The leaders might be the problem, many high-functioning technical folks are not high-functioning in empathy (including me!), and they just lack experience in dealing with such situations. It's not a recipe for success.
Instead, I picture a board setup by Software Freedom Conservancy or similar non-profit, offering to have an advisory role to FOSS projects that agree to delegate CoC conflict resolution to them. We do something similar already for accounting and bank accounts for donations and money for sponsorships...
Posted Sep 27, 2018 14:42 UTC (Thu)
by corbet (editor, #1)
[Link] (1 responses)
Posted Sep 27, 2018 16:36 UTC (Thu)
by martin.langhoff (subscriber, #61417)
[Link]
For example, SFC keeps money and does accounting on behalf of FOSS projects that _could_ do it themselves. But I remember the era of conflict in FOSS projects over $150 in money for DNS and hosting. That's mostly gone - in part thanks to sourceforge/github/gitlab, and in part thanks to SLC.
Today, many projects have slightly more interesting amounts of money, and disburse it in sponsorships for conference attendance, etc; and there's almost no problem.
Could they do their own accounting -- probably? Is it best left to professionals who are less invested?
To be clear, let me emphasize the _advisory_ aspect of the role I am suggesting, and that such an organization would have to earn its trust (as SLC has done) over time, with even-handed solutions to actual conflicts brought to its inbox.
Anyway, just an interesting tool, for more than interesting times.
Posted Sep 28, 2018 0:33 UTC (Fri)
by daniel (guest, #3181)
[Link]
This statement creates the appearance that you advocate against leadership from Linus, in this specific case.
Posted Sep 27, 2018 5:31 UTC (Thu)
by mcchinsy (guest, #120114)
[Link] (5 responses)
Please cancel my subscription to you. I do not support your purple-hair version of Linux. Thank you.
Tim
Posted Sep 27, 2018 10:08 UTC (Thu)
by risimmonsuk (guest, #92394)
[Link] (3 responses)
What does this even mean?
> Please cancel my subscription to you.
I think this wins the prize for the most inappropriately reactionary comment to an article. Well done.
Posted Sep 27, 2018 11:22 UTC (Thu)
by excors (subscriber, #95769)
[Link] (2 responses)
Posted Sep 27, 2018 13:31 UTC (Thu)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Oct 3, 2018 14:27 UTC (Wed)
by jubal (subscriber, #67202)
[Link]
Posted Sep 28, 2018 2:46 UTC (Fri)
by daniel (guest, #3181)
[Link]
Posted Sep 27, 2018 8:53 UTC (Thu)
by cdamian (subscriber, #1271)
[Link] (3 responses)
I looked for a CoC for LWN, but couldn't find it. (Except the "try to be polite, respectful, and informative").
Posted Sep 27, 2018 9:28 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (1 responses)
What more do you need?
Posted Sep 27, 2018 9:42 UTC (Thu)
by cdamian (subscriber, #1271)
[Link]
Posted Sep 28, 2018 2:54 UTC (Fri)
by daniel (guest, #3181)
[Link]
Posted Sep 27, 2018 10:32 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (2 responses)
Because the way that humans behave is less complex and easier to debug than the way computers behave? :-)
Posted Sep 27, 2018 13:08 UTC (Thu)
by peter-b (subscriber, #66996)
[Link]
Posted Sep 27, 2018 16:36 UTC (Thu)
by hkario (subscriber, #94864)
[Link]
Posted Sep 28, 2018 0:57 UTC (Fri)
by mcchinsy (guest, #120114)
[Link] (3 responses)
Here's your plea:
"Reading some of those emails (not to mention some of the unpleasant stuff found on the wider Internet), it's hard not to feel that our community is under attack from the outside. Hopefully those people will soon get bored and go back to trying to stir up trouble elsewhere. To the extent that we can encourage their departure by not responding to obvious trolling emails, the better off we will be. As a community, we are far stronger than those who would seek to tear us apart."
So, engaging in conspiracy theories, are we?
Your "community" is indeed "under attack from the outside." It's the SJW warriors that are attacking, not the loyalists like me.
It's well apparent now that Linux is dead. This is a corporate takeover, plain and simple. Good riddance to you, Sir. I will NEVER support this.
Let's see if this post stays more than 5 minutes.
Posted Sep 28, 2018 4:18 UTC (Fri)
by airlied (subscriber, #9104)
[Link]
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?
Posted Sep 28, 2018 6:05 UTC (Fri)
by k8to (guest, #15413)
[Link]
You really need to review who you're associating yourself with and what ideas you're supporting, becuase they're not good.
Posted Sep 28, 2018 16:21 UTC (Fri)
by flussence (guest, #85566)
[Link]
The kernel's code of conduct, one week later
> unpleasant stuff found on the wider Internet), it's hard not to
> feel that our community is under attack from the outside.
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
I'm still not understanding why this particular CoC was chosen and not, say, the Debian CoC. That would have been far less contentious IMO. Maybe there's still a chance to get such a CoC adopted instead.
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
bug tracker fragmentation
bug tracker fragmentation
bug tracker fragmentation
bug tracker fragmentation
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
What I am reading from the discussion on LKML is that some people consider it would be a daily concern.
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
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 kernel's code of conduct, one week later
The kernel's code of conduct, one week later
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.
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
The kernel's code of conduct, one week later
There's this whole alternative universe to call you. Duh. Since you're so fond of imagining what would have happened.
Yes I have. Why do you assume that people don't read stuff?
Yes. But not the ones you're implying.
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
(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?
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
The kernel's code of conduct, one week later
(A specific example from an Australian Senator sticks in my mind)
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
This seems to becoming a classical pattern in people arguing against a CoC: they ignoring the actual content of what people are saying and instead substitute their own cataclysmic assumptions about people mean.
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
having someone who has given the impression by his words and arguments that he's unlikely to be sympathetic to a report by a woman suffering sexual harassment on the board that adjudicates complaints
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
( in addition to any maintainer apparently "Maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful. )
executed in the community or on blog post, news article etc?
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The thing is, that stuff isn't up to Linus in the first place; as far as I can tell, he doesn't want to have to deal with it. It's up to the community to figure out and the TAB to implement. We will figure it out in a way that doesn't trash our community. We have spent almost three decades building it, and we're not going anywhere.
Authority
Authority
Authority
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.
Authority
Whereas introducing a CoC that creates new rules and responsibilities (especially for maintainers) and raises a lot of issues is quite a different thing.
That it was done in a rush, without discussion, apparently even among maintainers who are the most impacted, seems very strange and contrary to the way the kernel development process normally works.
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.
Authority
> 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.
Authority
> People often copy what they see stronger people modeling.
> Compassion and forgiveness go a lot further than rules and regulations.
Authority
Authority
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"
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.
Authority
Link to kernel code of conduct for convenience: https://git.kernel.org/pub/scm/linux/kernel/git/stable/li...
Authority
Authority
I personally don't think we need a good "code of conduct" nearly as much as we need good "conduct".
Authority
Some people have suggested that, in the long term, the TAB is not the right body to be handling CoC issues; it may be that a separate group is set up at some point. But I think that outsourcing such things to a group outside the kernel community entirely would be a fraught exercise; honestly, I don't see that happening. As a community, we are not so challenged that we can't figure this out, IMO...
Authority
Authority
Authority
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
gamergate never died, apparently :-(
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
"Wider Internet"
This might just me being not good at finding stuff.
"Wider Internet"
Except the "try to be polite, respectful, and informative"
"Wider Internet"
"Wider Internet"
The kernel's code of conduct, one week later
After 27 years, we still haven't finished bashing the kernel into shape; the code of conduct and its associated processes should come together rather more quickly than that
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later
The kernel's code of conduct, one week later