The Maintainer's Life (1)

While I was getting interviewed for an article in the "Open Source community leaders" series on a Japanese trade publication (due to come out in many weeks), I was asked an interesting question:

What is your role in the community? What is your job?

My immediate reaction was "Huh?". The interviewer contacted me knowing that I am the Git maintainer. Don't all maintainers do more or less the same thing and operate more or less in the same way?

But here is my version of what I do, anyway. What I do fall into two categories.

One is what I do as a member of the Git development community like everybody else.

• Triage end-user bug-reports into non-bugs and real bugs. Non-bugs may result in referring the user to an appropriate manual page, or may result in updates to the documentation. Bugs may result in fixes.
• Read other end-user requests, ranging from "Help, I do not know what I am doing" to a solidly written feature requests. Again, many may result in referring the user to an existing documentation, some may result in real enhancements.
• Design and propose fixes and/or enhancements (possibly inspired by end-user inputs above, or perhaps scratching own itch) to the community and discuss with the members to reach consensus. Post a series of patches to implement the design and get them reviewed by community members. With their help, polish the patches to perfection.
• Participate in the discussion and the review process initiated by other community members who do the above.

The other is what I the maintainer alone does as the project leader.

• Keep an eye on end-user reports and requests that haven't been responded, find somebody in the community (i.e. victims) who are knowledgeable enough to handle them, and redirect.
• Accept the patches polished in the review process and manage releases.

An interesting thing to notice is that the latter, at least when expressed as a list of bullet items, is a lot smaller than the former. Strictly speaking, the "Keep an eye on leftover bits and redirect" item could be done by anybody in the community, and in fact we saw various people acting as capable project secretaries to do exactly that from time to time. Even though I rarely do a "grand redesign with a road-map toward the future", such a topic would not be done by me as the maintainer descending from above with an edict, but as a proposal by me as one of the members of the community (bullet 3 in the former list). Also, compared to less experienced community members, I find myself saying "Let's step back a bit" a lot more often, asking other participants in design discussions to temporarily free their thinking of whatever narrow problem description originally given by the proposer of the topic, and instead to view the issue with wider context in mind. That is not done as the maintainer, but as one of the more experienced members of the development community. Other experienced community members can and often do the same to inject sanity to ongoing discussions.

I think one of the biggest reasons why the community does not come to a screeching halt when I disappear for a few weeks is because there aren't many tasks only the maintainer is supposed to do in our community in the first place. Capable others can take over fairly smoothly while I am away, because no matter who the interim maintainer is, what other community members do do not change very much.

Perhaps what the maintainer does may be different from communities to communities. How does your community work?