Below you may find the link attached that redirects the user to the corresponding Etherpad: https://etherpad.wikimedia.org/p/wmh2023-Best_practices_%26_ideas_for_implementing

Best practices & ideas for implementing them for high-impact tools & their maintainers.

Date & time: Sunday, May 21st at 10:30 am EEST / 7:30 am UTC

Relevant links

• Phabricator task: https://phabricator.wikimedia.org/T333178
• Proposed practices: https://www.mediawiki.org/wiki/Wikimedia_Technical_Engagement/Practices_to_support_maintainers_and_high-impact_tools#Practices_to_support_tool_maintainers_and_high-impact_tools_at_risk
• Older listing: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_tools

Participants

• Presenters: @srishakatux, @KHernandez-WMF
• Session Coordinators: @debt and @Quiddity

Notes

Introductions by speakers

Overview: taking smaller projects and finding tool maintainers. Sometimes risky - if tools only have one maintainers, or figuring out which tools have more impact and/or need help (might be broken)

Some developers don't know what to work on next and don't know who to ask

Tool problems:

lack clear steps for further development
no clear owner
broken code due to changes in the environment or maintainer is unavailable

how to identify a high impact tool?

 how many people notice that the tool is broken

number of edits by developers

number of tool users   

number of edits the tool makes

ease of use of the tool

tool that's focused on under-represented communities

existing support mechanisms

