I guess some of you know me mostly as maintainer of Flycheck, a popular extension for on-the-fly syntax checking in GNU Emacs. But the sad truth is that I’ve been fulfilling this role less and less over the past year.

Flycheck has become a huge success. It’s included in many Emacs distributions (e.g. Spacemacs, Prelude, etc.), it has over a thousand stars on GitHub, and it’s among the ten most downloaded packages on MELPA. Many many people contributed to this success, yet to this day maintenance of Flycheck largely rests on my shoulders.

I can’t deny that I’m a little proud to have come this far, but I must admit that the burden turned out to be too heavy for me.

Maintaining Flycheck takes a lot of time, time that is harder and harder to find among family and friends, among a great and interesting full time job as a Scala developer, and among many other interests that I’d like to pursue in my free time.

I’d like to spend more time on interesting projects again: I want to learn a little Rust, work my way through Software Foundations with Coq on my side and then there are a couple of ideas for Scala projects in the back of my head. And I’d like to work through my reading list; there are so many great books to blown the dust of in my room.

At the same time I must admit that I find less and less satisfaction in the grunt work of maintenance: I’m tired of triaging issues, reviewing pull requests, writing documentation, tired of fighting all the nuisances and complications Emacs infringes upon developers, tired of the lack of progress in some areas of Emacs…

To cut a long story short, I’d like to move Flycheck off my shoulders. I don’t want to get rid of it entirely, though; rather I hope for Flycheck to become community-governed around our Code of Conduct and a certain set of basic rules.

To achieve this aim I’ve spent a lot of time documenting Flycheck as a project, its tooling, its rules and policies and the decision making process I’d like to see, in order to set rules for future maintainers and to ease on-boarding of new contributors.

Today I’m taking another step in this direction: Flycheck now uses LGTM to establish a formal approval process for pull requests:

  • The master branch is now protected for all contributors except maintainers.
  • Every contributor needs to open a pull request for their changes.
  • Maintainers leave “LGTM” comments to approve pull requests.
  • Every contributor can merge approved pull requests.

Currently it’s mostly just me approving pull requests, but I’ll try and find more maintainers for Flycheck. If you’d like to help out drop me a line or ping us in the Gitter chat.

These changes will also affect you as a contributor to Flycheck whether regular or not:

  • I’ll spent less time to clean up pull requests. Instead I’ll ask you to improve your pull request until it’s definitely ready for being merged, including changelog entries, documentation, etc.
  • I may add you as a contributor to Flycheck, and ask you to merge your pull request yourself once it’s finished review.
  • I’ll likely not fix simple bugs myself anymore, and instead ask reporters to try and submit a pull request.

I’ll try to document the new rules more thoroughly over the next days and I hope to come up with a set of review guidelines for pull request which I hope help maintainers to properly review pull requests and let’s contributors see what we expect.

I hope that the new workflow helps me to spend less time on Flycheck while at the same time bringing more people on board to make Flycheck’s development more lively and prosperous than it was before.

If you’d like to help out please be welcome to join Flycheck. Just write me a mail, open a Github ticket or join our Gitter chat.