Portal:Toolforge/Admin/Monthly meeting/2023-12-19

== Attendees ==
* Bryan Davis
* Seyram Komla Sapaty
* Francesco Negri
* Nicholas Skaggs
* Taavi Väänänen
== Previous meeting action items ==
* Recruit more people to the Standards Committee (Komla?)
* Go through the tool adoption backlog
== Agenda ==
* Grid Engine Update
* Have a non-bouncing email for every tool be a requirement for running on WMCS platforms
== Notes ==
=== Go through the tool adoption backlog ===
* https://phabricator.wikimedia.org/project/view/2457/
* BD: Mostly about tools needing maintainers. Initial team of humans to review this was formed in 2016.
* BD: Taavi has followed up in Phab on some tasks
=== Have a non-bouncing email for every tool be a requirement for running on WMCS platforms ===
* FN: How can we ensure we don’t end up in a place where we can’t migrate or contact maintainers?
* BD: Sounds like a great idea. When proposed, volunteers pushed back very hard and considered it as Spam to get an email that asked them to click a link to confirm they are active and want the tools to be running for the next year?
** phab:T148792
* KS: Maintainers won’t check their email, or only very rarely. Categories of tools with responsive maintainers vs non-responsive maintainers? Maybe sending a mail asking for a response would be a helpful signal to know the maintainers exist. Even if we can’t get a response from everyone.
* FN: If email isn’t working or we can’t contact you, we shut down your tool until you contact us?
* BD: Show me an unpaid service on the internet that you can toss something to run and have it run forever, with no input from you, and where someone else maintains it. It’s not reality. We shouldn’t serve users who are disconnected from this reality. The needs of the majority outweigh the needs of the few in this case.
* TV: Audit admin as well? As for people to respond to emails or remove them?
* NS: We already audit cloud vps projects. Should we audit more things at the same time?
* FN: An advantage of something more automated means we don’t have to do everything at once. Distributing things across the year might be easier, rather than doing things all at once. Community impact may also be less.
* FN: Setup automated system that would consider shutting down tools if email addresses bounce – but not require any input from the maintainer
* TV: That would feel like spam
* FN: What do other cloud providers do? We could send things like “what’s new this quarter”. Could use cloud-announce?
* BD: Cloud-announce doesn’t include everyone
* KS: Our TOU allow us to reach out. We should be allowed to contact users on occasion.
* BD: TOU yes, but the social stigma is still present. Last time trying to implement this, 2 of the most engaged volunteers said NO very strongly.
* BD: Frustrating to hear people complain that we should have done the exact things we have done.
* BD: https://wikitech.wikimedia.org/wiki/User:BryanDavis/Developing_community_norms_for_critical_bots_and_tools
* BD: Now might be a good time to bring up this topic. Need to convey messaging that our efforts to understand what’s being maintained, where the source is, etc, is around tool sustainability. WMCS doesn’t care about wasting compute. But we do care about abandoned tools having an unintended impact when they break. We are doing this in the interest of the community.
* BD: People have had emergencies, been in the hospital, or disappeared for other reasons and caused unintended consequences to user communities.
=== Grid Engine update ===
* TV: Is anything we still have concerns about? How’s it going?
* BD: Did we ever make jsub spit out a warning? (No) 
* BD: Would this be helpful for me to do?
* NS: Is their risk with this?
** TV: Could end up spamming emails if we touch grid submission scripts
* NS: We seem to be progressing well on migrations
* KS: seeing people actually respond and migrate their tools now. The people who are upset seem to be a smaller group.
* NS: Anything to do to ensure we don’t end up providing support next week?
* TV: Finish disabling tools quickly
=== Recruit more people to the Standards Committee ===
* BD: This meeting is more or less the replacement for the standards committee? Completely volunteer run efforts might not be sustainable. Initial goals were to find ways to help tool community and promote best practices
* BD: The original members were 6 people as listed at https://wikitech.wikimedia.org/wiki/Help:Toolforge/Toolforge_standards_committee
* BD: Ideally it would be mostly made up of volunteers
* KS: During the Coolest Tool Awards process I noticed that users prefer decisions being handled by volunteers rather than staff
* FN: What can we do to revitalize the committee?
* BD: We could send a message to the mailing list asking for candidates, as I did in the past at https://wikitech.wikimedia.org/wiki/Help_talk:Toolforge/Toolforge_standards_committee 
* KS: Was the number of 6 volunteers an arbitrary number?
* BD: Yes, we were taking everyone who self-nominated or accepted a nomination. There were 8 people, but 2 did not sign the NDA.
* KS: The committee for Coolest Tool Awards were 7 people. Maybe the number should be increased to share the workload. But I’m not sure what the workload is here.
* BD: Quiddity was in the committee to help the volunteers planning and running meetings, and defining actions. We could think of a “chairperson” role, someone who is responsible for the fact that something happens. Enforcing responsibilities is problematic, but encouraging volunteers can be helpful. It would also be completely reasonable to take this entire question to the mailing list.
* FN: Maybe we should postpone this email to the community until the grid migration is completed in February 2024.
== Action items ==
* Let’s do something about uncontactable maintainers and abandoned tools in Q3/Q4. Related tasks:
** phab:T148792
** phab:T218239
** phab:T320342
* Discuss with the community how to restart the Toolforge Standards Committee. We can use the mailing list and/or the talk page, but we should not start this discussion until the grid migration is completed to avoid having too many discussions at the same time.