I think we should have this session, but I'm looking for help or someone interested in running it.

I think this session lends well to a presentation, but also to a discussion. This can happen in the same session (20' presentation and 35' discussion), or we can also do a discussion with some prompts and questions to kick things off.

I'll add some prompts and ideas of things that have been discussed elsewhere as references.

Hey @Jhernandez and thanks for coordinating this session!
We would love to schedule it in the main track, on Saturday 22nd at 17:00 UTC. Let me know before May 17th if this session is confirmed and if the timeslot works for you :) (a later slot on the same day could also be possible if need be)

After discussions with Joaquin, this session is now scheduled for Friday at 18:00 UTC. Enjoy :)

I'll be around to help facilitate this. Let me know if there's something specific I can help with!

Hi @Jhernandez Thank you so much for organizing this session, I would probably need some help around T237998

In T282265#7103501, @Gopavasanth wrote:

I would probably need some help around T237998

Very interesting! Please attend, we will have time to share and discuss people's situation and challenges around this!

@Jhernandez I would really love to join, but due to the weird time zones I doubt if I can make it :/ That would be so great if any recordings are available post the session :)

Notes from the session https://etherpad.wikimedia.org/p/wmhack21-finding-comaintainers

Thanks everyone for coming!!!

=Finding co-maintainers for your tools=

https://phabricator.wikimedia.org/T282265

==Discussion prompts==

* What is your name?

* Have you built any tools?
** Do you have co-maintainers

* Do you maintain any tools?
** How did you become a co-maintainer?

* What can we do as a community to encourage a culture where people collaborate on software the same way they do on the wikis

== Interesting links ==

* Developing_community_norms_for_critical_bots_and_tools - `bd808`: https://wikitech.wikimedia.org/wiki/User:BryanDavis/Developing_community_norms_for_critical_bots_and_tools
* File:Stealing some of Wikimedia's Principles to Democratize Programming:  https://commons.wikimedia.org/wiki/File:Stealing_some_of_Wikimedia%27s_Principles_to_Democratize_Programming.webm

==Notes==

