Open Letter to the Emacs Maintainers
medium.com
Open Letter to the Emacs Maintainers
1–10 of 110 posts
Re: Open Letter to the Emacs Maintainers
#2> 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.
Re: Open Letter to the Emacs Maintainers
#3I 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.
Re: Open Letter to the Emacs Maintainers
#4> 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…
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.
Re: Open Letter to the Emacs Maintainers
#5> 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…
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.
Re: Open Letter to the Emacs Maintainers
#6It 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".
Re: Open Letter to the Emacs Maintainers
#7> 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…
I strongly suspect that the only people who want to rely on slack/gitter/hipchat/kik/etc are employed by those respective companies
Re: Open Letter to the Emacs Maintainers
#8> 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…
> > 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.'
Re: Open Letter to the Emacs Maintainers
#9So 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.
Re: Open Letter to the Emacs Maintainers
#10It 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 c…
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?