mentoring initiatives (wikimentor Africa, Hackathons, etc

hackathons

general technical support channel (IRC, telegram)

phabricator

monitoring by toolforge admins

Best Practices

1. getting started - resources to help get going - easily discoverable (starter apps [boilerplate / template code], visual database monitoring tools)
2. tool metrics for developers (number of visits a tool receives, [?])

Best Practices - Support & Mentoring

3. preventing tool developers from reinventing the wheel, empowering them to develop a tool for use by other wikis/projects (not enwiki-only), and tools for wide-spread campaigns.
4. mentoring programs (GSoc, Outreachy) to bring new contributors that do not need hand-holding - that become long term maintainers of code.
5. dedicated technical support for tool developers (prioritizing and managing projects, improving code architecture quality or prototype, reviewing documentation)

Best Practices - Processes

6. project workboard for developers - drawing attention to their tool and issue tracking, to have long-term surviving tools.
7. make finding tools easier - suggestions for alternatives for deprecated tools, allowing comparisons to other tools. Toolhub intends to fill that role but needs better integration into the tools ecosystem.
8. easy process for transferring ownership or transition of a tool (from a tool to Mediawiki extension)
9. tools integration with the MediaWiki CI system (continuous integration) - for more tracking support and better inform when a change will break a tool.

Key questions and tips:

• pick one best practice and brainstorm:
  
  What does a possible solution look like?
  
  How can we get there? What are the key steps to follow? (e.g. research, prototyping, testing)
  
  How can we ensure adoption by tool maintainers?
  
  Are there other practices that can work? recommend them to tool maintainers? would / should we change?

Housekeeping tip:

time for group discussion: 30 min

each group gets ~2 minutes to share outcomes

recruit volunetters for taking notes!

PUT YOUR IDEAS HERE!

• Add metrics to toolhub, (cf. discussions in the session yesterday) about uses, favourites, edits-made, page-visits
• Tried using phabricator, but end-users don't use it. (WMIT WLM). For a single-dev, he decided to just keep a local feature/bug/task-tracker. But for more developers it would be crucial to have a shared centralized tracker.
• (Not sure...) Easy process for transferring ownership or transition - https://wikitech.wikimedia.org/wiki/Help:Toolforge/Abandoned_tool_policy
• Not sure how #9 is crucial. -- Although perhaps if there's a designation of "Critical Tools" that should/must have higher standards? But that's invasive to impose on the community (unless we/they request it!). What about tools that are critical and don't have high-coding standards...?
• Toolhub can definitely solve a lot of these points if we add more features to it. -
• Starter Apps - https://wikitech.wikimedia.org/wiki/Help:Toolforge/How_to#Tutorials (“my first _ tool”)
  • could Striker show these and similar links after a Tool has been created?
  • Maybe these tutorials/first-apps, could be linked from https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker too?

• make finding related-tools easier -
  • Within Toolforge tools, have a banner? (but hard to be consistent beyond Toolforge, and gives false impression of unified platform).
  • For wiki-page tools like userscripts, perhaps a "userbox" style template that links to "See this tool on Toolhub"?

• could tool maintainers mentor outreachy interns? not all maintainers feel like they have the experience to be mentors, and it's also a matter of how much time maintainers can find
• Existing support mechanisms -
  • Google, StackOverflow
  • usually use Telegram (DM to a peer, or if they cannot help then the official Cloud channel), less so Phabricator and mailing lists.
  • Telegram official channel

Find ways to promote internal tools (e.g., Wikimedia's Gitlab, Phabricator, etc).:

• does creating a new tool in toolforge create a new project on gitlab
• maybe create a new account in toolforge as well - at the same time; in general, create automatically all what would be neded. Would it be a problem to create these unnecessarily (if projects do not poceed)?
• need to think about what the end user is needing, espeically when starting a new project
• e.g. start a repo and how to do it, start a new project on Phabricator and how to do it, etc
• log the decisions, version control documentation
• when starting in the various enviroments, and developing your skills, it builds confidence to solve other tasks
• don't create empty boards (especially if you're using external project trackers) - creates confusion
• take a look at abandoned tasks / tools to see if it's still "live" - check when was last edit, contact the author to inquire
• look for the list of tools before creating a new one, there are lists on MediaWiki for tools, but they don't necessarily contain info on if the tool is still "alive"
• will this information be available in ToolHub? last comment, last edit, author, maintainer, any issues, etc
• this would help with new users to learn the ecosystem, investing in researchers to use our tools - they want to know if they use a new tool, they want to know it's being maintained.
• could this also raise an alarm if my own code is getting old - and what impact the tool has with the changing colors (getting old, broken, etc)
• a 'healthy' rating for these tools can be created
• provide a way to identify which tools are highly used but low maintenance - does it have good resilence?
• how would we create / display this indicator?
• could be a tool that doesn't have issues (running well) but doesn't have a maintainer. how do we show this? or be able to contact those maintainers to fix any issues that might come up
• Tool hub does have maintainers list that can be used (not all tools are on toolhub though)
• tools that increase visiblity - where multiple wiki cente

Have toolhub

rs use things, only hear about new things by PyWikiBot

• how many watchers in articles - maybe add to tools (how many watchers); sign up as potential contributor on toolhub
• reviewing quality, checking for breakage, is it high quality code, are there warnings for maintenance needed.
• getting metrics for tools and displaying them - tool usage tracking (taking into account privacy), measuing it's impact
• this might make some developers less confident, but for others, it will help direct their work to the parts that are most needed. developer might trying to solve something else rather than what is urgently needed

Discussing about tools
There are many tools and various tasks to be solved, but it is not easy for newcomers to find out where and how to contribute.

• In some tasks there is a distinction for newcomers and experienced developers.
• volunteers to discuss with newcomers and guide them to appropriate projects based on skills and interests / another idea to be an open day for newcomers with project/platform presentation /survey for newcomers
• OpenRefine is a powerful free, open source tool for working with messy data: cleaning it; transforming it from one format into another; and extending it with web services and external data. Abstracting wikidata
• dedicated volunteers and

Team: PUteam (Plato & Upanishads)
Nivas, Dimitrios, Sevi, Spyros
In our view #3 & #7 are closely related.

1. It is good to have the link to the source code on toolhub or have the source codes under one account
2. (People probably do not find it interesting to go through Toolhub extensively, so..) Have a channel for guidance; people _about to start developing_ could announce their intent and experienced members or devs of similar tools could step in proposing the use or extension of existing tools. This could further be supported by some chatbot, that _knows_ all existing tools and based on their description can propose relevant tools.
3. Add more interactive and engaging content on Developer portal: https://developer.wikimedia.org/, eg short videos, self evaluation tests, gamification (levels, badges, etc).

• Preventing tool developers from reinventing the wheel, empowering them to develop a tool for use by other wikis/projects (not enwiki-only), and tools for wide-spread campaigns.

Presentation notes:

• Group 1
  • ToolHub came up a few times, seems like it's already a useful tool for finding information, figuring out what the important tools are that others use all the time, and how we can help use them more or fix them as needed. Discovery of tools to use, in general. ToolHub itself needs more visibility, one of us didn't know about it.
  • integrating with CI system - making sure new tools don't break older ones. Need to find a way to define critical tools without imposing on the community - how to tell a maintainer their tool is critical and why it is (over other tools). Tools that we want to treat differently and test rigorously.
  • Found tutorials in the toolforge page ("my first python app", etc.) - but not easily discoverable. Could we highlight these tutorials in Striker when you create a new tool? More info for new developers - tutorials.
  • related tools - For onwiki tools, perhaps have a userbox that can link from wiki to toolhub, add those bots to link from your tool or other tools, creating that link
  • support mechanisms - using Telegram to connect with other developers and other official channels - important resource to use. Maybe show more documentation / lists for new folks.

• Group 2
  • two ideas - strategies!
  • need to stop and think what is really needed - Phab project, repos, etc. would be great to have a step by step guide for people to follow
  • Automated pipeline that generates this for you? (Wonder if some of this is implemented already?) Concern: Wouldn't want prototypes to turn into abandoned cruft in Toolforge.
  • be more explicit on the needs each project has
  • Have toolhub be the central place to start
  • to have measures of tool health, might be something that can be automatically inferred
  • have the health of the tool on the tool page, how many issues are open for that tool.
  • would better inform users / devlopers to show the impact of the health of the tool and the need for the tool to be working well.
  • difficult sometimes to understand how a stable tool, has any willing contributors -- Have a way on the Toolhub page for people to sign-up as "willing maintainer if needed".

• Group 3
  • Newcomer perspective. Hosted a satellite event last year.
  • how do newcomers get more informed about Wikidata and the tools available there.
  • sometimes new users feel out of reach / overwhelming at time - lots of things to care about.
  • tools like Open Refine that brings large groups on the same level for easy collaboration
  • need more tools like this, get your hands dirty on the code, see how for the first time - how someone actually works on Wikidata.
  • Does this mean we need more links to real tools/documentation?
  • yes, a platform for newcomers to train on, small tasks to get them more familiar with things, with plenty of documentation available

• Group 4
  • In our view #3 & #7 are closely related. (preventing tool developers from reinventing the wheel) and (make finding tools easier)
  • some tools have links to their code, some have a link to a page that has github link - the link to the tool is there, but the page doesn't exist anymore, so the link to github is now gone
  • When someone is technically capable and sees a problem, they are often eager to start with brand-new code (it's more boring to fix an existing tool, and less community-recognition)
  • if there was a standard (?) to show that there is a problem and I have a solution - or a way for other developers to say - I also have a solution and we can jointly solve the problem
  • maybe propose some projects to work on (using AI?)
  • interactive content for new users (like big corps have - making more gamification, videos, fun things for newcomers to do.
  • assign developers levels and badges. Higher levels for contributing to harder problems.

Thanks a tonne @NicoleLBee for taking notes! Slides are here https://www.mediawiki.org/wiki/File:WMHACK_2023_discussion_session_around_best_practices_for_maintainers_of_high-impact_tools.pdf