* Gopa: Anyone interested to join as a co-maintainer of the VideoCutTool ( https://videocuttool.wmflabs.org )?
** https://phabricator.wikimedia.org/tag/videocuttool/
** https://phabricator.wikimedia.org/T237998
** Tech:React, Node
** Needs: Server side maintenance, need to deploy the beta from https://videocuttools.herokuapp.com/ to videocuttool.wmflabs.org
** contact https://www.mediawiki.org/wiki/User:Gopavasanth
**Wiki: https://commons.wikimedia.org/wiki/Commons:VideoCutTool

Anticomposite: What happens when a tool stops working?
What to do when something stops working and users need help
The maintainer just left, single maintainer tools
In that situation, the community must decide to fork & patch, rewrite, or abandon the tool
Co-maintainers help prevent single points of failure
Recent example, ogrebot on commons https://commons.wikimedia.org/wiki/User:OgreBot
* No comaintainers, with the latest replica changes it broke. Now a decision, do we fork it, rewrite it

Joakino: Can we identify critical infrastructure tools that only have a single maintainer?

Anticomposite:. making lists of critical infrastructure tools would be useful, this has been a problem for a very long time. I also have a bunch of tools that only I maintain

Lucas Werkmeister
** maybe worth mentioning: as far as technical access to a tool goes, there is an abandoned tool policy https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy
** doesn't solve problem of code access or understanding
** Policy is last resort, not something desired to have to do

bd808: when did this talk https://wikitech.wikimedia.org/wiki/User:BryanDavis/Developing_community_norms_for_critical_bots_and_tools this was what I was thinking
** not to block people but to help create community norms
** toolhub https://toolhub-demo.wmcloud.org/ doesn't solve this problems yet but we have ideas and hopes to add more features so that we can collect quality signals for these tools and surface them 

krinkle: want to be respectful, but also are a wiki community. 
** Could we have a trust model where people can get added based on roles or something else
** Would be useful to have a point where when a tool receives a lot of traffic, we would start finding a new maintainer before there are problems

bd808: started working in labs, because irc announce bot in #wikimedia-ops channel (jouncebot). Wanted to change how it worked. Got an instant offer to help fix and "became" a co-maintainer
Try to emulate the same behavoir now

AntiComposite
wm-bot is another example of a critical infrastructure tool with a single real maintainer

hauki is also unmaintained

Nicolas Vigneron
has anyone any ideas for tool already abandonned? (the only maintainers is already gone/inactive)

Ainali: Maybe we could have a template to add to your tool page showing who is the maintainer and if it needs others, like a really scaled down GOVERNANCE file

Krinkle: If a tool is created, we could send an email / reminder if the tool only has one maintainer after X time (1 or 6 months), prompt them to add a maintainer or someone else to get access to the tool

Anticomposite:
Flagging in toolsadmin that you are looking for people to help maintain it. May be a good way to help close the gap between people that need help and people that can help

bd808: List of known abandoned/looking for help tools: https://phabricator.wikimedia.org/project/view/2952/

joakin: could we maybe use the opportunity to build new projects and maintainers based in the features of abandoned tools?

amir: depends on the case in my opinion, sometimes it may be worth it, others not so much

bd808: wikistream is open to pass along

I have a tool that I "rescued" that I would be happy to pass on to anyone -- 
https://phabricator.wikimedia.org/T251555
 -- 
https://wikistream.toolforge.org/

joakino: how can gopa find a new co-maintainer? What should they look to do?

anticomposite: find people that are using the tool and know how it works. they are in the position to start doing more things. it is much more difficult if you are coming from the outside, and you are already invested in the project as well
along those lines, add the tag good first task, most people don't want to start been the comaintainer of the tool, because of the perceived responsibility. If they can start with something more simple or easy, that's a good way to get people introduced in the project

aklapper: Use https://phabricator.wikimedia.org/tag/good_first_task/ to help :-)

bd808: Use mailing list, participate in hack sessions, go to community events. Ask for help! Without asking, no one is aware.

amir: help with the jitsi instance at wikimedia, it has complexities with networking and need help. message me and we can talk

joakino: schedule a session in the hackathon, talk about your code, the tech, find people interested

balloons
Demoing the tool is a great way to plug for help 😃

balloons
ways to flagging projects that need help, is that toolhub where that would live?

anticomposite: I suppose you could use a "help needed" tag in toolsadmin, as well as admin.toolforge.org/tools does/doesn't work

joaquin
any happy stories? you are maintaining a tool and you have maintainers, how did it happened?

amir: wdvd wikdiata vandalism tool, been comaintained by me and lukas, we work on it together and is quite nice. it is based on github, so we have the source control, and we have a maintenance bot, gets automatically updated, using PRs. Streamlined processes helped from comaintaining it
amir: I made the tool because we were suffering from vandalism, but had very clear I needed help with it
lukas: we were together in the office and you showed me the tool, and made me a maintainer

nikki
I'm not actually a co-maintainer but I started contributing to lucas's lexemes forms tool, because I use it a lot and I was able to because lucas helps me and answers lots of my questions when I get stuck 😄

Thanks for participating in the Wikimedia Hackathon 2021! We hope you had a great time.

• If this session / event took place: Please change the task status to "resolved" via the Add Action... → Change Status dropdown.
  • If there are specific follow-up tasks from this session / event: Please create dedicated tasks and add another active project tag to those tasks, so others can find those tasks (as likely nobody in the future will look back at Wikimedia-Hackathon-2021 tasks when trying to find something they are interested in).
• In this session / event did not take place: Please set the task status to "declined".

Thank you,
your Hackathon venue housekeeping service

Somewhat offtopic to the point of this session, but I'm perturbed by the stories in Bryan's tales of "I didn't have the source and couldn't get the source". (Why was that tool on Toolforge without a license? Does anyone enforce the Toolforge TOU?) I doubt mine is an original take, but there should be a requirement that not only the source be open but that it be available. And/or a requirement to live on WMF-hosted source repository or at the least be mirrored there. Not just suggestion or 'best practice'. Make it a hard requirement and then enforce it. (Doesn't have to be mean to start with at least.) Check that every tool that gets spun up has a LICENSE file. Check that every tool points to where its source lives in a MAINTAINERS or the README.

It isn't fair to the volunteers who use the tool when a maintainer decides they don't want to volunteer here anymore (for w/e reason). Or the volunteer who has to pick up the pieces of the old tool.

In T282265#7108982, @Izno wrote:

Why was that tool on Toolforge without a license?

Toolforge is a permissive by default system. We have taken small steps over time however. Today when you create a new tool account one of the required fields is selecting a "default license" for any and all code deployed in the tool's $HOME that is not otherwise documented as having a license.

Does anyone enforce the Toolforge TOU?

We do, but we also try very hard not to disrupt existing tools unless they are egregiously in violation of a term. Shutting down an otherwise functional tool for an undeclared or non OSI-approved license would not be an initial step. First we would try asking nicely and pointing to the policy. Shutdown would be an absolute last resort.

I doubt mine is an original take, but there should be a requirement that not only the source be open but that it be available. And/or a requirement to live on WMF-hosted source repository or at the least be mirrored there. Not just suggestion or 'best practice'. Make it a hard requirement and then enforce it. (Doesn't have to be mean to start with at least.) Check that every tool that gets spun up has a LICENSE file. Check that every tool points to where its source lives in a MAINTAINERS or the README.

These all seem reasonable, at least on the surface. Things are not always as simple as this however. If we make creating a tool account a heavy weight process folks are more likely to make one and then cram all the things the do after into that same tool's namespace. That is driving away from a competing goal of tools that do one thing which in turn makes it easier to attract new co-maintainers or to take over if abandoned. Suites like XTools are an anti-pattern from the original Toolserver environment before there was a mechanism for shared ownership.

Similarly, what about the weekend hack experiments or ad hoc scripts to do a quick thing. Should those have to jump the same hurdles of public vcs hosting? Do I need to put any and all utility scripts I write while on a Toolforge bastion into a public vcs with an OSI-approved license before I can run them?

It isn't fair to the volunteers who use the tool when a maintainer decides they don't want to volunteer here anymore (for w/e reason). Or the volunteer who has to pick up the pieces of the old tool.

This I agree with, but I think that it is better handled on the user community side than on the Toolforge hosting environment side. I hope that Toolhub provides easier ways for the community to check things like how many maintainers a tool has, if it has public source code, and if there are clear ways to contact the maintainers to report problems independent of whether the tool is running from Toolforge, Cloud VPS, an arbitrary commercial hosting provider, or a raspberry pi under someone's desk. Once this type of health/quality information is available, I believe that communities can and should think about what criteria should be required for a tool to be actively promoted by a particular community when they are training new members and sharing tips among themselves. It does not hurt the movement for there to be 100 tools that try to fill the same workflow hole. It does hurt the movement to have 1 tool that fills a big hole but that could fail at any minute due to lack of maintenance and support. With better signals the users of a singular critical tool could find that it needs some things to better protect its users and then proactively work with the tool's maintainers to fill those gaps.

I would love for more things to be hosted in Toolforge or Cloud VPS where the Wikimedia technical community has an easier time helping co-maintain and recovering from maintainer loss issues when they arise. I do not think however that requiring that hosting is a short term or long term benefit. That sort of centralization, especially if it came with rigid rules about who/how/what can be done, will lead to stagnation at best and at worst exodus of technical contributors who don't want a central authority telling them how to volunteer any more than the enwiki content creation and curation community wants the Foundation to tell them what the page layout of an article has to look like or what sources are credible/unreliable.

See also T271712: Require tools to host a valid toolinfo.json file (e.g. while upgrading from one Debian version to another) for a random idea I once shared.

In T282265#7109752, @bd808 wrote:

We do, but we also try very hard not to disrupt existing tools unless they are egregiously in violation of a term. Shutting down an otherwise functional tool for an undeclared or non OSI-approved license would not be an initial step. First we would try asking nicely and pointing to the policy. Shutdown would be an absolute last resort.

At the end of the day, someone has to say, "What is the license? We're kicking you off otherwise." So I guess you are saying that's how that works today?

These all seem reasonable, at least on the surface. Things are not always as simple as this however. If we make creating a tool account a heavy weight process folks are more likely to make one and then cram all the things the do after into that same tool's namespace. That is driving away from a competing goal of tools that do one thing which in turn makes it easier to attract new co-maintainers or to take over if abandoned. Suites like XTools are an anti-pattern from the original Toolserver environment before there was a mechanism for shared ownership.

I... don't think I see where making the tool account is a heavy weight process. A checklist goes a long way to "yes, you may use these services". LICENSE? check CODE? check... oh, missing MAINTAINERS? okay, problem. It sounds like headway has been made for new tools, but old tools need the treatment too....

Similarly, what about the weekend hack experiments or ad hoc scripts to do a quick thing. Should those have to jump the same hurdles of public vcs hosting? Do I need to put any and all utility scripts I write while on a Toolforge bastion into a public vcs with an OSI-approved license before I can run them?

Yup, because those ad hoc scripts and hack experiments turn into longterm-hosted tools. You know they do. Xtools (to take your example) didn't magick itself up one day and say "I'm going to be one of the most important central trackers for contributor existence"; someone said "I want a pretty chart of edit count", and then someone else said "I want the number of thanks given", and then someone said "I want to check the contributions on an IP range" and on and on.

If it really really really is a short-term tool (and I mean, could be used no other way than by the person who made the thing for one specific purpose, short in time duration, a true throwaway), I must question whether Toolforge is its right home. We come up with solutions that someone else has here a lot, so I don't really think such short term tools really exist, but maybe you know of some.... (for fun context there are now something like 5 (five) purge a page scripts on en.WP, excluding the copies in user space of those 5).

It isn't fair to the volunteers who use the tool when a maintainer decides they don't want to volunteer here anymore (for w/e reason). Or the volunteer who has to pick up the pieces of the old tool.

This I agree with, but I think that it is better handled on the user community side than on the Toolforge hosting environment side. I hope that Toolhub provides easier ways for the community to check things like how many maintainers a tool has, if it has public source code, and if there are clear ways to contact the maintainers to report problems independent of whether the tool is running from Toolforge, Cloud VPS, an arbitrary commercial hosting provider, or a raspberry pi under someone's desk. Once this type of health/quality information is available, I believe that communities can and should think about what criteria should be required for a tool to be actively promoted by a particular community when they are training new members and sharing tips among themselves. It does not hurt the movement for there to be 100 tools that try to fill the same workflow hole. It does hurt the movement to have 1 tool that fills a big hole but that could fail at any minute due to lack of maintenance and support. With better signals the users of a singular critical tool could find that it needs some things to better protect its users and then proactively work with the tool's maintainers to fill those gaps.

It doesn't work like that. The community is not sufficiently technically minded and further those who are are exhausted doing the stuff they signed themselves up for volunteered for (for an example, Cyberpower has a half dozen bots doing a bunch of different things but I can't get a 2 line fixer implemented in one of them because a) I don't know PHP and b) he's perpetually busy even though c) the issue has been reported for years).

