Using the term OAuth for an authentication flow that from a user perspective doesn't involve OAuth at all is confusing. PAT[0] is a fairly common term for a long-lived bearer token, used across platforms like GitHub, Azure, Bitbucket, Gitlab and identity systems like Zitadel.
[0] https://en.wikipedia.org/wiki/Personal_access_token
Technical documentation on mediawiki.org benefits from the existence of the [[ https://www.mediawiki.org/wiki/Template:TabbedWindowBegin | TabbedWindow template ]], which relies on https://www.mediawiki.org/wiki/MediaWiki:Gadget-tabbedwindow.js. This template and gadget enables tech docs to show code samples in different languages, in a compact format with tabs for each language.
One example of a content on Wikitech where this would be useful (I'm sure there are many more): https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service/Migration/Rewrite_of_Utility_Services_and_Functions#wikibase:decodeURI()
The most robust code formatting template I'm aware of on wikitech.org, [[ https://wikitech.wikimedia.org/wiki/Template:Codesample | Template:Codesample ]], doesn't allow any sort of display of the same example in a tabbed format for different permutations of the same example.
Document the new/updated dashboards at https://releng-data.wmcloud.org/-/dashboards
Lets add documentation for the new dashboards so its more visible how they can be used. Include:
* https://releng-data.wmcloud.org/-/dashboards/core
* https://releng-data.wmcloud.org/-/dashboards/selenium
* https://releng-data.wmcloud.org/-/dashboards/castor
* https://releng-data.wmcloud.org/-/dashboards/quibble
* https://releng-data.wmcloud.org/-/dashboards/retries
* https://releng-data.wmcloud.org/-/dashboards/ci-load
* https://releng-data.wmcloud.org/-/dashboards/ci-by-repo-and-job
Some of them hasn't been iterated so also make sure to update them. The dashboard should be self-documented but we also need to have summary documentation of what we have and where to get the metrics.
[[https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo/-/blob/main/ADDING_EXTENSIONS.md?ref_type=heads|patchdemo/ADDING_EXTENSIONS.md]] says
> ### 3. add seed data
>
> _Skip if your extension does not have/need test seed data._
>
> Create `mediawiki/files/localSettings/extensions-YOUR_EXTENSION.php` and `mediawiki/files/pages/extensions-YOUR_EXTENSION.txt`. Follow the [README.md in the pages folder](https://gitlab.wikimedia.org/repos/test-platform/catalyst/ci-charts/-/blob/main/mediawiki/files/pages/README.md) on how to populate these files.
but the link is broken, and it's not obvious what would be the right place to look (is it [[https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo/-/blob/main/pages/README.md?ref_type=heads|patchdemo's pages/README.md]]?
It also says
> ### 3. (legacy support) setup LocalSettings.php
>
> _Skip if the only LocalSettings.php line you need is `wfLoadExtension('YOUR_EXTENSION')`, which is added automatically._
>
> Create a `localsettings/extensions-YOUR_EXTENSION.php` and populated it with the same settings you added to `pages/extensions-YOUR_EXTENSION.txt` in the `ci-charts` repo.
but the directory is empty.
The current doc at https://wikitech.wikimedia.org/wiki/Kubernetes/Add_a_new_service covers too many use cases, making it confusing for people that just want to deploy a standard service (ingress, single app container, one port, no specific need).
Combined with the parent task of renaming `python-webapp` to be a generic "start here and don't write a new one" chart, we should create a documentation for adding a new service that only covers the simple case.
Tutorial on converting an existing job using build service to use component services.
https://wikitech.wikimedia.org/wiki/Help:Toolforge/Migrate_build_service_job_to_push_to_deploy
In {T424097}, @Jdforrester-WMF added support for UI schemas into Community Configuration. They should be documented under https://www.mediawiki.org/wiki/Extension:CommunityConfiguration/Technical_documentation (with an example in CommunityConfigurationExample), to make sure other developers can understand the concept.
The documentation should be completed within this task.
Following {T436653}, after the project is complete. The Wikitech Documentation should contain
- Design decisions, tradeoffs
- Operational Procedures
- Usage
This page should be linked to any other page as required and vice versa.
See [[https://wikitech.wikimedia.org/wiki/Data_Platform/Data_Lake/Edits/Editor_counts_per_page | Editor_counts_per_page]] {T429863}
Done:
[ ] Complete https://wikitech.wikimedia.org/wiki/Article_Feature_Counts with all questions and more from SCROLL
[ ] Add link to this doc to https://wikitech.wikimedia.org/wiki/Data_Platform/Data_Lake/Content, a section in https://wikitech.wikimedia.org/wiki/Data_Platform/Discover_data called "Other Data Products", any other relevant sections.
The existing v1 SPARQL endpoint API documentation (that I've been able to find):
https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#SPARQL_endpoint
v2 endpoint API documentation:
https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service/WDQS_Architecture_re-design#API/Interface_Design
As part of the migration to v2 and updating the docs, we should bring this content into alignment with the Wikimedia API style guide and best practices for API reference content, including exploring whether we can publish it as an OpenAPI description: https://www.mediawiki.org/wiki/Documentation/API_documentation#Reference
The current documentation [1] has outdated information and many broken links.
[1] https://www.mediawiki.org/wiki/GitLab/Hosting_a_project_on_GitLab#Migrating_a_project
One of the common use cases I have for collection-level doc metrics is to help guide decision-making about which docs in a collection are important to work on first. I usually use the dashboard within the scope of a specific project, so there are prioritization decisions about which docs to include and which to focus on the most. To that end, it would be helpful if the dashboard could display a list of all pages in the collection, with their aggregate 90-day pageviews and edits, so I can easily see which pages get the most traffic and which are the long tail.
Example of what this would look like (data is made up);
{F98838892}
**Feature summary** (what you would like to be able to do and where):
As a technical writer working with the Wikidata Platform team on documentation to support the migration of WDQS to v2, I need documentation metrics for pages on wikidata.org to help inform prioritization and other doc decisions.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I have created a PagePile of the pages for which I need to view metrics: https://pagepile.toolforge.org/api.php?id=116017&action=get_data&format=html. The dashboard doesn't support pages in this on this wiki.
**Benefits** (why should this be implemented):
Anyone working on docs or technical projects will benefit from being able to get collection-level metrics for tech docs on wikidata.org, just like on Wikitech and mediawiki.org
MediaWiki borrowed the concept of "grant" (bundle of permissions you can grant to an application to use on your behalf) from OAuth 1. OAuth 1 is largely extinct now, and OAuth 2 unhelpfully renamed the concept to "scope". We should probably bite the bullet and rename things:
* the `$wgGrantPermissions` / `$wgGrantPermissionGroups` / `$wgGrantRiskGroups` configuration variables (needs B/C)
* the `GrantPermissions` / `GrantPermissionGroups` / `GrantRiskGroups` fields in `extension.json` (needs B/C)
* the `GrantsInfo` and `GrantsLocalization` classes / services and many of their methods
* the ListGrants special page
* the bot password UI, form handler, the `BotPassword::getGrants()` method, and some of the options / code of `createBotPassword.php`
* maybe the `bp_grants` DB field (might not be worth it)
* maybe a ton of message keys (might not be worth it)
* a bunch of documentation ([[https://www.mediawiki.org/wiki/Manual:Grants|Manual:Grants]], [[https://www.mediawiki.org/wiki/Manual:Bot_passwords|Manual:Bot_passwords]], [[https://www.mediawiki.org/wiki/Manual:Bot_passwords_table|Manual:Bot_passwords_table]]...)
**Feature summary** (what you would like to be able to do and where):
Mention format JSON will not be used in fact.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
1. Visit
https://en.wiktionary.org/wiki/Special:ApiSandbox#action=feedcontributions&user=Example
2. See prominent "format=json", in several places.
3. Hit "Make request".
4. Huh? The result is in format rss.
Ah ha, way over on a different page, way at the bottom, it says:
https://www.mediawiki.org/wiki/API:Feedcontributions#Additional_notes
> Note that if the request is successful, the output will be in the
> format requested by the feedformat parameter. The format requested by
> the standard format parameter (e.g., JSON) will only be used in the
> event of an error.
No wonder. OK, that also needs to be mentioned on
https://en.wiktionary.org/wiki/Special:ApiSandbox#action=feedcontributions&user=Example
too!
**Benefits** (why should this be implemented?):
Else there is no way users can figure out why they picked A but got B.
### To do
Edit the value of `apihelp-feedcontributions-param-feedformat` in [Api/i18n/en.json](https://gerrit.wikimedia.org/g/mediawiki/core/+/master/includes/Api/i18n/en.json) in MediaWiki core. The new value should clarify that `feedformat` overrides `format`, for example: "The format of the feed. This parameter overrides the <code>format</code> parameter." Make sure that the name of any parameters used in the message are wrapped in `<code>` tags so they are not translated.
For information about contributing to MediaWiki core, see the [Gerrit tutorial](https://www.mediawiki.org/wiki/Gerrit/Tutorial) and [How to become a MediaWiki hacker](https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker)
**Feature summary** (what you would like to be able to do and where):
Smarter use of columns on API documentation is called for.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
Browse https://www.mediawiki.org/wiki/API:Feedcontributions
I see:
```
OAuth CID:
1809, OAuth
CID: 1841,
OAuth CID:
4664, OAuth
CID: 5481,
OAuth CID:
6365,
```
Smarter would be
```
OAuth CID: 1809,
OAuth CID: 1841,
OAuth CID: 4664,
OAuth CID: 5481,
OAuth CID: 6365,
```
You might have to use CTRL++ or CTRL+- to reproduce.
**Benefits** (why should this be implemented?):
Else items get shattered even though there is plenty of room,
if whitespace is managed smarter.
Runbooks for WDQS on Wikitech should be reviewed and updated as needed for the new [[ https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/Backend_Replacement | QLever backend that is replacing Blazegraph ]].
* [[ https://wikitech.wikimedia.org/wiki/Wikidata Query Service/Runbook ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikidata Query Service/Runbook/High replication lag and query timeout ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikidata Query Service/Runbook/Update not propagated to WDQS ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikidata Query Service/Runbook/ElevatedMaxLagWDQS ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikidata Query Service/Wikimedia Commons Query Service/Runbook ]]
Additional playbooks found in other places:
* [[ https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_update/Blazegraph_failure_playbook ]]
* [[ https://wikitech.wikimedia.org/wiki/Wikidata_Query_Service/Streaming_Updater#Runbooks ]]
There's also a list of runbooks at https://wikitech.wikimedia.org/wiki/Wikidata_Platform#Runbooks which should be updated to ensure it reflects the relevant pages (or perhaps a category applied to the pages instead).
I created a draft page targeted at tool developers, to gather information about tool performance monitoring and analyzing tool usage: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Monitor_and_analyze_tools
I created this page because this step of the tool developer journey is currently unrepresented in the Toolforge docs, and I've been wanting to fix that for awhile. This may not necessarily be Toolforge-specific information, but the Toolforge docs on Wikitech are the only place I know of where we're providing this type of content for tool devs.
Related:
* We have https://wikitech.wikimedia.org/wiki/Help:Toolforge/Performance, but it is very long, seems targeted at SREs or Toolforge admins (see T347893).
* This work was prompted by the info in [[ https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/message/44IQZWC2BMH7VT5N66DOC736SYQW4HH2/ | this Wikitech-l thread. ]]
* As noted in the wiki page draft, it would be ideal to have a curated list of tools in Toolhub that devs can use to monitor and analyze their tool usage. If /when the work is done to annotate Toolhub records and/or create a curated list of such tools, we should link to that from the wiki page instead of linking directly to tools.
Any edits made using the ChartWizard have a change tag, which links to https://www.mediawiki.org/wiki/Extension:Chart/Wizard
That page on mediawiki.org does not exist yet. We should create it and add documentation about how the ChartWizard works.
NOTE: https://www.mediawiki.org/wiki/Help:Chart_Wizard also exists but is empty and marked as a draft. (could be a redirect to Extension:Chart/Wizard)
[meta:Research:Page view](https://meta.wikimedia.org/wiki/Research:Page_view) has seen very few substantive changes since 2017.
We should edit it to:
- make it a more readable reference for understanding the pageview defintion
- fix any information that's no longer correct
- ensure there's a clear separation between the definitional information on this page and the technical information on Wikitech pages [like the one for pageview_hourly](https://wikitech.wikimedia.org/wiki/Data_Platform/Data_Lake/Traffic/Pageview_hourly).
Also, we should deal with the [generalised filters](https://meta.wikimedia.org/wiki/Research:Page_view/Generalised_filters) and [tags](https://meta.wikimedia.org/wiki/Research:Page_view/Tags) subpages. This likely means incorporating any useful content into the main page or one of the Wikitech pages and then redirecting them to an appropriate destination.
## Summary
This is a generic task regarding our documentation.
As the ML team continues to grow, implement new features, host additional models, and evolve the underlying infrastructure, parts of our documentation have become outdated.
This task is intended to review and update stale documentation to ensure it accurately reflects the current architecture, workflows, deployment procedures, supported features, and operational guidelines.
### Scope
* Review existing documentation for outdated or inaccurate information in [[ https://gerrit.wikimedia.org/r/plugins/gitiles/machinelearning/liftwing/inference-services/ | inference-services ]] repo.
* Update documentation to reflect current infrastructure, services, and workflows on the corresponding wikitech pages.
* Remove obsolete content and update model requests/schemas/examples on LiftWing.
* Ensure documentation follows a consistent structure and style where applicable.
This was brought up in Team challenges in Wikimania 2026.
Currently, In tools admin, you can set a gitlab repo or create a project in Phabricator:
{F96182994}
It would be really nice if we could also set an official documentation space for the tool too. Connect it and advertise it publicly in toolhub. Right now, the documentation around toolforge tools are scattered and hard to find.
My preference would be having something like a wiki page with subpages (e.g. [[ https://wikitech.wikimedia.org/wiki/Tool:Stashbot | Tool:Stashbot ]] in Wikitech) with a pre-filled box but open to other ideas
The Help page for the MediaWiki REST Sandbox, https://www.mediawiki.org/wiki/Help:RestSandbox, should act as a landing page that includes
[ ] Documentation for end users of the REST sandbox
[ ] Contact info for escalations or filing issues
[ ] Navigation / links to other key docs about the REST Sandbox, including:
* Link to instructions for how MediaWiki core developers should document their APIs and test API documentation display
* Link to or include instructions for MediaWiki extension developers: T426851
* Link to or include instructions for external extension developers: T426852
* Link to administrator documentation and other technical docs that explain how the Sandbox is implemented and how to maintain it (MWI team docs? Wikitech?)
It's possible that the latter items should be documented in the page for the RestSandbox as an Extension, but right now it's part of https://www.mediawiki.org/wiki/Extension:WikimediaCustomizations, and I'm not sure what that means for how/where we would put its docs. And, if that's only a temporary state, maybe for now we just use https://www.mediawiki.org/wiki/Category:OpenAPI to be able to find the rapidly-increasing number of pages?
Add 'subtle' and 'progressive' type to document of Message and Toast component, the 2 types above currently supports both in InfoChip and Message/Toast, but document only written in InfoChip, we should add it.
Documentize actionButtonAction prop after the prop merged into main
https://wikitech.wikimedia.org/wiki/Password_and_2FA_reset lacks info how to reset GitLab MFA.
It should probably be covered.
Currently, the Lift Wing OpenAPI docs are stored in the inference-services repository [several separate files](https://gerrit.wikimedia.org/r/plugins/gitiles/machinelearning/liftwing/inference-services/+/refs/heads/main/docs/) (one for each endpoint) and combined via `ref` links in a [top-level file](https://gerrit.wikimedia.org/r/plugins/gitiles/machinelearning/liftwing/inference-services/+/refs/heads/main/docs/openapi.yaml). This helps make the docs easier to maintain, but it presents a few issues:
- Separate files make the docs harder to lint using the [Wikimedia OpenAPI Linter](https://wmf-openapi-linter.toolforge.org/) (CI integration coming soon!). Since the linting rules expect some fields to be present per OpenAPI file, linting each file separately results in some errors that wouldn't apply to a single, unified file. (For example, a missing `contact` field.)
- Separate files make it difficult to use the OpenAPI file for client generation or similar use cases. One of the major benefits of OpenAPI is that, as a machine-readable standard, it can be used to generate client code or for other programmatic uses. With separate files, users would need to repeat their process for each file instead of being able to use one file for all endpoints.
- Fetching information from multiple files makes the MediaWiki REST Sandbox a little slow to load the first time.
Ideally, the solution would be to combine the files into a single file before they are served via the public endpoint, but I'm not sure how feasible this is considering the architecture of that endpoint. Another option is to store the OpenAPI docs as a single file in the repository and remove the per-endpoint files; this would result in a file that is probably ~2,000 lines long at least.
Happy to discuss these options and tradeoffs, and work on a solution that works best for inference-services maintainers!
And the conditions we send them in.
Also include mailto links we provide to donors as in {T396271}
This would be for reference, primarily for DR.
Could link from each to the template is Civi for previewing or perhaps to versions from email team if these are better.
Maybe create a meta page, and link to that? Rather than ensuring some local page on each local wiki.
Needs setting in CommonSettings.php (or InitialiseSettings as appropriate; we can use 'private' to do it for all)
[[https://datatracker.ietf.org/doc/html/rfc8252#section-7.3|the spec says]]
> The authorization server MUST allow any port to be specified at the time of the request for loopback IP redirect URIs, to accommodate clients that obtain an available ephemeral port from the operating system at the time of the request.
and we outsource redirect URI handling during authorization requests to the oauth2-server library which seems to be implement this as written (ie. ports are ignored when matching redirect URIs where the host is 127.0.0.1 or [::1]). This is a non-obvious quirk of OAuth 2, maybe worth calling out in the docs / on the UI (alongside the fact that we don't require HTTPS for localhost/loopback, which I think we also don't really document).
Looks like etcdctl's usage has changed since the [[ https://wikitech.wikimedia.org/wiki/Etcd | etcd wikitech article ]] has been written and the commands don't seem to be working:
```
brett@cumin2002:~$ etcdctl -C https://conf1007.eqiad.wmnet:4001 ls /conftool/v1/pools/eqiad/
Error: unknown command "ls" for "etcdctl"
```
A helpful birdie told me that I need to prepend ETCDCTL_API=2 (and ideally use --endpoints instead of -C). This may be common knowledge for etcd veterans since it appears that the v3 ecosystem has been both in beta and also widely deployed for a while now. But if there are to be examples on the page, maybe it should include these changes!
Update memcached-related documentation on Wikitech to cover Debian upgrade procedures, any configuration changes, and post-upgrade validation steps.
The docs on creating and editing mail aliases [1] are out of date and should be updated to fit the current set up.
[1] https://wikitech.wikimedia.org/wiki/SRE/Clinic_Duty#Mail_aliases
There are several scenarios (some documented on https://www.mediawiki.org/wiki/Parsoid/Parser_Unification/Instructions_for_editors, and others discovered via mw:Parsoid/Feedback) where Parsoid differs from legacy parser's interpretation / rendering of some wikitext.
This is somewhat complicated by the fact that Parsoid uses the preprocessor which the legacy parser also uses for expanding templates. This makes the behavior a bit confusing because certain syntactic forms that are handled normally via transclusions aren't supported by Parsoid when the template page itself is rendered directly. In order to minimize such confusion, we should encourage using syntactic forms that Parsoid directly supports wherever possible. But, it is not possible, right now, to eliminate all such usages because string-concatenation based expansion is extremely common in templates.
All associated wikitext help/syntax pages should be updated to reflect these changes (and explicitly flag the distinction between rendering of Template namespace pages and pages that transclude those templates).
One of the things highlighted by {T423027} is that we needed to restart CI after such an issue.
---
[ ] Document how to restart CI if that does not exist
[ ] Integrate the doc into [[ https://wikitech.wikimedia.org/wiki/Gerrit/Operations#Switch_over | Gerrit's ]]
[ ] //Optional//: Write a cookbook to do it automatically
This is a pretty common extension that lots of parties interact with. It's probably a good idea to get its documentation properly published.
Extension description and repo location: https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor
Some documentation exists at:
https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor/Toolbar_customization
https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:WikiEditor/Toolbar_customization/Library
CodeMirror is an existing extension that has JSDoc that is being published.
https://gerrit.wikimedia.org/g/mediawiki/extensions/CodeMirror
Instructions for JSDoc are at:
https://www.mediawiki.org/wiki/JSDoc
This includes publishing instructions:
https://www.mediawiki.org/wiki/JSDoc#4._Publish_on_doc.wikimedia.org
After setting up publishing, it would then end up at https://doc.wikimedia.org in the MediaWiki Components section
In the [[ https://wikitech.wikimedia.org/wiki/Gerrit/Administration#Forcing_Replication_re-runs | current doc ]] the statement about Github could be improved a bit:
{F77401765}
What should be done? This should be explicitly documented, even if it is just to ask the operator to run `systemctl restart gerrit.service`
**Steps to replicate the issue** (include links if applicable):
* Visit https://doc.wikimedia.org
* Click on Wikibase
* Click on "Storybook (Termbox)", "dist-size (Data-Bridge)", or "dist-size (Tainted-Ref)"
{F77275027}
**What happens?**:
* blank page or 404 page
**What should have happened instead?**:
* either don't include these links at all, or fix them, depending on whether WMDE wants these repos to have JSDoc or not
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
* in {T342905}, WMDE decided they did not want to support JSDoc for the main Wikibase repo. does that decision extend to these repos, too?
**Feature summary**:
Make `tofu import cloudvps_puppet_prefix $ID` possible.
**Use case(s)**:
As a co-maintainer of multiple Cloud VPS projects that predate Tofu usage, I would like to be able to import existing `cloudvps_puppet_prefix` objects so that Tofu can take over management of them.
**Benefits** (why should this be implemented?):
It is currently reasonably possible to create new puppet prefix settings related to a specific instance (named after FQDN), an arbitrary prefix, and project-wide (name empty or `_`). Unfortunately if there is already configuration at any of these name defined levels it is not possible to just overwrite the current config. ~~Instead you have to figure out how to first delete the existing prefix which requires figuring out how to call the `DELETE /v1/<project>/prefix/<prefix>` puppet-enc API directly somehow. You'll probably need to lock Puppet on affected nodes first, then delete the prefix, then recreate it with tofu, and finally unlock Puppet on any instances where you locked it. Possible, but not fun, easy, or obvious.~~
See T423970#12267831 for an explanation of how to find the ID for an existing prefix so that you can then use `tofu import` to add it to the state graph. Once that has happened tofu can update or delete the object.
It would be really nice to have a tool that can also output the tofu config matching a given prefix to make migrating from Horizon managed prefixes to tofu managed versions relative simple.
**Steps to replicate the issue** (include links if applicable):
* Have a toolforge tool that uses a reverse proxy.
** I have the following two proxies configure on my uploadmap tool they had no problems since many month:
```
---
# Service object for routing requests to cdn.example.com
apiVersion: v1
kind: Service
metadata:
name: cdn-map
namespace: tool-uploadmap
spec:
type: ExternalName
externalName: map.leolenz.de
---
# Ingress object for routing requests to cdn.example.com
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: proxy-cdn-map
namespace: tool-uploadmap
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/upstream-vhost: map.leolenz.de
nginx.ingress.kubernetes.io/backend-protocol: https
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"
nginx.ingress.kubernetes.io/proxy-ssl-name: map.leolenz.de
spec:
rules:
- host: uploadmap.toolforge.org
http:
paths:
- backend:
service:
name: cdn-map
port:
number: 443
path: /cdn(/|$)(.*)
pathType: ImplementationSpecific
```
```
---
# Service object for routing requests to cdn.example.com
apiVersion: v1
kind: Service
metadata:
name: cdn-osm-org
namespace: tool-uploadmap
spec:
type: ExternalName
externalName: tile.openstreetmap.org
---
# Ingress object for routing requests to cdn.example.com
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: proxy-cdn-osm-org
namespace: tool-uploadmap
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /$2
nginx.ingress.kubernetes.io/upstream-vhost: tile.openstreetmap.org
nginx.ingress.kubernetes.io/backend-protocol: https
nginx.ingress.kubernetes.io/proxy-ssl-server-name: "on"
nginx.ingress.kubernetes.io/proxy-ssl-name: tile.openstreetmap.org
spec:
rules:
- host: uploadmap.toolforge.org
http:
paths:
- backend:
service:
name: cdn-osm-org
port:
number: 443
path: /osm(/|$)(.*)
pathType: ImplementationSpecific
```
**What happens?**:
* For all content from these proxies I only get 404 errors.
** It is unlikely a problem of the the source servers, as these are two totally different servers they are affected.
** Requesting the data using curl in a shell as the tool works as expected.
**What should have happened instead?**:
* The requested files should be available through the proxies.
**Software version** (on `Special:Version` page; skip for WMF-hosted wikis like Wikipedia):
**Other information** (browser name/version, screenshots, etc.):
The title says it all: the [[ https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Configurable_properties | WDQS user manual on Mediawiki.org ]] will be outdated when the new backend is live. It needs to be updated/rewritten.
This page is more about the entire project than a specific wiki called "Abstract Wikipedia".
**Feature summary** (what you would like to be able to do and where):
There should be a single OpenAPI spec document of all MediaWiki REST API endpoints deployed on Wikimedia sites.
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
As a REST API developer, I want to know which endpoints are available. Currently, this information is scattered in several places:
* https://en.wikipedia.org/w/rest.php/specs/v0/module/- (only some modules)
* https://www.wikidata.org/w/rest.php/wikibase/v1/openapi.json (#wikibase_rest_api_wpp)
* https://en.wikipedia.org/w/rest.php/specs/v0/module/growthexperiments/v0 (#growthexperiments)
* https://en.wikipedia.org/w/rest.php/specs/v0/module/specs/v0 (broken?)
* (Special:RestSandbox also shows some specs that aren’t under `/w/rest.php`, but I would think those are out of scope for this task.)
More specifically, as the developer of a REST API client library (T411325), I want to know which request and response formats are used by existing API endpoints. In [this commit](https://gitlab.wikimedia.org/repos/m3api/m3api-rest/-/commit/bf7b46aaf8), I mistakenly concluded (based only on the first spec linked above) that all JSON-returning endpoints return objects or arrays, not primitives, and designed my API around that; I’ve now discovered that this is not true in Wikibase, and have to adjust my API to account for this (currently in [this commit](https://gitlab.wikimedia.org/repos/m3api/m3api-rest/-/commit/d1c9c240c7), but that will end up being rebased around a bunch of times, so the link will probably be dead at some point; search for a commit message with the subject “Also allow Strings from getJson(), postForJson()”, either on the `fetch` branch or eventually on `main`). This could have been avoided if I had been able to query a merged document for all REST APIs from the beginning.
**Benefits** (why should this be implemented?):
Better information for REST API consumers.
Possibly related: {T416532}
I am trying to install Extension:ReportIncident on my wiki, but I am just stuck at
```
Original exception: [a637c5a75694681cd1034d7a] /wiki/Lipu_open MediaWiki\Config\ConfigException: Config variable ReportIncidentEnabledNamespaces not found in community configuration.Should be requested via MediaWikiConfigRouter instead.
Backtrace:
from /home/taavi/src/mediawiki/extensions/CommunityConfiguration/src/Access/MediaWikiConfigReader.php(111)
#0 /home/taavi/src/mediawiki/extensions/CommunityConfiguration/src/Access/MediaWikiConfigReader.php(123): MediaWiki\Extension\CommunityConfiguration\Access\MediaWikiConfigReader->getConfigByVariableName()
#1 /home/taavi/src/mediawiki/extensions/ReportIncident/src/Services/ReportIncidentController.php(180): MediaWiki\Extension\CommunityConfiguration\Access\MediaWikiConfigReader->get()
#2 /home/taavi/src/mediawiki/extensions/ReportIncident/src/Services/ReportIncidentController.php(29): MediaWiki\Extension\ReportIncident\Services\ReportIncidentController->getLocalConfig()
#3 /home/taavi/src/mediawiki/extensions/ReportIncident/src/Services/ReportIncidentController.php(63): MediaWiki\Extension\ReportIncident\Services\ReportIncidentController->shouldShowButtonForNamespace()
#4 /home/taavi/src/mediawiki/extensions/ReportIncident/src/Hooks/Handlers/MainHooksHandler.php(45): MediaWiki\Extension\ReportIncident\Services\ReportIncidentController->shouldAddMenuItem()
#5 /home/taavi/src/mediawiki/includes/HookContainer/HookContainer.php(135): MediaWiki\Extension\ReportIncident\Hooks\Handlers\MainHooksHandler->onBeforePageDisplay()
#6 /home/taavi/src/mediawiki/includes/HookContainer/HookRunner.php(1023): MediaWiki\HookContainer\HookContainer->run()
#7 /home/taavi/src/mediawiki/includes/Output/OutputPage.php(3301): MediaWiki\HookContainer\HookRunner->onBeforePageDisplay()
#8 /home/taavi/src/mediawiki/includes/Actions/ActionEntryPoint.php(161): MediaWiki\Output\OutputPage->output()
#9 /home/taavi/src/mediawiki/includes/MediaWikiEntryPoint.php(180): MediaWiki\Actions\ActionEntryPoint->execute()
#10 /home/taavi/src/mediawiki/index.php(44): MediaWiki\MediaWikiEntryPoint->run()
#11 {main}
```
I found https://www.mediawiki.org/wiki/Extension:CommunityConfiguration/Developer_setup which has zero information about this. There is also https://www.mediawiki.org/wiki/Extension:CommunityConfiguration/Technical_documentation which says you can run `CommunityConfiguration:ChangeWikiConfig` but that does nothing (except saying `Saved!`) for me. Nor did something like `$wgReportIncidentEnabledNamespaces = [ NS_MAIN, NS_TALK ];` in LocalSettings do anything. Please document how to run the extension.
Information at the following locations should be updated to reflect the current status of the ORES migration / deprecation process. The information on these pages would also benefit from being combined into one reliable resource, and the remaining pages should just link to that single source rather than having duplicate and scattered information that is difficult to find and to maintain:
* https://wikitech.wikimedia.org/wiki/ORES
* https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing/Usage#Differences_using_Lift_Wing_instead_of_ORES
* https://www.mediawiki.org/wiki/Machine_Learning/Modernization#Migration_from_ORES_to_Lift_Wing
Revscoring model endpoints available via Lift Wing API are intended to replace the legacy ORES services, but most of the model cards on Meta-wiki currently only link to or reference ores.wikimedia.org.
Even though ORES may still be available as a service, if we want users to be able to find appropriate replacement endpoints using our preferred, more modern infrastructure, we should update the model cards to facilitate discovery of the appropriate Lift Wing API endpoints. (This will also solve the current issue of [[ https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing#Current_Inference_Services | this table ]] being confusing by linking to model cards that only reference ORES).
## Documentation updates needed
For each of the models listed below:
1. Supplement or replace the ORES links in the model card infobox (template) with links to Lift Wing API docs. ([[ https://meta.wikimedia.org/w/index.php?title=Machine_learning_models/Production/Multilingual_readability_model_card&diff=prev&oldid=30159036 | example change ]])
2. Supplement or replace example ORES API calls in the "Implementation" section of the page with Lift Wing API examples.
3. Check and update all other ORES references on the page, and determine whether to supplement or replace them with Lift Wing references.
4. Verify that the Lift Wing API reference documentation links to the model card on Meta ([[ https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_articletopic_outlink_prediction | example ]]).
* Note that the API portal is going to be shut down (T415293), so it may not be ideal to make these updates there , or it may be the best option for now, as the final location and generation process for Lift Wing API docs is TBD.
## Model cards to update, and their corresponding Lift Wing API endpoints
**Article quality**
* 12 model cards in the "Article quality" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]]
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_articlequality_prediction
**Draft quality**
* Model cards in the "Draft quality" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]] are red links (do we need to create them?)
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_draftquality_prediction
**Damaging edit**
* 33 model cards linked in the "Damaging edit" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]]
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_damaging_prediction
**Goodfaith edit**
* 33 model cards linked in the "Goodfaith edit" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]]
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_goodfaith_prediction
**Revert risk**
* 9 models with red links in the "Revert risk" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]] (do these model cards need to be created?)
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_reverted_prediction
**Article topic**
* 11 model cards linked in the "Article topic" column of [[ https://meta.wikimedia.org/wiki/Machine_learning_models#Revscoring_models | this table ]]
* https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_articletopic_prediction
**Draft topic**
*https://meta.wikimedia.org/wiki/Machine_learning_models/Production/English_Wikipedia_draft_topic
*https://api.wikimedia.org/wiki/Lift_Wing_API/Reference/Get_revscoring_drafttopic_prediction
https://www.mediawiki.org/wiki/Wikidata_Query_Service doesn't talk about the split service and still has the search team as supporting it.
We should iterate and make sure we have the most common uses cases. For example today we have many examples for mediawiki-docker as default. That should be quickstart or fresh.
Also we should look at the most common use cases. Are they captured correctly? Maybe we have other use cases that we should include.
https://www.mediawiki.org/wiki/Selenium
Let's document what we've done and why in a blog post. We should write about our measurements and how we measured it. And then our actual changes and what numbers/metrics it gave us.
**Acceptance criteria:**
* Blog post published about our changes
So far:
- `action=watch`
- `action=query&prop=info`
...
The [Add Link](https://wikitech.wikimedia.org/wiki/Add_Link) Wikitech page contains several information that is no longer up to date. For example, it contains obsolete information on codebase location (see T416877 for more detailed description). Similarly, the instructions on how to run the training no longer apply (as of now, whoever wishes to do that needs to schedule an Airflow DAG on the ML instance).
Let's update the #documentation!
From T416483:
> There's nothing in the wikitech docs about adding an ssh key for codfw1dev ldap, or even a note that you NEED to. A reasonable user would expect their existing eqiad1 key to just work which it definitely does not.
The mediawiki/vendor [[https://github.com/wikimedia/mediawiki-vendor/blob/master/README.md|README]] has a detailed explanation of how to create new patches, but the part on how to merge / deploy them is very vague (basically "ask someone who knows"). The process is nontrivial (or at least used to be, not sure about the exact state today) due to circular dependencies, and the uncertainty around it can make vendor patches a bottleneck - e.g. the train was just delayed by a day because {T416456} blocked it and no one available was confident how to revert a library version bump. There should be clear step-by-step documentation, just like for creating the patch.
**Description:** Préparer toutes les sections de la documentation de Traduc Ivoir' pour l’extension Translate. Ajoutez des balisages de traduction tout en préservant la mise en forme, les titres, les exemples de code, les modèles et les liens. Assurez-vous que chaque unité est correctement segmentée et que la terminologie reste cohérente entre les unités de traduction.
**Domaine:** Documentation (traduction)
**Difficulté:** Difficile
**Étapes pour reproduire:**
- Ajouter des balises `<translate>` autour des parties traduisibles de la documentation.
- Excluer les éléments non traduisibles (par exemple, blocs de code, noms de paramètres) lorsque cela est nécessaire.
- Vérifier que la page s’affiche correctement après avoir ajouté le balisage.
- Activer la traduction de la page dans l’interface de traduction de pages.
**Résultat attendu:** Une page de documentation entièrement marquée, prête pour une traduction multilingue, avec toutes les sections correctement reconnues par l’extension Translate.
**Liens ou références:**
- [[ https://meta.wikimedia.org/wiki/Traduc_Ivoir%27 | Documentation originale en français de Traduc Ivoir’ ]]
- [[ https://www.mediawiki.org/wiki/Help:Extension:Translate/Page_translation_administration | Directives de traduction Wikimedia ]]
**Étapes de mise en place:** Activer les outils d’aperçu du balisage de traduction et d’édition bilingue dans l’interface d’édition.
**Description:** Réorganiser la documentation dans une structure plus claire :
- Présentation
- Fonctionnalités
- Installation
- Contribuer
- Soutien
- Licence
**Domaine:** Documentation
**Difficulté:** Intermédiaire
**Étapes pour reproduire:**
- Analyser la documentation actuelle.
- Identifier les sections manquantes ou mal placées.
- Réécriver la structure en suivant le plan ci-dessus.
**Résultat attendu:** Une documentation bien organisée.
**Liens ou références:**
- [[ https://meta.wikimedia.org/wiki/Traduc_Ivoir%27 | Documentation de Traduc Ivoir’ ]]
- [[ https://www.wikidata.org/wiki/Wikidata:ArchiveExternalLinks | Documentation de ArchiveExternalLinks (exemple) ]]
**Étapes de mise en place:** Aucune.
What can we use from https://curl.se/.well-known/security.txt to update https://en.wikipedia.org/.well-known/security.txt ?
Follows up: {T187617}, {T337949}.
We are missing documentation on how to correctly override hooks in the wdio configuration. The implementation //wdio-mediawik//i take for granted that all hooks are run and if you extend the wdio-configuration and do not call the function you are overriding, things will break.
Acceptance criteria:
* Add documentation with a couple of examples on how to correctly override a couple of hooks
User story:
As a developer writing code to add new functionality for AuthManager, I'd like a tutorial or how-to guide to show me the essential steps to implement a [[ https://doc.wikimedia.org/mediawiki-core/master/php/interfaceMediaWiki_1_1Auth_1_1SecondaryAuthenticationProvider.html | SecondaryAuthenticationProvider ]].
Related requests:
https://www.mediawiki.org/wiki/Manual_talk:SessionManager_and_AuthManager#c-Legoktm-2016-10-27T08:13:00.000Z-Examples
https://phabricator.wikimedia.org/T320349
Existing related content:
https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager#SecondaryAuthenticationProvider
and existing example page for SessionProvider (I find no parallel example page for AuthenticationProvider(s)) https://www.mediawiki.org/wiki/Manual:SessionManager_and_AuthManager/SessionProvider_examples
Both https://wikitech.wikimedia.org/wiki/Backport_windows#Doing_the_deploy and https://wikitech.wikimedia.org/wiki/Backport_windows/Deployers contain very outdated instructions about manually deploying patches, and should probably be replaced with pointers to spiderpig/scap backport?
Domain
Documentation
Level
Advanced
Pula official wiki: https://www.wikidata.org/wiki/Wikidata:PULA
Sample translated wiki: https://www.wikidata.org/wiki/Wikidata:Pula/yo
Use any standard package to add onboarding wizard for mobile app. Follow the color palette and convention
Type
Coding
Level
Intermediate
**Domain:**
Mobile / Code Quality / Documentation
**Difficulty:**
Intermediate
**Problem / steps to reproduce (for bugs)**
- Many React Native components **lack documentation**, making it hard for new developers to use them correctly.
- Props are not clearly explained, which can lead to misuse or bugs.
**Expected outcome / task:**
- Add **component-level documentation** for all React Native components in the mobile app.
- Each component documentation should include:
- **Component name**
- **Purpose / description**
- **Props**: name, type, description, default value (if applicable)
- **Events / callbacks** (if any)
- Use **JSDoc / TypeScript style comments** for components, e.g.:
```ts
/**
* Button component for user actions
*
* @param {string} label - Text to display on the button
* @param {() => void} onPress - Callback fired when button is pressed
* @param {boolean} [disabled=false] - Disable the button
*/
const Button: React.FC<ButtonProps> = ({ label, onPress, disabled = false }) => {
return <TouchableOpacity onPress={onPress} disabled={disabled}><Text>{label}</Text></TouchableOpacity>;
};
**Domain:**
Frontend / Code Quality / Documentation
**Difficulty:**
Intermediate
**Problem / steps to reproduce (for bugs)**
- Many React components in the project **lack proper documentation**, making it harder for other developers to understand how to use them.
- Props are not clearly described, and component purpose is not explained.
- This can lead to misuse, bugs, and slower onboarding for new developers.
**Expected outcome / task:**
- Go through all React components and add **clear documentation** including:
- **Component name**
- **Purpose / description** of the component
- **Props**:
- Name
- Type
- Description
- Default value (if applicable)
- **Events / callbacks** the component emits (if any)
- Use **JSDoc / TypeScript comment style** for components:
```ts
/**
* Button component for user actions
*
* @param {string} label - Text to display on the button
* @param {() => void} onClick - Callback fired when button is clicked
* @param {boolean} [disabled=false] - Disable the button
*/
const Button: React.FC<ButtonProps> = ({ label, onClick, disabled = false }) => {
return <button onClick={onClick} disabled={disabled}>{label}</button>;
};
**Domain:**
Frontend / Backend / Code Quality
**Difficulty:**
Intermediate
**Problem / steps to reproduce (for bugs)**
- Many functions in the project currently **lack proper comments or documentation**.
- This makes it difficult for other developers to understand, maintain, or contribute to the codebase.
- There is no consistent pattern for function documentation across the project.
**Expected outcome / task:**
- Go through the entire codebase and add **clear function-level documentation** for all functions.
- Each function documentation should include:
- **Function name**
- **Purpose / description** of what the function does
- **Parameters**: names, types, and description
- **Return value**: type and description
- Any **side effects** if applicable
- Use standard commenting patterns, e.g. **JSDoc** for JavaScript / TypeScript:
```ts
/**
* Calculates the sum of two numbers.
* @param {number} a - The first number
* @param {number} b - The second number
* @returns {number} The sum of a and b
*/
function sum(a: number, b: number): number {
return a + b;
}
**Feature summary** (what you would like to be able to do and where):
Make the platform more legible and accessible for technical contributors who will write edit checks and suggestions in the future.
**Benefits**:
- Technical contributors can easily start new checks and offer patches to existing ones.
**What does done look like?**
- [ ] A brief overview of `TextMatchEditCheck`, in case the user can be directed there instead
- [ ] A minimal VE + Editcheck dev setup guide for mwcli – eg a pointer to other documentation and `LocalSettings.php` changes.
- [ ] One or two examples
- [ ] Lifecycle documentation
- What listeners exist, when they fire, what data they receive
- What context data is available, eg action tags (dismissal etc), modified ranges, selection
- [x] Brief guide to working in the codebase
- [ ] Pointers to VE data model concepts and a brief overview
- [ ] Examples of how to do the following with the data model:
- Search for strings (modified or otherwise)
- Identify modified nodes
- Identify nodes of a particular type
- [x] Notes on enabling checks for development
- [ ] Pointers to the edit check configuration file and how it's laid out
- [ ] It's clear how to test a check, eg, enabling experimental checks and suggestions
**Timeframe**
I'll seek feedback on this as I tend to underestimate how long it takes me to write text. I think it would be reasonable to target 8 hours, expecting some of the items above to be half an hour and some to be 1.5-2 hours. Generating examples feels harder to scope, I'll aim to outline one full example and the interesting bits of a second one, based on existing code.
Due to T409860 the [[ https://wikitech.wikimedia.org/wiki/HCaptcha | hCaptcha wikitech page ]] is very out of date.
Furthermore, it should be updated to contain the following:
- [ ] proxy design overview
- [ ] incl. anycast setup
- [ ] say the word fallback somewhere in there
- [x] update relevant puppet module paths
- [x] describe how it interacts with common mediawiki userflows <-- this is probably in the trial design docs, pull it out into techwiki
- [ ] runbooks
- [ ] smoke test requests
- [ ] how to depool a VM/site
- [x] fallback mechanism of the extension
**Feature summary**:
Create comprehensive contributor documentation including CONTRIBUTING.md with code style guidelines, development workflow, and testing requirements, plus architecture diagrams showing data flow, class relationships, and cache strategy to help new contributors understand and contribute to Paulina effectively.
**Use case(s)**:
1. A new contributor wants to submit their first pull request to Paulina
- Current behavior: No CONTRIBUTING.md file with guidelines for code style, commit messages, or PR process
- Expected behavior: Clear documentation guides contributors through the entire contribution workflow
2. A developer wants to understand how data flows from Wikidata to the user
- Current behavior: no visual diagram or architecture points to that
- Expected behavior: Architecture diagrams provide visual understanding of system components and data flow
3. A contributor wants to understand the complex copyright calculation logic in pdclasses.py
- Current behavior: Complex business logic has minimal inline comments explaining the legal basis
- Expected behavior: Detailed comments explain the copyright law rules and assumptions behind calculations
4. A new developer encounters an installation error and searches for solutions
- Current behavior: README.md lacks troubleshooting section for common issues
- Expected behavior: Troubleshooting guide helps developers resolve common setup problems
5. A contributor wants to know what code style standards to follow
- Current behavior: No documented code style guidelines (PEP 8 compliance, naming conventions, etc.)
- Expected behavior: CONTRIBUTING.md specifies code quality standards and linting requirements
**Benefits**:
1. **Lower Barrier to Entry**: New contributors can get started quickly with clear documentation
2. **Consistent Quality**: Code style guidelines ensure consistent, maintainable code
3. **Faster Onboarding**: Visual diagrams help developers understand architecture faster than text alone
4. **Better Maintainability**: Well-documented code is easier to maintain and extend
5. **Reduced Support Burden**: Troubleshooting guide reduces repetitive questions
6. **Knowledge Preservation**: Documents complex domain knowledge (copyright law logic)
7. **Community Growth**: Good documentation attracts and retains contributors
== Background and overview
Epic umbrella task for transitioning [[ https://github.com/gruntjs/grunt | Grunt JavaScript task runner ]] tasks into npm scripts in Wikimedia deployed projects.
With the decline of Grunt for many years now, it won't be feasible to use it infinitely without risking modern functionality and abilities and security (read below). The last release dates back to Jan 2023.
In a recent NPM audit **in Oct 2025, a security vulnerability** [[ https://security.snyk.io/vuln/SNYK-JS-INFLIGHT-6095116 | was identified ]], where Grunt, depends on an unmaintained version of Glob.
This task tracks the overall progress while {T246326} serves with examples.
Besides the pure technical transition challenges, we also need to ensure to update documentation and remove mentions of Grunt.
https://www.mediawiki.org/wiki/Continuous_integration/Entry_points
== Goal
Transition Grunt tasks using projects away with npm as current technology choice
== Acceptance criteria for done
[] Transition each of the projects below, orient on https://codesearch.wmcloud.org/deployed/?q="grunt"
[] Remove mentioning of/replace Grunt in documentation
[] Update LibUp configuration
=== Projects (Wikimedia deployed)
**MediaWiki core**
[] MediaWiki Core
**Extensions**
From prior art tasks
[x] T206069 MobileFrontend
[x] T206462 Popups
[x] T295464 ContentTranslation
[x] T266977 MediaViewer (MMV)
Newly captured in this task
[x] #GrowthExperiments
[x] #mediawiki-extensions-readinglists T410437
[] #wikimediacustomizations T428668
**Skins**
[x] Skin:Vector {T242781}
[] Skin:Example
[] Skin:Timeless
[] Skin:MonoBook
[] Skin:Modern
Other projects
==== Prior art
{T246321}
### Description
We need to improve clarity over who should respond to errors and ultimately be responsible for incoming requests across API modules.
### Conditions of acceptance
1. Start with the Core Maintainer's list as a source of truth for clearly owned services to get a sense of what is actually maintained vs not within the API.
a. This includes both Action & REST API modules.
a. Ensure that all modules are accounted for; only a subset are currently in the spreadsheet. The most complete list is likely the [[ https://en.wikipedia.org/wiki/Special:ApiSandbox#action=parse&page=Pet_door&format=json | Special:ApiSandbox ]]"action" dropdown list, if there is not a better scripting or tool alternative.
a. Tag instances that are currently "owned" by teams that might not make sense.
1. Review initial proposal with MWI
======= Out of Scope/Follow up tasks ========
1. Update the API list to include last-touch and/or conceptual owners for unmaintained modules that have APIs.
1. Create an API maintainers list proposal for REST APIs (this should be fairly straightforward)
1. Create a maintainers list proposal for Action API modules
1. Review prospective owning teams (Halley can help with this)
1. Publish 'final' proposal on-wiki
### Implementation details
* [[ https://docs.google.com/spreadsheets/d/1-fcgVYgM0elpTizqN93VEsBINgcs88Gp_6Kw-wrczIs/edit?gid=2132717274#gid=2132717274 | This spreadsheet ]] [WMF staff only for now] can be used as a starting point for documenting the list of APIs & formatting (but feel free to edit as you see fit)
* Use the [[ https://www.mediawiki.org/wiki/Developers/Maintainers#MediaWiki_core | MW maintainer's list ]] as a starting point for extension and feature ownership.
* In cases where the maintainer's list does not illuminate specific ownership, review recent changes in code to determine which team/person might be a good starting point.
* We should have at least some recommendation for every module/API family.
The publication of the draft page https://www.mediawiki.org/wiki/API/Deprecation may create confusing and inconsistent information about API versioning for the impacted APIs:
- The [[ https://www.mediawiki.org/wiki/Wikimedia_REST_API | Wikimedia REST API ]] claims to follow https://www.mediawiki.org/wiki/API_versioning as its versioning policy, but https://www.mediawiki.org/wiki/API/Deprecation applies to that same API.
- https://www.mediawiki.org/wiki/API/Deprecation is not listed in the list of Deprecation policies in https://www.mediawiki.org/wiki/Template:Deprecation_policies
- https://api.wikimedia.org/wiki/Core_REST_API claims to follow [[ https://api.wikimedia.org/wiki/Stability_policy | this stability policy ]] , which currently has no apparent connection to https://www.mediawiki.org/wiki/API/Deprecation
I updated the [[ https://www.mediawiki.org/wiki/API:REST_API | landing page for the MediaWiki REST API ]] to point to the new Deprecation page from its "Versioning" section, but more work is needed here to ensure that the information provided at https://www.mediawiki.org/wiki/API_versioning, and linked to from each API's docs, is consistent. [[ https://www.mediawiki.org/wiki/API/Deprecation#How_does_this_relate_to_existing_stability_policies? | This section of the Deprecation doc ]] alludes to this, but I'm filing this task because:
- we shouldn't let this inconsistent information linger for too long
- we shouldn't let the new Deprecation page be marked for translation if some or all of its content should ultimately be integrated with the existing API_versioning page
Compare [[ https://en.wikipedia.org/wiki/List_of_EC_numbers_(EC_2)?useparsoid=1 | Parsoid ]] vs [[ https://en.wikipedia.org/wiki/List_of_EC_numbers_(EC_2)?useparsoid=0 | Legacy ]] output. If you scroll down to `EC 2.1.1.270: (+)-6a-hydroxymaackiain 3-''O''-methyltransferase` .. you will see that the link renders differently in parsoid & legacy. The actual redlink is the same but legacy's linktext converts the `''O''` to an italicized //`O`//. A number of links on this page are similarly affected.
With a quick test, I cannot reproduce this difference on the CLI. So, needs some more investigation.
https://www.wikifunctions.org/wiki/Wikifunctions:Abstract_Wikipedia/2025_fragment_experiments needs some step-by-step instructions
**Related discussion / context **
https://abstract.wikipedia.org/wiki/Abstract_Wikipedia:Project_chat#Making_it_easier_to_contribute
Alerts are setup that will alert if there are no new metrics produced by Pixel. We need a runbook so everyone in the team can act on the alert and take a first look.
AC:
* Create a runbook that handles:
1. Log into the instance and figure out if the problem is Pixel or metrics just don't get delivered
2. Restart Pixel
3. Redeploy Pixel
@Mhurd do those actions make sense or should it be others that are explained in the runbook?
https://www.mediawiki.org/wiki/Extension:ConfirmEdit documentation doesn't have everything in the root `extension.json` config variables, we should fix that.
See also: {T404716}
This document is about interfaces covered by the stable interface policy so I'm leery about changing it.
The document uses several prefixes. It is unclear whether these prefixes are used in the Turtle dump files. It turns out that the Turtle dump files use data: and s:, not wdata: and wds:. There are other differences.
This difference should be remedied or documented.
As well, there should be a delineation of just what is stable. Is it the triples? Is it the RDF qnames, i.e., including the prefixes? Are repeated @prefix blocks allowable?
The reason the last is important is that some systems that ingest Turtle files allow parallel parsing of parts of the file. This is only guaranteed to work if all the prefixes are in a block at the start of the file.
**Feature summary** (what you would like to be able to do and where):
If you visit https://doc.wikimedia.org/mediawiki-core/1.39.7/php/classMediaWiki_1_1ResourceLoader_1_1StartUpModule.html#details it's not clear you are reading old outdated documentation. Could we put a banner at the top of the page that says "This documentation is outdated" and link to the latest version?
**Use case(s)** (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):
I had a work colleague who ended up on it from a ResourceLoader search which led to outdated code problems (1.39.7 is mentioned but in very tiny text at the top).
We already do this on mw.org with https://www.mediawiki.org/wiki/Template:Update
**Benefits** (why should this be implemented?):
We want
- Google searches presumably will bump newer documentation if old documentation links to it
- Less confusion for new developers
I'm currently adding its first jest tests to the CampaignEvents extension. I followed the [[https://www.mediawiki.org/wiki/Vue.js/Testing | documentation page ]] on mediawiki.org, but it hasn't received substantial updates in 5 years and some parts of it were clearly outdated, like the list of dev dependencies. I updated that because it was obvious, but I'm sure there's more. It then also says you need to create a jest config and a jest setup file, both with some boilerplate code. I ended up copying this from other extensions, and I suppose I'm not the first doing it; this is obviously problematic. I don't have specific preferences on how to make this easier to developers, but I do have some suggestions:
- Update documentation
- Track the dev dependencies in LibUp for automatic updates (would mitigate the issue of the documentation not using latest versions)
- Consider creating a package that brings in all the needed dependencies, as well as extensible config files with sensible defaults (what we do for code checkers like PHPCS, eslint, phan, stylelint)
- Create a phab tag, or column in #mediawiki-core-tests, for reporting bugs. I'm having to tag this task semi-randomly for the time being.
Me falling over it again, in {T404801}...
We don't seem to document anywhere that WebAuthn needs an SSL cert, or otherwise specific configuration to work properly...
At our team page today developers/teams can contact us using Slack or Phabricator. Is that enough? Let's discuss and decide if that who'll be updated. In T384421 we slightly talk about the same thing,
AC:
* Discuss in the team how we want people to contact us.
* If necessary, update the team page
Our team page at https://www.mediawiki.org/wiki/Wikimedia_Testing_Platform is missing the section of what we do, what is our projects. Let's discuss that within the team and then document it on our team page.
AC:
* Define our projects - the projects that we are responsible for as a team
* Is there other areas that is not a project that is our responsibility or should be?
* Update the documentation page
Update our [[ https://www.mediawiki.org/wiki/Wikimedia_Testing_Platform | team page ]] to reflect the teams core values. But first iterate our core values. I think we can use release engineering as a starting point:
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/About
Document WIP: https://docs.google.com/document/d/1sm9J5mzPfelJzycYrXvl9MtqFDmqTnicDRAa5p03Yls/edit?tab=t.0#heading=h.c5xtg0yeoevu
Is there something in that values section that we want to change?
AC:
* Agree what is our core values
* Update the page to reflect them
Please document what these various config vars in the extension mean
```lang=json
"WMEReadingDepthSamplingRate": {
"value": 0
},
"WMEWebUIScrollTrackingSamplingRate": {
"value": 0
},
"WMEWebUIScrollTrackingSamplingRateAnons": {
"value": 0
},
"WMEWebUIScrollTrackingTimeToWaitBeforeScrollUp": {
"value": 0
},
"WMEStatsdBaseUri": {
"value": false
},
"WMEStatsBeaconUri": {
"value": false
},
"WMEEditCampaigns": {
"value": []
},
"WMESchemaEditAttemptStepSamplingRate": {
"value": "0.0625"
},
"MFSchemaEditAttemptStepOversample": {
"value": false
},
"WMEWikidataCompletionSearchClicks": {
"value": []
},
"WMEClientErrorIntakeURL": {
"value": false
},
"WMESessionTick": {
"value": false
},
```
The documentation for Pixel 2 is ready: https://wikitech.wikimedia.org/wiki/Draft:Pixel2
Let someone else in the team review it and give feedback. Four eyes is better than two :) One question though, who is the audience for this documentation?
**AC**:
* Verify that the code examples in the documentation works
* Verify that the documentation is easy to read and understand
* Verify that the documentation is what's needed for the audience for the documentation
* Document the feedback in this task and have session where the document is edited/fixed.
The canonical documentation page for OAuth apps is https://www.mediawiki.org/wiki/OAuth/For_Developers but it's very hard to use, in part because it tries to describe three different workflows (handshake, API request, OIDC-ish) for five different app types (OAuth 1, OAuth 1 owner-only, OAuth 2, OAuth 2 non-confidential, OAuth 2 owner-only; the sixth would be OAuth 1 with RSA but we don't even document that) which all work a bit differently, and in part because it tries to be non-wiki-specific so it only handwaves the relevant URLs instead of actually providing them. It's terrible DX.
We should just have MediaWiki generate the documentation (at `Special:OAuthHelp/<app id>` or something like that) that's relevant for a given app and the current wiki.
Hi,
While configuring `MediaWiki:Are-ratings`, we noticed that the `category` field inside the JSON seems to have no visible effect. [The documentation](https://www.mediawiki.org/wiki/Extension:ArticleRatings) only briefly mentions it and points to Brickipedia as an example, but does not explain its actual purpose or how it should be defined.
From what we understand, it might have been intended either:
1. to automatically place pages with a certain rating into a corresponding category, or
2. to automatically assign a rating to pages in a given category.
However, in practice it seems to do neither. On Brickipedia, some of the `category` entries even point to redlinks with no pages, which makes the feature even harder to interpret.
Could you please clarify what the `category` field is actually supposed to do, and ideally improve the documentation accordingly?
Thanks!
GrowthExperiments has instructions for developer setups available at MediaWiki.org, see https://www.mediawiki.org/wiki/Extension:GrowthExperiments/developer_setup. The documentation mentions several ways to use Suggested edits, some of them use production data (useful if you import articles from production), others include full integration with the Add Link service (requiring only the language of articles to match) and other solutions mock the data from Add Link service using a subpage.
Unfortunately, not all of those solutions are currently working. For example, T402698 includes a report by @SomeRandomDeveloper that the documentation suggests to use https://addlink-simple.toolforge.org/ for mocking the Add Link service output, but that tool is down.
Indeed, https://addlink-simple.toolforge.org currently returns a 404, and the corresponding tool account does not currently exist in Toolforge (maybe the tool was deleted since?).
Within this task, we should review the developer instructions documentation, ensure what it recommends people do is up to date and make any relevant updates (and/or create tasks for them).
We have information on [[https://wikitech.wikimedia.org/wiki/Catalyst|Wikitech for Catalyst]], a stub on [[https://www.mediawiki.org/wiki/Patch_demo|MediaWiki for Patch demo]], the [[https://gitlab.wikimedia.org/repos/test-platform/catalyst/patchdemo|Patch demo README]] and the [[https://gitlab.wikimedia.org/repos/test-platform/catalyst/catalyst-api|Catalyst README]].
We should think about the user flow through this documentation, and what information belongs on what page.
(draft) AC:
- Catalyst wiki page has catalyst information
- Patch demo wiki page has information on Patch demo
The AuthManager-based Action API endpoints (`action=clientlogin` and `action=createeaccount`; there are more but those aren't used much) return a set of JSON objects describing what kind of credentials are expected, and then the client can submit those using dynamic parameters. This isn't obvious, isn't documented very well, and it's not clear what stability guarantees exist for the dynamic parameters (none, but we should state this explicitly).
We are going to need runbooks to help folks figure out what to do when things like the various tofu and magnum failures from https://gitlab.wikimedia.org/repos/releng/zuul/tofu-provisioning/-/merge_requests/29 happen.
There is a small temptation to do docs as code things for this, but discoverability and long term improvement of the docs are more likely if we do it on Wikitech or mediawiki.org. https://wikitech.wikimedia.org/wiki/Nova_Resource:Zuul would be a reasonable place to start building docs. We can move them later if a better home is found.
For users how to setup collections. For the team to refer to when closing tasks related to the old lists feature.
**Steps to replicate the issue** (include links if applicable):
* Navigate to the "posts" section on the Codex docs site main page: https://doc.wikimedia.org/codex/latest/#posts
**What happens?**:
* Notice that each card displays a placeholder thumbnail image because the images provided have a 404 status "not found". For example, the image URL source, https://doc.wikimedia.org/homepage-images/creating-the-wikimedia-design-system.jpg, results in an error:
>Failed to load resource: the server responded with a status of 404 ()
**What should have happened instead?**:
- The image should load with `/codex/latest/` included in its base path: https://doc.wikimedia.org/codex/latest/homepage-images/creating-the-wikimedia-design-system.jpg
**Software version** : Codex v2.2.0
**Other information** (browser name/version, screenshots, etc.):
* Other images that load successfully on this page, such as the Codex logo, have a base path with `/codex/latest/` due to VitePress's base configuration that determines the base path in production, `base: process.env.CODEX_DOC_ROOT || '/'`. In addition, the Codex logo is a static image, and VitePress automatically processes static asset paths. As per https://vitepress.dev/guide/asset-handling#base-url, dynamic asset paths need to be wrapped with the `withBase()` helper function.
* Suggestion: (1) Consider using static assets versus dynamic props, or (2) wrap the URL with `withBase()`.
# Acceptance Criteria
[ ] Ensure VitePress processes the asset path by either using static assets or wrapping the image URLs with `withBase()`.
https://wikitech.wikimedia.org/wiki/Portal:Toolforge/Admin/Striker or some page linked from it should contain documentation that explains how to run Striker database migrations in production.
Roughtly, the process is:
1. Deploy the Striker version with the database changes included with the usual deployment process
1. Acquire the striker admin database credentials from somewhere
1. Shell to a cloudweb hosts, and enter the Striker pod
1. Run manage.py, with the database credential environment variables manually overridden
In https://gerrit.wikimedia.org/r/c/mediawiki/core/+/928902, the `docs/hooks.txt` file was deleted from MW core and we now new hooks docs is now `docs/Hooks.md`.
There are still references to the old `docs/hooks.txt` file: https://codesearch.wmcloud.org/search/?q=hooks.txt&files=&excludeFiles=HISTORY&repos= (HISTORY file excluded), in code and also onwiki docs like: https://www.mediawiki.org/wiki/Template:MediaWikiHook.
We should probably scan for references and update those to point to the new documentation in the .md file?
NOTE: Notice how https://www.mediawiki.org/wiki/Template:MediaWikiHook#Finding_a_hook's_version_and_Gerrit_ID points to a link to `hooks.txt` that is broken.
As a Wikibase user I want to be able to quickly navigate relevant documentation content and links on [MediaWiki](https://www.mediawiki.org/wiki/Wikibase)
It's not all clear to handlers in ingress objects how to handle idempotency so that handler-maintained state converges on what it should be despite processing some things out of order or dealing with concurrent changes from other handlers or even non-handler code.
I'm thinking of high-level classes of listeners to consider:
[] a) Notify users (e.g. email, echo) on page change (mentions page diff)
[] b) Flag a page for a daily digest notification (e.g. email, echo) on page change (mentions page diffs)
[] c) Flag a page as "changed since last seen" for users
[] d) Notify users when a milestone is reached (e.g. edit count eaching 1000)
[] e) Assign autopromote group to a user once a threshold is reached (e.g. "editor" for FlaggedRevs)
[] f) Purge a cache entry (e.g. in memcached) keyed on page ID
[] g) PUT/DELETE a storage object (e.g. in Swift) keyed on page ID
[] h) Purge a cache entry (e.g. in memcached) keyed on (namespace/dbkey) (strongly discouraged)
[] i) PUT/DELETE a storage object (e.g. in Swift) keyed on (namespace/dbkey) (strongly discouraged)
Each of these could use documentation on a page linked from https://www.mediawiki.org/wiki/Manual:Domain_events . This would include things like locking the page row with READ_LOCKING, checking (a) if the row is still there and (b) comparing page_latest if it is there, using those to decide whether to no-op (e.g. when maintaining state) or continue anyway (e.g. when sending notifications). Right now, people writing handlers have to magically know this stuff. If they don't want to do these things, it should at least be a sensible tradeoff (e.g. extra cache purges that don't hurt or the maintained state has a short TTL anyway).
Having a field that can autocomplete from a list of users on a wiki would be useful functionality. This is doable via https://www.mediawiki.org/wiki/Manual:HTMLForm_Tutorial_3#usersmultiselect and https://www.mediawiki.org/wiki/Manual:HTMLForm_Tutorial_3#user
```lang=php
$class = HTMLForm::getClassFromDescriptor( $name, $field );
```
https://www.mediawiki.org/wiki/Extension:ContactPage#Creating_complex_forms isn't great... and requires a few clicks to find the types...
While it's not uncommon, it does happen that extensions (and maybe skins?) have breaking (config) changes that should probably be mentioned at a higher level than just the `git log` of the extension.
We should potentially have a specific section in the mediawiki core RELEASE-NOTES file where things like this can be highlighted.
Useful for things like one "fix" for {T394814}, or {T384064}, where, basically the same issue... some specific config (`LocalSettings.php`) change is needed to save breaking a wiki during upgrade
https://doc.wikimedia.org/codex/latest/components/demos/menu.html#menu-groups
It says "//Avoid mixing menu groups with visible titles and menu groups with visually-hidden titles.//" but the example does not actually mix anything. Both of the titles in the example are hidden, but I believe makes it a "good" example rather than a "bad" example — according to this guideline at least.
{F60317136 height=300}
{F60317162 height=300}
See also:
* {T394829}
Currently the documentation does not contain instructions for what to do if a wiki does not have templates. It does suggest en wiki documentation pages to go along with en wiki templates. However these are complex templates with many dependencies, and they may be hard for small wikis to import, understand (they use Lua) and maintain as they may lack the correct permissions to import rights. Many small wikis will try to copy paste these templates instead of importing them, and this results in broken templates because of missing dependencies.
We should in the documentation include a minimally viable config and template (+ TemplateData) for small wikis that they can copy paste, and don't require import rights.
Draft minimal config which uses the en wiki Citation template: https://www.mediawiki.org/wiki/Citoid/Minimal_config
While many of the config variables are defined in ORES' `extension.json`, many are not.
Similarly, some are documented on https://www.mediawiki.org/wiki/Extension:ORES#Config_variables, but not all of them
Can we please document the rest?
T393876#10812740 being a case where the use of one is not 100% clear.