The last time Hackerfall tried to access this page, it returned a not found error. A cached version of the page is below, or clickhereto continue anyway

Open Letter to the Emacs Maintainers '(Sam Halliday) Medium

Open Letter to the Emacs Maintainers

These are some thoughts from a free/libre project, which is using modern tooling to manage a community of active contributors, to the Old Guard maintainers of Emacs.

TL;DR I wish Emacs was as easy to contribute to as ENSIME.

How ENSIME DoesThings

We (the core maintainers of ENSIME) gave a talk at ScalaSphere recently about how we do everything http://ensime.org/talks/scalasphere16/

At ENSIME the vast majority of communication is through popular channels:github.com (non-free), gitter.im (non-free), meet.jit.si (libre) andtwitter.com (non-free). Wed use IRC with history if it was easy to use. We also have a standard code of conduct and are members of Typelevel.

We have a welcoming contributor page http://ensime.org/contributing thatwe funnel most documentation towards and we put a lot of effort intomaking it easy for people to contributeeven forgoing working onfeatures we want, to make it easier for others to contribute.

Key to contribution is our extensive testing and continuousintegration setup. We host a libre https://github.com/drone/drone/server (its extremely lightweight), and contributors can donateworker nodes that run libre docker servers.

Before a pull request can be merged, the tests must pass on drone, theCLA must be signed, a core admin must approve the code, and some othernon-free tests must also pass (travis and appveyor running tests forOS X and Windows respectively). This is all automatically managed bygithub and github extensions.

Once merged to a release branch, the same CI infrastructure takes careof building, testing and publishing binaries / sources for userconsumption. We have a rolling release strategy for unstable brancheswhich means that once an improvement is accepted, it will be on allusers machines within hours.

The ease of testing, coupled with rapid release turnarounds, hasresulted in a huge amount of contributions. I estimate that about10% of users are also contributors.

The other thing that has hugely boosted our contributor base is themonthly Hack Days in London (and some satellite days in Poland). Werenow seeing consistently 10-ish people coming along every month wantingto help out with the roadmap.

Thoughts from the PeanutGallery

On Contributor Engagement

One of the things that prompted me to write this was how hard it isto communicate or be involved in the Emacs developer process. Recently I encountered the notorious fixing randomize_va_spacehttps://debbugs.gnu.org/cgi/bugreport.cgi?bug=23529

and I tried out Emacs 25 pretest, and found two bugs: bothof which were affecting email which meant I couldnt use report-emacs-bug.

The communication channels with Emacs developers are, honestly,terrible. debbugs is an awful awful awful piece of software and the*vast majority* of modern software developers do not want to use emailas their communication channel. There is a huge chasm between the OldGuard and the Next Generation who reach for Atom or (in Java / Scala)IntelliJ.

I dont think it would be right for Emacs to use github.com. I donteven think it is right for ENSIME to use github, but Im scared ofmoving in-case we lose contributor momentum. The FSF gave github.com abad score and its not libre, which makes me nervous.

But gitlab.com got triple gold stars with a cherry on top, is libreand can be self-hosted. It sounds like it would be ideal to hostEmacs, so Id like to propose the following:

1. Move the Emacs git repository to gitlab.com and put a Code ofConduct in place for all communications on gitlab.2. Migrate the debbugs tickets to gitlab.com (the gitlabfolks may be willing to help, given the publicity theyd receive)3. Change the workflow to a pull request process instead of an emailprocess.4. Set up a drone CI to test on whatever GNU / Linux variant youchoose (possibly multiple!) and ask for contributors to help bydonating docker servers. This is, unfortunately, blocked byhttps://debbugs.gnu.org/cgi/bugreport.cgi?bug=23529 unless allworker nodes run in privileged docker instances.5. Do the same for each package on ELPA (not a mono-repo - have one repo and one CI per project).6. Tolerate non-libre CI runners such as appveyor and travis, whichwould test the code on non-libre platforms.

There are several areas where contributors of a variety of programminglanguages could help for the greater good:

- improvements in gitlab, including command line tools likehttps://github.com/github/hub (or email => PR converters for the OldGuard)- improvements in drone (which is written in Go, I assume you are awarethat the vast majority of Go developers are using Emacs?)- improvements in workflow tooling, customising the PR acceptancecriteria. (e.g. check that contributors have signed the FSFcopyright assignment contract)

On Emacs26

ELPA / MELPA / etc and use-package are game changers. I see everynon-core package in Emacs as bloat and technical debt that makes itharder to contribute to Emacs and slows down the build. Id love tosee every non-essential package move to ELPA as a standalone. Thiscould be done in a 100% backwards compatible way by having asite-lisp.el to install all the packages that are currentlydistributed with Emacs. GNU / Linux distributions could provide avirtual package which installs all the necessary ELPA packages andmakes the site-local available.

I feel that the code cleanup introduced by such a separation wouldmake it dramatically easier for contributors to get involved withEmacs. Suddenly one has a chance of being able to read all the Emacssource code and understand what is core and what is library.

We can expect contributions to the ELPA-hosted packages to increase aswell! The decoupling from Emacs releases, combined with an easy gitlabworkflow, lower the barrier to entry.

Id be so excited about Emacs development if the above were to happen!

So much so that Id be willing to alternate the monthly ENSIME hackdays as Emacs / ENSIME hack days. In London we have the Church ofEmacs meetups and Im sure we could build up a good crowd of 10+people of various skills.

If Emacs could move onto gitlab and use a pull request workflow, I thinkthats the point where Id be willing to do this: moving packages toELPA sounds like a good opportunity to get a huge number of peopleinvolved (its easy, if not tedious). If I were to bring copyrightassignment contracts with me, we could mail them off in bulk so thatpatches can be accepted quickly.

Id also be happy to get Emacs mugs and stickers printed off as giftsto encourage people to come along.

Continue reading on medium.com