The general community's stance is "make it work". They don't care who or why or when, just make it work. They don't know how to assess such things. All they know is their favorite tool is dead or dying (see reFill, which is a current (pardon) source of much angst and which doesn't have source available). Some get mightily discouraged. I suspect you've seen some of that for that exact tool.

As for many small tools and one big tool, open source encourages the one big tool like reFill (is refill that big? I don't know what you're qualifying as 'big') because we don't want to duplicate someone's work and have the tools (usually) to do something about it. Xtools is good in that respect because it does have enough presence in the community for some of the volunteer (since-hired by WMF and others but not to maintain it) maintainers. Tons of little tools don't.

I would love for more things to be hosted in Toolforge or Cloud VPS where the Wikimedia technical community has an easier time helping co-maintain and recovering from maintainer loss issues when they arise. I do not think however that requiring that hosting is a short term or long term benefit. That sort of centralization, especially if it came with rigid rules about who/how/what can be done, will lead to stagnation at best and at worst exodus of technical contributors who don't want a central authority telling them how to volunteer any more than the enwiki content creation and curation community wants the Foundation to tell them what the page layout of an article has to look like or what sources are credible/unreliable.

I did not intend 'live' on WMF to mean 'canonical copy'. Did you interpret it that way? These things need to be findable and executable from the resources that we have on hand, not require a skip and a hop over to Github. Why? Because there is also often Other Stuff that is required to make the software work in its configuration, etc. Most software doesn't magically start itself. :) Even aside from that, it has obvious benefits like when some API is deprecated (CSRF is recently relevant) being able to find and fix the tool locally even if for some reason the volunteer doesn't want to upstream it to his own canonical source.

