Open Letter to the Emacs Maintainers
medium.com> thevast majority of modern software developers do not want to use email as their communication channel
Wait. What? I must be old school then, with my ~12 years of experience, because I think email is much more approachable than some of the modern communication methods. I create text and send it in an email. I get an email back. Repeat until complete.
Or do people really think it's better to go out and sign up for yet another account with Slack (or is that Github? Or Discourse? Or HipChat? Or BitBucket? or...), verify my email (ironic, no?), get into a chat room, try and get a dev's attention in the rolling spam of giffy links... Or perhaps I'll create yet another gitlab issue and pull request, so they can get lost in the thousands of others, due to the lack of organization capability present in most email clients. Yeah, I prefer email, personally.
> the Old Guard and the Next Generation
An excellent way to alienate the people you're trying to get help from.
> put a Code of Conduct in place for all communications on gitlab.
Sigh. This again?
> If Emacs could move onto gitlab and use a pull request workflow
What real benefits does this offer, over an email patch?
If this is the "New Guard", perhaps it's best they are scared away by email.
Regarding the "code of conduct" fad/trend, I don't understand where it came from or what problem it's trying to solve. I suspect that I might be sympathetic to their goals, if the "code of conduct" people did a better job of explaining them, but they just seem to take the necessity of this practice for granted. I therefore assume that the cultural conversation which produced the idea must have taken place in some venue unknown to me, and the "code of conduct" therefore largely functions as a shibboleth - these are clearly not my people, whoever they are, because they clearly don't consider me to be one of theirs.
Also, I hate the pull request workflow; it's a big barrier to entry for people dipping their toes in with small changes. If you're trying to recruit more participants, or encourage an open-source project to open itself up to more participants, why on earth would you adopt a workflow which requires more up-front folderol on the part of the patch submitter? Just let people send in their patches and be gracious about accepting them. You can gently suggest that they start jumping through git branching hoops and other project-specific processes later, when they're already on board and committed to participation.
Are you serious or arguing insincerely? I can't tell.
Codes of conduct are a direct response to ongoing harassment and stalking against various contributors of various open-source projects, followed by inaction on the part of the project maintainers or the excuse of "that just can't handle criticism".
What is so offensive about saying "make it about the code, not about the person" and "don't stalk, dox, or harass people"?
A code of conduct is a signal that juvenile behavior won't be tolerated and that if your code reviewer starts sending you dick pics they'll get banned from the project. It doesn't do anything by itself - if the project maintainers don't follow through it is worthless but like security lights and door locks the signaling value has an effect on people's behavior.
And for the record it protects while males too.
I'm not the parent poster, but will post anyway. I really don't want to get into this discussion, which is kind of ironic because the reason I don't want to get into the discussion is the very reason codes of conduct are purported to exist. It is very easy to become targeted and vilified if you happen to have a different point of view on the subject.
A very common clause in codes of conduct is that people who are identified with a project must uphold the code of contact when they are communicating, even when they do so outside the context of the project. Usually "identified with a project" is defined loosely enough that it can be used fairly indiscriminately. It has happened that people who voiced objectionable ideas outside the context of a project have been forcibly removed from those projects.
For some, this is a triumph of justice. For others (and I include myself in this camp) it is further fostering an "us" vs "them" viewpoint, vilifying those whose ideas differ. Interpersonal conflict is difficult and requires considerable skill to moderate. A code of conduct, while it can simply be a communication of the ideals that the project strives towards, can be used as a scaffolding to attack those who we disagree with and wish to punish.
He's quite sincere, and there are others of us who agree. Codes of conduct are a flavor of the month, and they don't achieve anything. I don't need to pre-announce that I will not accept patches from murderers or pedophiles, I can simply do it. The same is true for the types of offenses typical of a code of conduct.
Perhaps it is generational, and the new guard will eventually win this battle one funeral at a time. But as a politically liberal curmudgeon, 'codes of conduct' feel like the beta release of 'safe spaces'.
please go back to Pokemon Go-ing on my lawn... quietly. Daddy has to focus on writing code.
>Codes of conduct are a flavor of the month, and they don't achieve anything
In other words you've never felt harassed. That's a good thing but it doesn't mean your situation is all encompassing.
>The same is true for the types of offenses typical of a code of conduct.
Also a good thing. How many times have you rejected a patch because someone was harassing another member of your community?
I support codes of conduct, for multiple reasons stated and not in this thread.
I do not support putting words into someone else's mouth, particularly on socially explosive (hence the discussion in the first place) or ideologically driven issues.
Asking if someone's ever been harassed is one thing. Stating point blank that they haven't, crosses a line. Your interlocutor knows their personal history. You don't. Don't presume. It's a cheap shot, often derailing.
You're right.
He says "Codes of conduct" don't work and your response is this?:
>In other words you've never felt harassed.
Do you fail to see the problem here?
>Also a good thing. How many times have you rejected a patch because someone was harassing another member of your community?
Does one need a written down, politically charged, potentially divisive document in legalese to say "I don't want to share my toys with the class bully"?
He said codes of conduct don't achieve anything. The only way to believe that is to have never felt harassed. So no I don't see the problem.
>Does one need a written down, politically charged, potentially divisive document in legalese to say "I don't want to share my toys with the class bully"?
Apparently yes given the number of abusive people that have been active members of a lot of communities which now have codes of conduct.
> The only way to believe that is to have never felt harassed.
Try believing that I could have been harassed, but feel that a code of conduct would not have prevented nor resolved the problem.
I've tried and I can't. Could you please share what happened to help me understand?
I suspect this discussion has now ceased to be useful to anyone. I'm more or less certain that you are now 'white knight' and 'question trolling'. I find it equally frustrating that you are 'concerned' about 'feeling' harassed, not 'being' harassed. I'm suspect you view me through a similarly narrow filter.
But hey, https://xkcd.com/386/
I did not say anything about 'what happened', I was speaking of 'belief' which was part of your sentence.
I'm not claiming I've been harassed, nor am I denying it. I find the term a bit vague, as it runs a spectrum from minor trolling which I think we've nearly all experienced (and perhaps committed), to real world doxing and stalking and physical violence. So let's pick something much more concrete.
Rape. Since even that has a somewhat ill defined colloquial use, I'll specifically restrict to a narrow and somewhat historic subset: The act of a man forcing coitus upon a woman.
There is recent precedent for this in the Tor community. I don't know enough of the specifics of that to claim my hypotheticals reflect any of the reality of that case, but I think it's a useful way to make this seem less abstract.
I don't believe that the Tor project had a specific 'code of conduct'. Despite that, they seem to have been able to report appelbaum's behavior as inappropriate, and remove him from the project. This suggests a CoC is not a requirement -- it is not necessary. Does anyone claim a CoC would have prevented those events from happening? -- it is not sufficient.
Let's imagine that there was a CoC. I don't think any of the CoCs I've seen specifically mention rape (nor murder or pedophilia - my original examples). I find it hard to believe that there was (or even could be) a woman who was ready to contribute to Tor, but due to previous experience with rape, and the lack of it being mentioned in the CoC, decided this was not an environment where she was welcome.
trigger warnings, safe spaces, and codes of conduct have all become strangely familiar https://en.wikipedia.org/wiki/PCU_(film) , but bland ways of marking some tribal identity. But they do not seem to actually achieve any of their stated goals.
I've previously been involved in organizing one tech conference, where a single member of the admin board felt it was urgent that we nail this down, and it became a time consuming and long recurring part of our calendar, which to my mind achieved little beyond bike shedding. None of us are strongly opposed to the core idea. We do want a healthy vibrant community. But if that's all we wanted, we'd have joined some other social forum, be it a book club, a sports team, or whatever suits you. Instead we joined a code base, a conference or some other technology focused community, and advancing that specific goal is actually priority #1. To the extent a community helps us to advance that goal, wonderful. But to the extent that certain members of that community actively hurt progress, we're glad to see them excluded. Sometimes we decide that exclusion is necessary due to social practices like criminal activity ( Hans Reiser ) sometimes it's due to some (race/sex/other)-ism which is taboo. But one of the great things about the way we do online collaboration ( https://en.wikipedia.org/wiki/On_the_Internet,_nobody_knows_... ) is that I've gotten to meet and collaborate with a lot of people who are WAY outside my usual social bubble. And it's allowed me to build a tolerance and respect for people who I would otherwise have probably dismissed too early. Satanic polytheist -- have you seen his filesystem API? Blind transexual with a diaper fetish - built that 9 dimensional rubics cube app in 4k of assembly. CoCs set a dangerous precedent of deciding in advance who's one of us, and who is not, based on things other than tech skills. I've got enough of that in my corporate and real world life. This is the internet. 99.9% of the time the absolute worst that can happen is that you get your feelings hurt. To prematurely constrain it to prevent that, is a medicine more dangerous than the disease.
You point to a case where someone was freely able to harass and abuse other members of the community for years as an example of why CoC's aren't needed?
You accept that you need to exclude people for the health of the community but you continue to reject CoCs because....you once were involved in a board with someone that took a long time to establish one?
I personally think a lot of the push back is from jerks fearing that they will be pushed out of the only communities that have dealt with them up to now.
There are stereotypes about programmers and their social skills and if over 20 years programming has taught me anything it is that they portray way too many individuals involved in it accurately. A lot of people do need to be told exactly what is or isn't appropriate. A lot of people do need something like a CoC to feel comfortable reporting abuse.
And a lot of people don't care so much if someone else says something "inappropriate".
Yes I commented on them in the last paragraph.
Huh?! You're saying that some people don't know what is inappropriate, not that they don't care.
>There are stereotypes about programmers and their social skills and if over 20 years programming has taught me anything it is that they portray way too many individuals involved in it accurately.
People police themselves better if they know what is expected behavior and there aren't any gray areas.
Otherwise you have owner arguing with contributor drama trying to explain implied etiquette. Of course unless the transgression was severe the owner is forced to be lenient for fear of appearing overly authoritarian (which would drive away some contributors), but they can't be entirely forgiving because the transgression might drive away some other (or same) people. CoC removes this bargaining.
>I don't need to pre-announce that I will not accept patches from murderers or pedophiles, I can simply do it.
The question is, why would you care? What the person does in their personal life is outside the scope of the project.
I am completely serious and meant exactly what I said. I did not say that it was offensive; I said that I don't understand where the practice came from. I have never been part of an open source community where "stalking, doxing, or harassing" was a problem - or at least not a problem anyone talked about. It sounds very strange, and it's hard to imagine how people that immature could be capable of doing good engineering work, but if that's the problem then I understand why people are trying to solve it.
A whole bunch of projects suffer from the issue - even (especially) ones as large as FreeBSD[0]. The issue usually winds up being that some minor contributor - or even just someone who hangs around in the dev channels - harasses some specific woman/trans person/other minority member, and the project has no official framework in which to approach this issue. Often in the project leaders' eyes, the project leader's job is all about code, not community management, leading to a call of "sort it out yourselves" when it's brought up to them - which is essentially a signal that the project will allow its contributors to harass each other without repercussion.
Basically - the sorts of people who women have to get conference organisers to have a quiet word with and/or ban don't stop being assholes on the Internet. If anything, they become worse, and it's easier to hide that behaviour when it winds up being in large part through private messages and communication systems other than the project's official ones.
(If you were associated with a volunteer group irl, and you started harassing your co-volunteers through Facebook and email and text messages, you'd hopefully be kicked out. Various CoC debates show that many people think that if the volunteer group is online, such behaviour should be excused.)
A Code of Conduct isn't magic, but it does provide social proof that the project leaders at least thought of the issues that can affect their contributors, and can provide a yardstick to judge whether a project is likely to at least listen about issues affecting contributors who are members of minorities.
[0] https://blog.randi.io/2015/12/31/the-developer-formerly-know...
Thank you for explaining and providing a really shocking example. This helps me understand.
> or at least not a problem anyone talked about
Is a big part of the problem. A lot participants don't want to be seen to be rocking the boat so they let stuff slide that they really shouldn't in the effort to not be "that person".
A formal code of conduct gives people the support up front to come forward with complaints about other members.
> A code of conduct is a signal that juvenile behavior won't be tolerated
Hardly: a code of conduct is juvenile behaviour. It's like when I was a little kid and drafted a huge constitution for my amazing awesome cool club — that was just me.
Adults don't need to write down a code of conduct, because they adhere to an unwritten code of conduct. Children whinge, 'you shouldn't do that, because this says not to!'; adults don't do that, because they know that they oughtn't — and they refrain from associating with others who do. Children want their clique to gang up on the people they don't like; adults simply walk away from those people.
Childhood is all about, 'you can't'; adulthood is all about 'I won't.'
I agree that that's how it ought to be; I strongly disagree that that's how it is. Plenty of people are physically adults; a subset of those people are mentally adults. This is even worse in the world of tech forums and open source projects than it is in the world at large.
FWIW, I have yet to see a code of conduct that really says anything beyond "don't be a jerk, and act like a grownup". It might be silly if it also told me how to dress on Tuesdays and who to vote for, but in reality they rarely or never say anything beyond "don't be a jerk, and act like a grownup." I also have no problem with someone else reminding me of that, because I have to remind myself of that all the time. I don't know why anyone would be offended by such a thing.
I suppose that's part of the reason I've had trouble understanding this phenomenon: the couple of "code of conduct" documents I've read have seemed so inoffensively obvious that it is hard to understand why such a document would be necessary, much less why it would be controversial. It alarms me that people care so much about them that merely expressing confusion about the purpose or utility of such a document acts as an invitation for criticism, and it reinforces my perception that these are not my people, arguing about something that doesn't concern me, and I don't want to get involved. I suspect that this is not what the people promoting codes of conduct are actually trying to do. I'm mentioning it in hopes that becoming aware that the harsh moralistic approach is alienating people who might otherwise support their project will help them do a better job, because it sounds like the overall effort is worthwhile.
I guess I don't interpret the presence of a code of conduct as an alienating, harsh, moralistic approach to anything. It's about as alienating/harsh/moralistic as a kitten, if the kitten was easily ignored and made of ASCII.
It's not the code of conduct document itself which seems harsh and moralistic, but the us-versus-them, tribal-feeling advocacy which accompanies it. The two code-of-conduct documents I have read were so inoffensive I couldn't tell what the point of instituting them was; but right here in this discussion there's a fairly hostile attitude toward people who are not on board with the idea, as though one must either embrace this novel code-of-conduct practice or be labelled a troglodyte. The more I have read today about the purpose of these codes of conduct, the more I like what the people promoting them are trying to do; but I'm still stuck with this feeling that they aren't my people, and don't consider me to be their people, and it's pretty much "do what we say or we think you're an asshole." Which... does not strike me as the most effective way of achieving change. Wouldn't it be more useful to bring people on board by engaging with us and explaining what's going on?
omg but your oppressive code of conduct may prevent me from harassing or berating someone down the line, so I better act like they stifle speech even though I can't find a single example of them doing so!!111 /s
It really is magical to see these people that think that everyone are supposedly always courteous to each other throw such a shit fit over codifying that into an official policy.
> Adults don't need to write down a code of conduct, because they adhere to an unwritten code of conduct. Children whinge, 'you shouldn't do that, because this says not to!'; adults don't do that, because they know that they oughtn't — and they refrain from associating with others who do. Children want their clique to gang up on the people they don't like; adults simply walk away from those people.
Because no adult has ever harassed another in a programming community? I would love it if everyone behaved politely and courteously, however this is not currently what is happening in some projects. Having a CoC is merely a preventative measure to curb bad behavior for those who can't self-police.
In this thread are men literally defending sending unsolicited dick pics to unwilling participants.
Feel free to waste your breath trying to convince me that CoCs aren't needed.
I can't help but notice that no matter how often this comes up, no one ever points to an incident of a code of conduct fixing something.
I do see a lot of complaints about heated arguments about having a code of conduct, and plenty of evidence of those arguments existing.
There is one from the Rust team below.
As far as I can tell, they are simply claiming it's a project with a code of conduct that seems welcoming. There appear to be projects that don't have a code of conduct that could be described the same way, so it's not useful as evidence of an effect.
My university participated in a study that found their anti-alcohol posters appeared to increase student drinking. Admittedly, with not as large a data set as desired, so it's also possible they simply did nothing. You find this with a huge array of both government and non-profit efforts. Most of the time, the things we try to improve society simply don't work, or not to the degree desired.
They said their discussions have been more productive since the change.
Out of all codes of conduct, how many will allow the next Linus or Theo de Raadt to emerge? It seems to me that most are driven by the same animus against crimethink that brought us donglegate.
What's so bad about a code reviewer which starts sending you dick pics compared to a code reviewer which starts sending you cat pics? They're both a waste of time.
Dick pics fall into the category of "unwanted sexual advances", which is a form of harassment.
I guess some people could see it that way given the donglegate scandal, but it can't be harassment if it's not repeated. And if something is to be repeated, then lots of things can be used besides dick pics.
> it can't be harassment if it's not repeated
Pretty sure there are a LOT of women who would strongly disagree.
No, it's just annoying or a simple threat if it's one time only. From http://www.merriam-webster.com/dictionary/harass (emphasis mine):
> Simple Definition of harass: to annoy or bother (someone) in a constant or repeated way; to make repeated attacks against (an enemy).
"sexual harassment" is a term with its own specific definition, which is not precisely a naïve combination of the simplest common definitions of "sexual" and "harassment".
Not only women... I totally feel harassed when someone sends me a dick pick
> but it can't be harassment if it's not repeated.
Incorrect. Sexual harassment doesn't require repeated conduct, though repeated conduct is more likely to be harassment (both because it is more likely to create a hostile environment simply because of the pervasiveness, and because it is more likely that the actor will be in a position where they should reasonably have known that it was unwelcome.)
The thing that's so bad about dick pics is people don't like them. And what better reason for something being bad could there be?
Not people, just some people. Also there are people who don't like cats.
Would you believe I've just spent 25 minutes trying to figure out how to respond to this, and I still don't know.
I suppose that means you win.
While one might be an annoying waste of your time, the other is not only annoying, but quite possibly illegal as well.
I leave it to you to figure out which is which.
What's so illegal in some dick pics?
Send one to a person under the age of 18 and I'm sure the prosecution, the judge and possibly your eventual roommate might be willing to explain it in ways that make you regret ever asking that question.
Code of conducts are a response to the democratization and increased accessibility of software development. Like in other communities, as the number of collaborators increases and the number of personalities, behaviors, backgrounds, and ideologies intersect, the chance of disagreements goes up.
Code of conducts are a sane effort to highlight behavior that won't be tolerated, such that it's written down and no longer implicit.
That being said, one is free to disagree with the content of a particular code of conduct if the content does not appeal, but a mere presence of one should not result in becoming dismissive of a project.
Maybe the content is usually "objectionable", hence the reaction to any code?
I'd also love to see actual stats showing a CoC improved a project on objective criteria. Less defects or something.
The best CoC is simply DBAD.
> > put a Code of Conduct in place for all communications on gitlab.
> Sigh. This again?
+1. Whenever I see a Code of Conduct I think, 'these people aren't going to be welcoming, and indeed there's a very good chance that they will slam the door in my face.'
That's the exact opposite of the intention of a Code of Conduct. Can you point out exactly what isnt welcoming about rules like "no racism" or "criticize code, not people"?
Do you have a burning desire to call people "honkey" in code reviews? Can't live without calling people stupid for being old/young? Is being prohibited from stalking other contributors so you can call their workplace and get them in trouble a huge problem for you?
This sounds like unjustified whining without any basis in actual fact or experience... iow "get off my lawn damn kids!!!".
A code of conduct is usually just shorthand for "don't be a jerk, be a professional".
GitHub code of conduct actually is in favor of racism, if you're in the wrong group. Ditto for sexism.
"We will not act on complaints regarding ‘reverse’ -isms, including ‘reverse racism,’ ‘reverse sexism,’"
That they even use the term "reverse racism" is telling. This is from a company that, in internal training, has anti-white material. "This is not work for white people", "biggest barriers to progress are white women". https://m.imgur.com/7YaVYUx?r
I don't particularly care, but if you're going to be inclusive, it should be technically inclusive, not loaded with politics. I'd bet there's a lot of people like me, thinking a egalitarian would be far less of an issue though I don't like curtailing expression, abrasive it may be, nor policing people in their personal lives.
Those quotes are inexcusable but are from a talk given by the presenter prior to her working with Github.
Ah my mistake. It wasn't at GitHub then? I guess it fit the narrative so I didn't verify. OTOH if they hired such a person for a related position, that speaks a lot. (If it was a technical hire, less so.)
If you have to rely on a CoC to get your contributors to not "be jerks" and "be professional", you have other issues with your community which really need to be addressed first.
No CoC is ever going to stop a jerk from being a jerk. It will just prompt the jerks to work around it and cause even more headaches for the contributors. Worse, it brings about those who only want to criticize the CoC, either because it's too strict, or too lenient.
Taking the time to address critiques on a CoC is time taken away from actually developing on a project and building a community who cares about the project, not the CoC.
>No CoC is ever going to stop a jerk from being a jerk.
Right but it will remove the jerks from the community.
>It will just prompt the jerks to work around it and cause even more headaches for the contributors.
How do you imagine this happening?
>Taking the time to address critiques on a CoC is time taken away from actually developing on a project and building a community who cares about the project, not the CoC.
Spending time complaining about a set of guidelines that say don't be a jerk is time taken away from actually developing on a project. Except the people doing it are complaining about not being allowed to be jerks.
> Right but it will remove the jerks from the community.
How, exactly? The CoC does nothing but codify someone's values for a community. It doesn't actually do anything, other than state a set of unacceptable behaviors and potential solutions to those behaviors. It's still up to the contributors to actually act, and if your community is good in the first place, they won't need the prompting of a CoC to act against jerks.
> How do you imagine this happening?
Easily - a CoC leaves a lot of grey areas, which provide plenty of room for griefing and harassment which isn't technically against the CoC. And if an action falls within that grey area, someone, or several someones, has to take time and not just say "this is bad", they have to tie that judgement back into the CoC somehow. It's even worse when there are consequences in the CoC for "lack of enforcement of the CoC" - being perceived as doing nothing can remove someone as a contributor. It's worth remembering, we're (mostly) developers, not lawyers.
> Except the people doing it are complaining about not being allowed to be jerks.
Are most of the people in this thread of comments complaining about not being able to harass or abuse other people? Or are they raising concerns about the ambiguous nature of these CoCs, and the perceived unnecessity? More specifically, how much time did Matz have to take out of his development schedule just to address the complaints against Ruby's CoC?
>How, exactly?
By giving members of the community a place to point to which explains why exactly they are excluding someone and a set of reasons why they will exclude others in the future.
>Easily - a CoC leaves a lot of grey areas, which provide plenty of room for griefing and harassment which isn't technically against the CoC.
Like what? Saying it could happen then when asked for examples replying with "it could happen" isn't exactly convincing for it being possible.
>Are most of the people in this thread of comments complaining about not being able to harass or abuse other people?
Well I see a few complaining that they don't feel comfortable in a space where one exists so for those people it probably is though I doubt they'd use those words to explain their actions. I see others complaining about their existence but not really providing any arguments against them other than "they aren't needed" or "they don't work".
I mean your whole argument here is that it should just happen as the CoC outlines. But history isn't on your side as open source in general has been historically full of harassment both sexual and non-sexual and various levels of abuse. To the point that it's actually celebrated from some of the bigger names in the space.
> Right but it will remove the jerks from the community.
As if the maintainers/leaders can't remove someone from the community if they wish to, without the need of codes.
P.S. By the way, the Rust Code of Conduct [1] states:
> Remarks that moderators find inappropriate, whether listed in the code of conduct or not, are also not allowed.
They can but it is a lot easier to remove someone from the community when you can point to actual rules of the community they've broken besides just "we don't like you".
I honestly can't see peoples objections to CoC. If as you say it doesn't actually change anything why do you object?
Because you have to waste time reading it, and because they tend to force people to sugarcoat everything they say so that someone doesn't get "triggered" [1]. They also encourage SJWs (social justice warriors) to waste other people's time with various crap, for example the Node.js pronoun scandal [2].
This response explains everything about your stance. Thank you.
I agree with you. For a practical example, the Rust Code of Conduct has done an excellent job at being inviting. Even our community's most divisive arguments remain civil, which, as a side effect, means more discussion, so each others' perspectives are better explored.
What does professional mean, someone who doesn't say shit as mentioned in the history of the Agile manifesto? [1]
> This freedom from the inanities of corporate life attracts proponents of Agile Methodologies, and scares the begeebers (you can’t use the word ‘shit’ in a professional paper) out of traditionalists.
If you believe everyone with a code of conduct won't like you it might be a good sign it's time to re-evaluate your actions and behaviours.
Not just you. Age-wise I suppose I'm part of the ᶜʳⁱⁿᵍᵉ ‘New Guard’ ᶜʳⁱⁿᵍᵉ, but I consider email + IRC to still be really hard to beat in terms of low barrier to entry.
I think this might be special case of more general and more important topic of software project (or basically any human operated project) spanning multiple generations. Knowledge transfer, continuity of ideas, experience sharing ... all that difficult stuff.
The Rust community, comprised largely of "New Guarders", is very active on IRC. It seems to me as though this community split is really an issue of a (relative) lack of developer community-building and marketing.
I strongly suspect that the only people who want to rely on slack/gitter/hipchat/kik/etc are employed by those respective companies
> If this is the "New Guard", perhaps it's best they are scared away by email.
This isn't a healthy attitude to have toward an open-source project -- as a "New Guarder" myself, I would be very sad to see Emacs contributions dry up.
It sounds like the author wants basically everything about how Emacs is developed to change in order to better fit their ideas about what open source looks like.
There are plenty of established projects that don't use a "pull request" workflow, Emacs only recently migrated to Git; I don't have the discussion from ESR around migrating Emacs to Git handy, but it was a pretty slow process to "bring Emacs into the 21st century" and encourage contributions from new devs. There is simply no way the entire development workflow would change based on this critique. Never mind the fact that Emacs is RMS' baby, the suggestions are so far-fetched as to be laughable.
> the vast majority of modern software developers do not want to use email as their communication channel
This sounds more like "the vast majority of software developers like me" and I'm not sure how much value there is in debating something like that. Mark me down for "disagree". I have, in the past, skipped over projects when the only means of contribution or discussion is "sign up for our Slack/Gitter/etc. channel".
Can anyone explain slack to me? It just seems like a shitty reinvention of IRC.
Doesn't require an IRC client, looks slick, has rich text, and integrations with other platforms. Biggest thing is that it doesn't need an IRC server. It could have been made with IRC underneath, but you'd want an intermediate layer to retain messages and so on.
There are web based IRC clients. IRC can integrate with other platforms pretty easily. IRC doesn't require setting up your own server.
Being able to setup your own server is a benefit, not a negative. Much like twitter it seems to be another regressions from an open internet to corporate control.
The only positive I can see is rich text, but that has extremely limited value in a chat program. History is nice too but IME too painful to use (scroll, load, scroll, load, scroll, load) to be of any practical benefit.
I'd love to agree. But with IRC you've no guarantee, for instance, that an offline user will receive notifications when they sign in (plus multi client handling).
Slack has search for history, which is huge. No more "eh we talked about it".
Onprem is great. But it's a hindrance for quick adoption.
I'd love if an open system would win. I've no love for Slack and don't use it. (Have used hipchat; what a UI mess like all of their products.) But I guess no one stepped up with an IRC-based platform that could compete.
> I'd love to agree. But with IRC you've no guarantee, for instance, that an offline user will receive notifications when they sign in (plus multi client handling). > Slack has search for history, which is huge. No more "eh we talked about it".
For functionality like that it sounds like a mailing list would fit the use case better.
> Onprem is great. But it's a hindrance for quick adoption.
It's not either/or. Think of git, you can use a hosted server or a private one. The ability to host your own server doesn't hinder anyone.
> For functionality like that it sounds like a mailing list would fit the use case better.
Then you're looking at an email with the visual noise of recipients and whitespace and signatures, and if the UI is really bad (mailing list websites, for example), every message is viewed in isolation without the responses.
The problem is: we're removing features one by one which help dealing with mailing lists. Most modern mail agents e.g. miss the threading feature, IMHO totally a must-have for mailing lists. Things don't get better, they get, in an attempt to over-simplify email, worse.
I totally agree on the UI disaster that a lot of those mailing lists are. But it seems like the solution to that would be a better mailing list ui, not to throw the whole lot out and start from scratch.
I don't know how we'd find a nice, automated solution to removing people's wordy signatures.
Doesn't gmail handle this really well? It doesn't change often, so it should be too hard to build a filter.
Rich text is a pretty strong negative, for me!
Here we go again. There has already been countless discussions on HN about why Slack has raised instead of IRC, see (https://news.ycombinator.com/item?id=10486541) for instance.
In short: Slack is what you get when you have a team managing an IRC server with all the nice plugins and bots and building a single UI that does everything. You can spend your time setting up the same thing, or you can go to Slack.
So because something is hard to setup we should regressive from an open internet to walled gardens.
Why not make IRC easier to setup?
Because IRC-the-protocol currently doesn't have what is requested by the users who prefer Slack over it:
* offline messages * full history access and search * fancy authentication schemes
There are some who try to build a full experience similar to what Slack is proposing; I'm thinking of IRCCloud for instance. But then instead of being stuck inside Slack, you're stuck inside IRCCloud (note: for the nice features, not for the basic messages). What we'd need is an open source IRCCloud server and client, that would then become the new standard... then only can IRC compete.
So, it's not just a software issue, it's a protocol issue. Which is why XMPP was born, and Matrix was born, and all other IM protocols were born. But none of them has reached the point where they can overwhelm all the other ones combined, so in the meantime people converge towards a centralized system because it's easier to be up-to-date.
I believe slack does have a IRC gateway.
A webbased irc client that doesn't suck (and keeps a channel log) would probably be a good solution to making things easy for people unfamiliar with IRC.
Some sort of one click setup for a channel on Freenode or a similar network would probably be pretty popular - especially if you could get some useful bots from the get go (like git ones) .
The problem is, and I think in the case of Github he makes his rationale plain and clear:
> I don’t think it would be right for Emacs to use github.com. I don’t even think it is right for ENSIME to use github, but I’m scared of moving in-case we lose contributor momentum. The FSF gave github.com a bad score and it’s not libre, which makes me nervous.
This is what scares me about the power of GH too. But let's be honest, as this came up with Stuart Sierra yesterday as well in his post on open source rewards stupid bug fixes and not hard work.
https://stuartsierra.com/2016/07/18/apathy-of-the-commons
If the work is boring, people won't do it.
A corollary: if the tooling sucks, people avoid the tooling, and then things stay on the backburner and never complete.
I hate the whole Slack/Gitter/IM channel as well, but the idea of avoiding tooling (e.g. git), which did take Emacs forever, leads to far less contributors like me.
Can we at least work on documenting contributor workflow? How do I build an Emacs test environment and harness system? These things must be bookmarked to emacs-devel and other mailing lists on MARC archives and what-not, as I have yet to find even good blog posts (not that I say that as a standard, but in this case more of what I don't want) of how to set this up.
I do not expect a Github wiki linking to a Gitter channel about setting up a Docker dev containter for emacs-25.x, but can we at least have better tooling for pulling from git repos and running the test suite? Document it in the manual?
>Can we at least work on documenting contributor workflow?
It is documented. Look at the file "CONTRIBUTE" in the root of the Emacs source.
That file is also cited in the manual: https://www.gnu.org/software/emacs/manual/html_node/emacs/Co...
And that manual page is the first Google result for "contributing to emacs".
Thanks for taking the time to respond.
This nice, but I have screwed around with open source for a long time. So, things like:
> Ref: The "Tips" Appendix in the Emacs Lisp Reference.
Example Novice (not me in this case): How do I get to that?
> After you have downloaded the repository source, you should read the file INSTALL.REPO for build instructions (they differ to some extent from a normal build).
> Ref: http://savannah.gnu.org/projects/emacs
Example Novice (not me in this case): What am I downloading from there? I guess I will go visit that page.
> See the existing ChangeLog files for format and content. Note that, unlike some other projects, we do require ChangeLogs also for documentation, i.e. Texinfo files.
> Ref: "Change Log Concepts" node of the GNU Coding Standards Info Manual, for how to write good log entries.
Example Novice (not me in this case): What the hell is Texinfo?
My point is this is a good high-level view. It asks me to visit half a dozen different manuals and asks I fill out a CLA.
I am not saying this is even god awful by open source standards, it is good. The problem is I am on the tail end of Linux/FLOSS culture, where a lot of people want more tooling and less learning. I know that is asking a lot. I give counter-examples in this space (Fedora, Mozilla, Start-a-flame-with-Node-NPM-dev-groups) and more focus on onboarding and get on the ground running.
Re your point on Google, I am embarassed. I looked up on DDG, and with !g for Google "emacs volunteer" "emacs hack" initially and never found these documents at first. I later did, but cloning the code is not where I see the issue here.
This stuff does not inhibit me from contributing. The problem with Linux and emacs is I must spam many thousands of people with git patches via email, and I want a way to build a reliable system in a VM or container without shitting all over my system emacs (it is a shell and editor for me) and finding a mentor so I do not get yelled at for spamming THOUSANDS of veteran Emacs devs I respect. I do not want every to use the damn Vagrantfile, but I would an emacs novice devel list or wiki or anything where I can build up to being one of those people, with simplified environments, and admit I need training wheels to contribute to one of the oldest and most important active FLOSS projects in existence. I know I demand a lot, but you seem to know this stuff. In my position, would you contribute a patch without anyone else helping you just given this material and not expect nastygrams back?
Yes, we have a CONTRIBUTE page that links to a dozen manuals is a good start, but is the kind of reaction that leads to the blog posts we see here. I do not mean to target you, but git clone I can do. Moving from that to being a member of emacs-devel that is not yelled at to the stop screwing up is different.
I find that more intimidating and think that is something worth focusing on.
> I am on the tail end of Linux/FLOSS culture, where a lot of people want more tooling and less learning
To be honest, the 'less tooling, more learning' is exactly why I prefer the GNU culture. It keeps inessential complexity down. A lot of people are broadly in my side of the boat, and it's a major part of why we're here...
Some of us need tooling because we do not even know what to learn, or where to start.
Again, this on me. I listened to Wiegley talk, and wanted to get involved. I looked into one weekend, but did not follow up. I need to stay committed. I like the history and culture of GNU as an outsider, and this is why I wanted to get more involved in Emacs.
Ask questions, read docs, hang out in IRC rooms. Some folks are on Twitter too. :-o
edit: Most of the floss world respects people who take the time to learn something before asking questions. So long as you dig about and frame an intelligent question backed by openly available information (did you RTFM :) ), the people worth respecting aren't going to trash you. I don't contribute to emacs myself, it does pretty much everything I could ever need. I would be happy to help you with floss norms and so forth... contact info in my profile. :-)
I have been lazy, but I am trying to figure out how to set up an IRC bouncer for different respective projects specifically with this in mind.
I already emailed you. Thanks for the encouragement.
> This sounds more like "the vast majority of software developers like me" and I'm not sure how much value there is in debating something like that. Mark me down for "disagree".
I'm not a fan of this, but lets not act like A LOT of new projects aren't going in this direction because they are.
> the suggestions are so far-fetched as to be laughable.
Yeah, considering git still is a source of contention on the list changing anything in their process seems nuts.
> I have, in the past, skipped over projects when the only means of contribution or discussion is "sign up for our Slack/Gitter/etc. channel".
I understand - and i'm not a fan, but that goes both ways - lot of folks have skipped over projects when the primary forms of communication are mailing lists/irc - stuff that is foreign to them or seems like a hassle.
I do think that stuff like emacs does get hurt by their processes - moving to git was a big step. The devel list is less than welcoming and at times very hostile.
I'll leave my two cents here.
My two cents come from two experiences: submitting a patch to an open source GNU project on GNU Savannah, and asking for directions to the emacs-devel mailing list in order to read the GNU Emacs codebase (because I want to do weird/neat/crazy/nasty stuff with Emacs buffers).
So:
1) Gnu Savannah. It's okay. It's a bit weird but it does everything it should do. Most open source development happens on GitHub nowadays, and this basically means that savannah is weird to work with. Imho it should just be more documented, possibly in a "visual way" (ie, video).
2) The emacs-devel mailing list. It just works. The access barrier is low (can you receive emails? can you send emails? then you can come hack with us) and it really is that simple. I really don't understand what people don't get about mailing lists.
For short, most of the article says that emacs development has not enough colours and and buzzwords.
p.s: GNU Emacs the whole GNU project had a "code of conduct" way before this was the "cool" thing: it's the GNU Manifesto.
tl;dr: githubbing open sourcers face culture shock because they haven't realized that people have been doing opensource/free stuff for a lot longer than the world of pull-requests and slack. and rather than think that there may be value in the existing ways they just brand everything as old fashioned and wrong.
I thought the cliche was meant to be that old developers don't know new tech and don't want to know.
Now it seems that there are even more new developers that don't want to know old tech.
As an emacs user, and someone who follows the emacs development lists, here is my two-cents.
You're argument is predicated on the idea that because the "new guard" don't need to rely on IRC and email anymore that the "old guard" who have been doing this since the only way to contribute to projects WAS IRC and email need to change their ways to accommodate others.
That isn't a bad thing at all, in fact most people (myself included) think it would be a good idea, but you have to remember that the FSF isn't just a software organization, but it is also more or less a political organization as well, and their processes will reflect the values of those whose interests align. While Emacs indeed does have new leadership under John Wiegley, as a whole, the project cannot change without the blessing of the GNU elders.
I feel your point might loose a bit of steam when your main argument for moving towards a pull-request model is based on "this is how they do it on Github", given that as you acknowledged, it is a non-free project that the FSF looks unfavorably on.
>While Emacs indeed does have new leadership under John Wiegley, as a whole, the project cannot change without the blessing of the GNU elders.
This isn't true. It's just that the GNU elders are elders for a reason - their opinion is respected, explicitly sought out, and generally correct.
The OP is talking hard facts, ENSIME _do_ have a low barrier for contributing. I have been witness of the continuous effort to make it more so. He is sharing what has worked for them. Are solutions "fads" now? Aren't we engineers and problem solvers? What's all this nonsense of "respecting tradition" and "elders"?
I'm not saying that experience is worthless, I'll be the first in defending it, but I also know, first hand, that as we get a little older, we get too used to our ways, even if there are others more efficient, that require change.
Hi,
I would suggest reconsidering the suggestion to use proprietary software and fad approaches. Consider digging a bit deeper before criticizing.
Just because something isn't up to date with the latest bling doesn't mean it's bad, wrong, or unwise.
I agree that email is not a VCS, but it's worked relatively well for 30 years. I would carefully consider where the actual problem is.
I agree with (most) everything here[0]. However based on the byzantine (to me, anyway) meta discussions about free/libre/gnu that seem to evolve out of every proposed major change to the emacs development process, it seems extraordinarily unlikely to happen. But man would that be cool.
[0] A code of conduct seems unnecessary.
> At ENSIME the vast majority of communication is through popular channels: github.com (non-free), gitter.im (non-free), meet.jit.si (libre) and twitter.com (non-free)
How does one know which of those four channels to use? Are people expected to follow all four of them if they want to keep informed about the project?
Wouldn't it be easier to have just one channel that is universally available? Email would be the obvious choice, and since you have to provide an email address to sign up at Github, you are already implicitly requiring your contributors to have email.
So there ought to be a new generation of leadership in the Emacs maintainer community. Ironically, he is a Haskeller. I thought this was covered on HN before, because people were enthusiastic or concerned depending on how you look at it.
http://sachachua.com/blog/2015/12/2015-12-10-emacs-chat-john...
http://www.youtube.com/watch?v=udNb4E4smbM
To the consternation of many, I love Emacs. I even eschewed tmux for multi-term, trying to move to notmuch.el for Gmail-esque email, and even consider moving away from a dedicated PDF reader and consider doc-mode if not for its lagginess (it is doing impressive stuff).
But how do I contribute to Emacs?
I like the Old Guard, I do, but I think there is something to be said for a few orgs philosophy, not implementation, such as Fedora, Mozilla, and their attempts to onboard volunteer effort.
They have good wiki material, they have the badge process to show hip ways to contribute. I too find the latter kind of off-putting, but my point is they try to signal to novices like me what to do and what of those things can be valued and by whom. I recently set up an account with Fedora and will try to work on the project not because I particularly fond of the distro (I prefer Debian, which I also want to start pitching in on), but as a culture I want to understand them and leverage their community handling tactics and use it later. They seem to know something, I want to know how they got there, why, and immitate it elsewhere needed.
Traditional projects have far less material on this. I appreciate a good static page/wiki/doc system more in the post-JS monstrosity that is the web (again, scary is the number of sites weekly I cannot visit with JS blocking to READ DOCUMENTATION; Emacs is thankfully one, or any GNU project, I worry about in this regard), but we find no good information about how to get involved with Emacs.
I have intended to email John about this. Can we consider this post to mean I am not the only one at a loss?
And a smile gripe: I have started to use ensime for a Scala Coursera course, and if the author of that post is here, I find your docs polished but confusing. Basic concepts (I need to really focus on sbt-mode to get interactive, ensime does not help with that and other stuff, you need to set up SBT first for ensime integration and the server) is there, but is linked to GH issue tracking and other stuff. You insist on reading the FAQ section that links to that, but I ended very tired one night going in circles. Resting AND trying again next day I got what you guys did, but you will lose idiots like me every time.