How to help GNU Emacs maintainers?

You can download the video, discuss the ideas on Hacker News and check Q&A on the EmacsConf 2021 webpage.

Hi everyone!

I'm Bastien Guerry and I'm the maintainer for Org-mode since 2011.

After a decade of dealing with the Org community, my view of what a maintainer is changed. I'd like to share some ideas with you as I think they could be useful to help Emacs maintainers in general, not just maintainers of GNU Emacs, but of any Emacs package out there.

Hopefully, these ideas also apply to other free software projects, at least those where contributors are all volunteers.

First of all, what is a free software maintainer?

Someone with a lot of free time, probably a rich dude
Acting both as a supersmart hacker and a super-patient manager
Someone who acts as the central hotline for users and developers
Who knows how to write many emails, probably at the same time
Who does not hesitate to publicly scold annoying users
Someone narcissistic enough to seek credits for community efforts
But really looking for a job in some big IT company

Well… no. I'm joking. But why did you smile?

Because, of course, there is some truth to it.

Why? Because our culture encourages free software users and casual contributors to think about maintainers this way. Don't we continue to call some of them "Benevolent Dictator For Life"? This is what I'd call the "Spiderman syndrom": maintenance is perceived in terms of great power and great responsibility.

I believe our culture of superheroes is not helpful here: it does not reflect the truth, it does not set the right expectations and it prevents contributors from properly understanding how to help maintainers.

So let's start again.

Instead of asking "what is a maintainer", let's make a list of what a maintainer does. As the org-mode maintainer, here is my TODO-list:

Take care of the orgmode.org website.
Take care of the org-contrib NonGNU ELPA package.
Do gardening on our community-driven documentation, Worg.
Add contributors to Worg.
Read emails on emacs-orgmode@, emacs-devel@ and bug-gnu-emacs@.
Contribute to email moderation of the emacs-orgmode@ list.
Reply to private emails asking me for help about org-mode.
Try to design and develop a better "bug tracking" system.
Coordinate with GNU Emacs maintainers for Emacs/Org integration.
Contribute with public emails on emacs-orgmode@.
Release new versions of Org-mode.
Sometimes, contribute with code.

Do you see a pattern here?

I bet the last three tasks is what most people have in mind when they think of a maintainer: it's all about hacking and being an efficient hotline. But in fact, these tasks are only a superficial part of what I do as a maintainer.

Some would consider that these core tasks are the interesting ones, while the others are the boring ones. I don't see it that way: some tasks are about the product, others are about the project. Without a good product, there is little chance you will have a good project, but maintaining a project requires thinking in terms of infrastructure, not in terms of bugs, thinking in terms of resources that enable both users and contributors, not in terms of commits.

So let me try to define again what a free software maintainer is.

A free software maintainer is someone who cares about enabling users and contributors so that they collectively take care of the project.

See another pattern here?

It's all about the project (vs the product) and about taking care of it (vs being a direct hotline for users), caring about the project infrastructure and about empowering users and contributors with tools and incentives so that they care too.

How can you help such a maintainer?

By focusing on the project and becoming an enabler yourself.

Let's pause and summarize: our culture wants heroes and this leads us to expect maintainers to be superhackers and superactive hotlines. This is the HOT mindset of maintenance, where the maintainer is the Headmaster Of Tweaks and soon becomes the Headmaster Of Troubles.

To resist this HOT mindset, let's redefine maintenance as ACDC: Asynchronous Collective Distributed Care:

Asynchronous because time management is a private matter and we are all volunteers.
Collective because, well, no man is an island.
Distributed: the more power to the "edges", the more resilient the project is.
Care because this is all about care: with each other as users or as contributors, with the project's infrastructure (servers, websites, bug trackers, etc.) and care about having a useful product.

Enabling means encouraging contributors to take ownership, which is more than just delegating tasks. Let your users and contributors know that they need to tap into the collective attention pool with care: the more autonomous they are, the better.

So, with this ACDC definition in mind, how can you help Emacs maintainers?

Become a maintainer for your own project, however small. Think in terms of project (vs product). Empower users and contributors. This will help you understand how to help other maintainers. ("More power to the edge!")
Volunteer as a contributor steward for a project: you don't need to be a supersmart hacker to help others to contribute. (For Org-mode, we are lucky to have two contributor stewards.)
Learn how to teach. Because pedagogical skills are invaluable. (Taking the time to explain others how to write a bug report or a patch is invaluable is part of the Org culture.)
Test and enhance the project's contribution process. (For Org-mode, you would read and enhance the org-contribute page.)
Take care of the project's calls for help. (For Org-mode, this would be this list. For Emacs, this would be etc/TODO.) If the calls for help are not explicit, try to contribute some.
Encourage users from outside the project to contribute to the core forum. (For Org-mode, there are many hacks and fixes being shared on reddit and stackoverflow: we should not wait for months before having this shared on the list.)
Let the core forum know about what happens in this outside world by sharing important information yourself.
Propose your help for non-code tasks: maintain a website, enhance the (community-driven) documentation, help with bug triage, etc.
If you expect someone else to fix your bug, trying fixing someone else's bug too: that's how you'll learn Emacs Lisp and that's how you'll concretely train your empathy, your sense of taking care.
Don't expect the maintainer to be a hotline, especially a private one. Address yourself to the community.
Complete this list.

That's it. Why is it hard?

Because helping maintainers by becoming an enabler is not immediately rewarding, whereas fixing a bug clearly is. But if you start thinking of the project as something that enables you to do amazing things, and of the maintenance as something that enables contributions, you will see how important and rewarding it is to become an enabler.

I'm definitely grateful to all enablers we have in Org's community! And to everyone who maintains a culture of teaching and learning through polite interactions on the mailing list and elsewhere: we always need more "power to the edges".

Also thanks to the EmacsConf 2021 organizers: that's really taking care of the community!

Thank you very much.

To comment this blog post, send an email to ~bzg/public-inbox.

Follow me on Fosstodon and subscribe to my newsletter.