Where is the technical volunteer support in the Wikiverse?

Volunteer support is a major theme in the Wikimedia movement, and a typical endeavour of many affiliates. Content contributors are supported in many ways − Wikipedia writers get access to reference books, Wikimedia Commons photographers to equipment and accreditations, contest organizers to project management support, etc.

Yet, to me there seems to be a major blindspot when it comes to technical contributors.

By technical contributors, I encompass all people contributing to server-side scripting (templates and modules), client-side scripting (user-scripts and gadgets), autonomous editing programs (bots), desktop and web applications, etc.

Existing support

Here I will try to draw a (likely non-exhaustive) map of the existing support.

Technical infrastructure

The Wikimedia Foundation (WMF) provides technical infrastructure:

• to run the tools, eg web-apps and bots via Cloud VPS and Toolforge
• to support the development life-cycle: issue tracking, code-hosting, code-review, build & testing, deployment − with Gerrit, Phabricator and Jenkins.

While these platforms have their shortcomings (indeed, many volunteer developers avoid them altogether), I believe they are an amazing proposition. I also believe they are well supported: hang out on IRC asking for help for your Toolforge tool, and you will most certainly get it, whether from WMF staff, volunteers, or WMF staff with their volunteer hat.

Events

The WMF, generally in partnership with an affiliate, has long been organizing hackathons − the Wikimedia hackathon around May, and the Wikimania one around July/August (other such events exist, such as the Dutch TechStorm).

I think hackathons are amazing − as I wrote before, they are great at creating an atmosphere suited to get work done.

Motivation & appreciation

A key tenet of the volunteer support, this has seen some welcome progress with the notable creation of the Coolest Tool Award.

Money

Ah, this is often where it ends: a question “What about VeryImportantTool” is likely to elicit an answer along the lines of “This tool is volunteer-developed, and not supported by BigOrganization. We would be happy to consider a grant request to work on it though!”

While grants are useful, and have certainly helped the creation and enhancement of great tools (both in the Wikiverse and in other open movements like OpenStreetMap¹), I think this answer is reductive and inappropriate in many cases. The main reason I see is that most often, when time or motivation are lacking, money will not buy either. Some tool developers may be self-employed freelancers, or be between jobs, with the flexibility to set aside a few weeks/months supported by a grant ; not so much if one is regularly employed. Timing can also be tricky: some grants have cycles, which may not fit the (work-)life of people.

So what is missing?

I believe that what is missing in tool development is more collaboration. It takes a village to raise a tool − and various specialties ranging from product ownership, design, development, operations, testing, QA, security, documentation… −  yet more often than not, a single person is behind a tool.

Staff support

It has been suggested before that WMF should take over part of the duties related to a tool − typically the operations (of tools like PetScan) but UX/design had also been suggested. 

Historically, I think it fair to say WMF has not been keen on doing so. I can see good reasons to avoid that (different priorities, limited resources, not so easy to adopt foreign and potentially messy codebases, perhaps fear of cannibalizing volunteer efforts), but also bad ones (wrong sense of priorities, Not-Invented-Here syndrome).

I can see how staff taking over operations of a major tool, or having a UX review queue, might not be sustainable. But I am convinced that there is space for a technical counterpart to the Volunteer Support for content contributors.

This crystalized to me when (story time) following the pipenv 2018 release − where Sumana Harihareswara (who once upon a time worked at WMF, interestingly enough) stepped in to help the maintainers put together a well-overdue release of a major piece of the Python ecosystem. Sumana called it “Coaching and cheerleading”:

An external perspective can help a lot. You can be that person. Whether you call yourself a sidekick, a project manager, a cheerleader, a coach, or something else, you can be a supportive accountability partner who helps with the bits that maintainers are not great at, or don’t have time for. And you don’t have to know the project codebase to do this, or be a feature-level developer – the only pipenv code I touched was the docs.

