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

From Meta, a Wikimedia project coordination wiki

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]

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]
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]
I fully see that point. That said, I think it's also really important to emphasize the perspective from the side of Wikimedians who do partnerships with external organizations. Some volunteer-developed tools have become so crucial to our movement's work that it's, frankly, a very bad thing if they go down, even for a short while. Sometimes there may be very pressing feature requests which can't or won't be accommodated by the volunteer developers, because they are just too busy, or they have stepped away from a tool entirely. We also need good and responsive approaches for such situations. Sandra Fauconnier (WMSE) (talk) 08:05, 28 September 2022 (UTC)[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]

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]
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]
Just posting a follow-up that @Legoktm and others are indeed initiating a "Tool Sweep" as mentioned in the comment from last September: https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Tool_sweep TBurmeister (WMF) (talk) 16:11, 9 January 2023 (UTC)[reply]
@TBurmeister (WMF) and @Legoktm This is great, and I will be happy to help advertise this initiative if needed! Sandra Fauconnier (WMSE) (talk) 13:20, 10 January 2023 (UTC)[reply]

Conflict of goals and expectations[edit]

I see this as a conflict of goals and expectations between developers and audience. The volunteer developers mostly want to achieve their own goals at as low amount of effort as possible. This specific audience want to have reliable tools on which they can build strategies and achieve their own goals, but,

  1. A single developer is never reliable
  2. Software ages faster than you can write it
  3. 95% is not 100%
  4. Audience might use the tool in ways different from original intent
  5. Skill of intended audience might not match skill of actual audience

I think people/partners mostly seek (sort of in this order):

  1. Responsiveness to questions and expertise in answers
  2. Ability for someone to investigate and solve problems when they arise
  3. Documentation
  4. A predictable future for tools
  5. Development to achieve their next goals

I think it is perfectly fine to setup a group to assist tool builders with that. Even to become co-maintainers of tools and code, or even fork and replace a tool if required. As long as mutual respect is shown and there is understanding how parties might have different goals, that's fine. —TheDJ (talk • contribs) 11:03, 28 September 2022 (UTC)[reply]

@TheDJ: I've been discussing the possibility of a developer user group (or possibly even a thematic organization) with a couple of people — among other goals, I'm sure it would be in scope to attempt to meet some of the things you mention above — TheresNoTime (talk • they/them) 00:17, 29 September 2022 (UTC)[reply]
@TheDJ @TheresNoTime Thank you so much. Derk-Jan, I think you summarize the conundrum very well, and I am grateful for your balanced view here. Mutual respect, understanding, good communications are absolutely crucial for us (at the hub) and I am keen to learn how we can make this happen in a way that works well for everyone.
@TheresNoTime I'm very curious about your ideas/plans, how far developed they are, and would be very keen to work with you on this! Would you be available for following up? Sandra Fauconnier (WMSE) (talk) 08:13, 11 October 2022 (UTC)[reply]
@Sandra Fauconnier (WMSE): Sure :) there's been some back-and-forth over smaller, "niche" user groups which have technical focuses versus a larger, thematic/encompassing group — there are a number of interested developers on both sides of the argument. Most recently, I contacted the affiliations committee to see what it'd take to get the Wikimedia Tool Developers Group reinstated, as that seemed a logical place to start. Please do feel free to reach out — TheresNoTime (talk • they/them) 08:49, 11 October 2022 (UTC)[reply]
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Talk:Content_Partnerships_Hub/Software/Volunteer_developers_discussion_at_Wikimania_2022&oldid=24347035"