11 ms·

Open Letter to the Emacs Maintainers

46 points by caente 10y ago

falcolas 10y ago
> 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.
- zeveb 10y ago
  > > 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.'
  - xenadu02 10y ago
    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".
    - moosingin3space 10y ago
      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.
    - MichaelGG 10y ago
      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 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.
      - jcoffland 10y ago
        Those quotes are inexcusable but are from a talk given by the presenter prior to her working with Github.
        MichaelGG 10y ago
        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.)
    - falcolas 10y ago
      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.
  - sanswork 10y ago
    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.
- PeCaN 10y ago
  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.
  - koja86 10y ago
    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.
  - moosingin3space 10y ago
    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.
- xkcd-sucks 10y ago
  I strongly suspect that the only people who want to rely on slack/gitter/hipchat/kik/etc are employed by those respective companies
- marssaxman 10y ago
  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 10y ago
    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.
    - marssaxman 10y ago
      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.
- moosingin3space 10y ago
  > 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.
numlocked 10y ago
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.
nprescott 10y ago
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".
- 616c 10y ago
  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 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? https://duckduckgo.com/html?q=emacs%20build%20environment https://duckduckgo.com/html?q=emacs%20build%20environment
616c 10y ago
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-wiegley-maintaining-emacs-can-help/ http://sachachua.com/blog/2015/12/2015-12-10-emacs-chat-john... 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.
shruubi 10y ago
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 10y ago
  >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.
znpy 10y ago
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.
pnathan 10y ago
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.
jimjimjim 10y ago
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.
caente 10y ago
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.
tzs 10y ago
> 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.

46 points by caente 10y ago

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

zeveb 10y ago
> > 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.'
- xenadu02 10y ago
  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".
  - moosingin3space 10y ago
    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.
  - MichaelGG 10y ago
    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 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.
    - jcoffland 10y ago
      Those quotes are inexcusable but are from a talk given by the presenter prior to her working with Github.
      - MichaelGG 10y ago
        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.)
  - falcolas 10y ago
    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.
- sanswork 10y ago
  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.
PeCaN 10y ago
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.
- koja86 10y ago
  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.
- moosingin3space 10y ago
  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.
xkcd-sucks 10y ago
I strongly suspect that the only people who want to rely on slack/gitter/hipchat/kik/etc are employed by those respective companies
marssaxman 10y ago
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 10y ago
  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.
  - marssaxman 10y ago
    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.
moosingin3space 10y ago
> 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.

numlocked 10y ago

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.

nprescott 10y ago

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

616c 10y ago
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 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? https://duckduckgo.com/html?q=emacs%20build%20environment https://duckduckgo.com/html?q=emacs%20build%20environment

616c 10y ago

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

shruubi 10y ago

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 10y ago
>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.

znpy 10y ago

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.

pnathan 10y ago

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.

jimjimjim 10y ago

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.

caente 10y ago

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.

tzs 10y ago

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