Hello, I'm Bastien Guerry,
and I'm happy to be here.
I've been the Org-mode maintainer
for the last 10 years,
and I would like to ask the question
how to help GNU Emacs maintainers in general.
By GNU Emacs, I mean
the whole GNU Emacs ecosystem,
including packages,
not just the core GNU Emacs
that we all love.
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.
And 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?
- Obviously this is some rich dude
with a lot of free time
- Acting both as a supersmart hacker
and a super-patient community manager
- Someone who acts as the central hotline
for users and contributors
- Who knows how to write many emails,
probably at the same time
- Who does not hesitate
to publicly scold annoying users
- and someone narcissistic enough
to seek credits for community efforts
- But really looking for a job
in some big IT company
Right? Well... no. That was a joke.
But maybe you did smile
and that's probably
because 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 use the expression
"Benevolent Dictator For Life"?
This is what I'd call
the "Spiderman syndrome":
maintenance is perceived in terms of
great power and great responsibility.
But 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
to properly understand
how to help maintainers.
So let's start again.
Instead of asking what a maintainer is,
let me take the list of
what I do as the Org maintainer.
Here is my TODO-list:
- First of all, I take care of
the orgmode.org website.
- I also take care of the
org-contrib NonGNU ELPA package.
- I do gardening on the
community-driven documentation, Worg.
- I do add contributors to Worg.
- I read emails on emacs-orgmode@,
emacs-devel@ and bug-gnu-emacs@.
- I contribute to email moderation
of the emacs-orgmode@ list
with a bunch of other contributors.
- I reply to private emails
asking me for help about org-mode.
- I coordinate with GNU Emacs maintainers
and thanks to them for Emacs/Org integration.
- I contribute with public emails
on the Org mailing list.
- I release new versions of Org-mode.
- and sometimes, sometimes,
I contribute with code.
Do you see a pattern here?
Yes. 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
or should be.
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?
That's all about the /project/,
versus the product.
It's about /taking care of it/,
versus being a direct hotline for users,
caring about the project infrastructure
and about empowering users
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 maintainers are Headmasters Of Tweaks
and soon becomes the Headmaster Of Troubles.
To resist this HOT mindset,
I suggest to 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/: because the more power
to the "edges", the more resilient
the system and 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/ users and contributors means
encouraging them 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?
- First of all, by *becoming 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 edges!")
- *Volunteer as a contributor steward
for another project*: you don't need to
be a supersmart hacker
to help others to contribute.
(For Org-mode, we are lucky to have
two great contributor stewards.)
- *Learn how to teach*,
because pedagogical skills are invaluable.
(Taking the time to explain
how to write a bug report or a patch
is invaluable and this is a core part
of the Org culture.)
- *Test and enhance the project's
contribution process*. (For Org-mode,
you would read and suggest contributions to
the org-contribute pages on Worg.)
- *Take care of the project's calls for help*.
(For Org-mode, this would be this list
that we have on updates.orgmode.org
For Emacs, this would be =etc/TODO= file.)
If the calls for help are not explicit enough,
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:
and that's fine, but we 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,
try 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.
That is so critical.
- *Don't expect the maintainer
to be a hotline*,
especially a private one.
Address yourself to the community.
- and last but not least,
*complete this list*.
I'm trying to open a conversation here,
so don't be shy.
That's it. Is it hard? Yes, this is hard,
and that's because helping maintainers
by becoming such a enabler
in this ACDC mindset
is not immediately rewarding,
whereas fixing a bug clearly, clearly is.
But if you start thinking of the project
as something that enables you
to do amazing things, and I believe
Org is this kind of project,
and if you start thinking
of the maintenance as something
that enables more contributions,
you will see how important and rewarding
it is to become such an enabler.
So, definitely grateful to all enablers
that we have in Org's community!
And to everyone who maintains
a culture of teaching and learning
through polite and respectful interactions
on the mailing list and elsewhere:
we always need more "power to the edges".
And I'm also very grateful
to the EmacsConf 2021 organizers,
because that's really taking care
of the community! Thanks very much.
[captions by sachac]