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

[marssaxman]

Rich text is a pretty strong negative, for me!

[rakoo]

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.

[flukus]

So because something is hard to setup we should regressive from an open internet to walled gardens.

Why not make IRC easier to setup?

[rakoo]

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.

[jjrh]

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

[616c]

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?

https://duckduckgo.com/html?q=emacs%20build%20environment

[catern]

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

[616c]

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.

[pnathan]

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

[616c]

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.

[pnathan]

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

[jjrh]

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