Portal:Toolforge/Tool sweep

From Wikitech
Jump to navigation Jump to search

Tool sweep! (discussion)

It has been nearly a decade since Toolforge came online. Since then, there have a been a lot of improvements to tool infrastructure, but many tools have not yet caught up. We will "sweep" through all tools, checking each one for license compatibility, published source code, privacy compliance, etc. Some tools might no longer be needed and should be archived or deleted. The goal is to support tool maintainers with bringing their tools up to standard rather than criticizing them for not doing so. This is inspired by the English Wikipedia's GA Sweeps project.

How it works

The list of 3,200+ tools is split up into 12 batches, about 250 for each month. Any active Toolforge member is welcome to participate (just don't sweep your own tools). Mark yourself as sweeping the tool, then review the tool based on the below checklist, following the remediation steps as necessary. If you are unsure about anything or want some assistance, ask on the talk page or on #wikimedia-cloud connect. You may also want to ask the maintainer directly.

Once you're done, close the review as 1) no issues, 2) no license, check again in 30 days, 3) issues filed, or 4) tool deleted. Please cross-link any issues filed and notifications left.


Each tool should:

  • Indicate a OSI-approved license in the source code or Toolsadmin/Toolhub metadata
    • Remediation: File an issue for lack of clear license and notify the maintainer on their most active talk page. If there's no follow-up, notify again in 30 days along with an email. If there is no response in 60(?) days, Toolforge administrators will begin the tool archiving process.
  • Have their source code published somewhere, with a link in Toolsadmin/Toolhub metadata or on the tool itself
    • Remediation: File an issue for lack of published source code and notify the maintainer on their most active talk page
  • Not load external resources (e.g. JavaScript/CSS from Google CDN).
    • Remediation: File an issue. Submit a patch if possible.
  • Have tool information and metadata in Toolsadmin or Toolhub
    • Remediation: Try to add the metadata yourself, or file an issue if not possible.

There are plenty of other best practices one could check for when looking at each tool, which reviewers are welcome to so, but it is not part of this process, which is focused on getting tools up to a baseline standard.

Why do this?

Tool authors will create something useful, people grow to depend on it, and then when the original maintainer becomes inactive, someone else comes in to take it over and realizes that it doesn't have a license (e.g. T92963, T314167, T324607) or they don't have access to the source code (e.g. T121279), so it has to be recreated from scratch.

Steps have been taken to address this in newly created tools, which are now required to state a default license, but nothing has been done for older tools (see T190377).

Some tools are no longer necessary for whatever reason, and should be archived and deleted, but that only became possible in October 2022.

For maintainers

Please feel free to go through your tools ahead of time and ensure they're compliant with the above checklist. If you get a notification or an issue is filed against your tool that you don't know how to address, please ask on the talk page or in one of the support channels.

Positive feedback

When maintainers do a good job, either by having compliant tools in the first place, or by fixing issues when pointed out, we should provide them with some sort of positive feedback, like barnstars or WikiLove. TBD.

Same for reviewers that do a good job.