
Open Letter to the Emacs Maintainers - caente
https://medium.com/@fommil/open-letter-to-the-emacs-maintainers-226cb67a961f#.1pq4ienoh
======
falcolas
> the _vast 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.

~~~
marssaxman
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.

~~~
xenadu02
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.

~~~
cariaso
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.

~~~
sanswork
>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?

~~~
dredmorbius
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.

~~~
sanswork
You're right.

------
nprescott
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".

~~~
flukus
Can anyone explain slack to me? It just seems like a shitty reinvention of
IRC.

~~~
MichaelGG
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.

~~~
flukus
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.

~~~
MichaelGG
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.

~~~
flukus
> 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.

~~~
orbitur
> 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.

~~~
flukus
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.

~~~
orbitur
I don't know how we'd find a nice, automated solution to removing people's
wordy signatures.

~~~
flukus
Doesn't gmail handle this really well? It doesn't change often, so it should
be too hard to build a filter.

------
znpy
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.

------
jimjimjim
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.

------
shruubi
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.

~~~
catern
>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.

------
caente
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.

------
pnathan
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.

------
numlocked
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.

------
tzs
> 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.

------
616c
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://sachachua.com/blog/2015/12/2015-12-10-emacs-chat-john-wiegley-
maintaining-emacs-can-help/)

[http://www.youtube.com/watch?v=udNb4E4smbM](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.

