Talk:Content Partnerships Hub/Software/Volunteer developers discussion at Wikimania 2022

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

A bit surprised[edit]

I wasn't able to make the session unfortunately, it was at a bad time for me - I appreciate the effort to summarize the session and write up the blog post. Is a recording available?

In general I'm pretty surprised by the general observations in the "What did we learn from the group discussion" section.

  • I'm not sure what the issue is with relying on volunteers to fix things. Volunteers do most of the work overall, it seems reasonable to rely on them to fix things. Of course, that also means you get a volunteer level quality of service, which means fixes might be postponed until the weekend or after a vacation. If you want better quality of service then volunteers might not scale (but that's not how it's framed).
  • Agreed mostly on this point. Mostly as a side note on the topic of training, I think an underappreciated part of Quarry is how easy it is to see how other people use it by looking at their queries, and improving from them. More tools should do this.
  • I guess it depends on specifics, but I'm pretty uncomfortable with the idea of having an organization "step in and to take over tasks from volunteer developers". I do think volunteer developers need better PM, etc. support. But I don't think having a formal organization take it over fixes that problem, I'd worry that it actually reduces growth opportunities for volunteers to learn how to do those things themselves. There is no way that any organization can cover all the tools that get created, there are just too many of them (a good thing!). So it's important that devs are able to do their own PM, promotion, documentation, etc. I would love to see formal support in helping devs learn how to do that, rather than just doing it for them.

I hope this is useful feedback. Legoktm (talk) 05:41, 12 September 2022 (UTC)Reply[reply]

Thank you, @Legoktm, I'm really happy that you found the post (already before we advertised it more broadly!) and took the time to comment. Your feedback is very useful.
Yes, there is a recording, for now only on YouTube although I think it will be on Commons too at some point. I linked it from the top of the page, thanks for flagging that.
To provide a bit more context to the discussion: it took place as part of a larger effort to provide Wikimedians who do content partnerships (including GLAMwiki) with better-working and more reliable software in the long run. Especially in the GLAMwiki community, we have a long standing problem that the software that is really important to us for statistics and batch uploading tends to break or be down at irregular times, which impedes Wikimedians' and partners' work, and leaves a bad impression on partners in general. So with the content partnership hub we are looking if it would make sense to provide better support to a selection of key tools (think 2-3 to start with, and it will certainly never be a lot of them - just the most important ones that the community decides are crucial to them). And we want to learn which kind of support makes most sense: good support for volunteer developers who want to work and maintain autonomously, but also reliability of the software itself.
To respond to some of your more specific points:
  1. I agree that the framing / phrasing is a bit awkward. I copied the nearly exact thing someone wrote in the Etherpad, but I think the gist is more along the lines of: "we are a volunteer driven movement and if volunteer developers want to have freedom to build and maintain tools, by all means they must be supported to do so. However, if maintenance has become a burden for them, and if reliability of the software has become a blocker for its end users, then there should be a safety net" - or something along those lines.
  2. I also think there's not a 'one size fits all' solution. (My impression was that everyone in the session agreed on this, although it's perhaps not reflected in the notes or recording very well.) Some volunteer devs will indeed be very happy to do a lot of work by themselves; others (like Magnus) may be interested in only building prototypes and will be extremely happy if others take over. As a concrete example: I currently also work for OpenRefine, and our main developer has stepped back from Wikimedia development. We can try onboarding new volunteer Wikimedia developers (I would really like to do that), but it won't be easy (complex codebase in Java) and we want the software to be reliable and bugs to be fixed quickly when they arise, which is a lot to ask from volunteers. From that position, I would welcome an organization that would play a role in providing support and consistency.
Welcoming other thoughts, Sandra Fauconnier (WMSE) (talk) 06:34, 13 September 2022 (UTC)Reply[reply]
I heartily agree with @Legoktm that "it's important that devs are able to do their own PM, promotion, documentation, etc.". The tech writers on the WMF Developer Advocacy team are working towards providing more formal support in helping devs learn how to do analyze, improve, and manage their documentation, rather than just doing it for them. TBurmeister (WMF) (talk) 14:47, 22 September 2022 (UTC)Reply[reply]

Already established best practices[edit]

I'll use Magnus as an example just since he was already called out by name, but this actually applies to a lot of prolific and non-prolific tool developers (including myself!). Magnus is really good at what he does and builds really cool tools. But last I checked, most of Magnus' tools have a single maintainer - himself. We have a well established set of best practices now, and having multiple maintainers is a big part of ensuring tools are sustainable in the long run.

I think there would be a lot of value in promoting those best practices, going through lists of tools, checking to see if they published their source code somewhere that's easy to find, have a documentation wiki page (so other people can improve it, iteratively), and match them with possible other maintainers, even if it's just in a backup capacity. Legoktm (talk) 05:47, 12 September 2022 (UTC)Reply[reply]

Thank you, that's an awesome resource which I wasn't aware of yet! We are building a longlist of crucial tools and these will be very helpful to check the tools' general health and status.
Totally agree that having multiple maintainers is the way to go. But how do you attract and retain such people? Does anyone have examples of projects where this has gone quite well? Sandra Fauconnier (WMSE) (talk) 06:38, 13 September 2022 (UTC)Reply[reply]
Just an addendum re: Legoktm's first link: There's also a shorter version (and linked within the navbox) at wikitech:Help:Toolforge/Developing successful tools. HTH. -- Quiddity (talk) 17:25, 14 September 2022 (UTC)Reply[reply]