Sumana Harihareswara

We could really use some professional coaches and cheerleaders.

(Speaking only for myself, as the developer of the moderately successful integraality (and ex-co-maintainer of the the monuments database) − no smash hits, but somewhat relied upon tools − I can see how having someone checking in on me once every couple of months, to help me plan/organize work, could be very valuable).

Being the village

As I outlined above, there are many parts to tool development, many of which are non-technical: handling bug reports, writing documentation, prioritizing feature requests… We are an amazing collaborative community − why isn’t there more collaboration around tools? For example, when building integraality, I experienced first-hand how delegating product decisions helped:

Making the decisions on where to take the product and what red lines to draw scope-wise is sometimes the hardest. This saved me heaps of time, in the couple of instances where I was unsure how to proceed. I wonder if this should be part of the hackathon setup − every hacker being the “owner” or “client” of the another’s project.

This − again − crystalized with a recent story: reading Magnus Manske’s “The Buggregator” blog post. I could not help but feel deeply sad: Magnus, a prolific developer of highly-popular tools, is so overwhelmed with bug reports and feature requests, raised in many different places, that he feels the need to write a tool to help manage all of these. I could not help but think − why on earth does he have to manage this communication influx all by himself? Since his tools are so popular, surely there should be many folks happy to help with this tool, or that one? When someone reports a bug to Magnus on some random talk page or Telegram channel, why isn’t there a volunteer happy to take over, ask the necessary clarifications, file it in the canonical bug tracking place (whichever that might be), prioritize it for later?

Of course, most of us will never churn in so many tools that we need to write a bug aggregation platform ; but I think that Magnus’ problems are everyone’s problems − just magnified (magnufied?) ten times over.

In short, there should be more of a community active around a popular tool − people helping out in particular with the non-technical aspects. 

I used to think that the lack of such community was somehow the responsibility of the developer themself − that if you were the single-maintainer on your Toolforge tool account, then you should try a bit harder.

I have come around on this: we set out to develop software, often to scratch our own itch, and not necessarily expecting success ; we don’t sign up to do community building and management on top. But that community does not seem to happen on its own either: it seems that in this movement, we are more prone to ask tool developers for help, than to ask whether they need help.

If so, then I think this should be the first and foremost job of the professional technical volunteer support: helping build up an active support network around a tool. This may include recruiting co-developers, but I see a real opportunity in engaging volunteers in non-technical capacities, and structuring that engagement with models and best practices. Far from cannibalizing volunteer resources, this would rather fit nicely in our goal of capacity building and increasing the sustainability of our movement.

Conclusion

In this post, I tried to map out the existing support for technical contributors, and have made the case for professional volunteer support, mirroring the practices and successes of support for content contributors. Beyond a direct “coaching and cheerleading”, this would entail recruiting and structuring volunteer-based support networks around each tool.

This may find an echo at the existing big software-houses that are WMF and WMDE, who may decide to create dedicated technical volunteer support roles or teams − I would certainly welcome it. But there are so many tools − I don’t think this is a problem that can be solved centrally. After all, no one expects WMF to help out individual content contributors in a particular country or focus area − this is what affiliates have excelled in.

Rather, the idea would rather play well with the Hubs model of support structures that has been developed as part of the 2030 strategy: a hypothetical “GLAM” thematic hub helping out on GLAM-related tools, or a “Wikisource” hub on Wikisource tools, etc.

Until then, in the spirit of decentralization and subsidiarity, I rather hope that the idea might be taken up by all affiliates: expanding their existing volunteer support to technical contributors − one tool at a time.

---

This piece was in the works for a while ; the impetus to finish out was ahead of the “Please don’t get hit by a bus! Towards a resilient and sustainable Wikidata tool ecosystem” session at WikidataCon 2021.

---

Notes

¹ Pattypan (grant) immediately comes to my mind ; I also think of the StreetComplete project (which I am quite fond of)