I don't think I agree that the general case of what already exists in the TOU is overreach in any sense whatsoever and certainly don't see contributors leaving. It's already in the TOU that they signed (implicitly by using the service). If they aren't willing to comply, there's nothing you can do anyway but kick them off (alternatively ditch the TOU. I don't think you intend to do that). "Telling them how to volunteer" is "you must work on this tool or that one or use specific languages that we may or may not support on our servers", not basic best software engineering practices like "tell us who owns the contributions to that tool that is and provide us a copy so that if you leave, the community doesn't suffer". Even if "give us a copy" is supposedly overbearing, is it worth the frustration 5 years down the road? 10 years? Having the "allow others to continue the same mission you originally started on" clause seems like it fits right in with the open ethos and is even framed positively, not negatively. That's not a sufficient carrot for technical contributors to Wikimedia wikis? Really? Is that someone we truly want in the community? :)

In T282265#7129824, @Izno wrote:

(see reFill, which is a current (pardon) source of much angst and which doesn't have source available)

• https://en.wikipedia.org/wiki/Wikipedia:ReFill
• https://github.com/zhaofengli/refill

T213515: Co-maintainers needed for reFill on Toolforge: ReFill's problem is not lack of source, it is that literally nobody seems to want to maintain it.

I might be thinking of the other citation tool that is now no longer available? I know there was one :^).