Live data from Hacker News

Open Letter to the Emacs Maintainers

medium.com

11–20 of 110 posts

Re: Open Letter to the Emacs Maintainers

#11
post #2

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

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.

Re: Open Letter to the Emacs Maintainers

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

Re: Open Letter to the Emacs Maintainers

#13
post #12

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 (my…

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

Re: Open Letter to the Emacs Maintainers

#14
post #10

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 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 hone…

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

Re: Open Letter to the Emacs Maintainers

#15
post #2

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

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 ven…

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.

Re: Open Letter to the Emacs Maintainers

#16
post #8
post #2

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

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

Re: Open Letter to the Emacs Maintainers

#17
post #2

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

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 ven…

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.

Re: Open Letter to the Emacs Maintainers

#18
post #8
post #2

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

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.

Re: Open Letter to the Emacs Maintainers

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

Re: Open Letter to the Emacs Maintainers

#20
post #14
post #10

Earlier quoted context omitted.

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 hone…

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

Post reply on HN