The state of these docs has evolved since this task was originally filed. I investigated the current state of each of the landing pages and docs they link to; the following improvements are already in place:

Unassigning since I didn't get to this as hoped this quarter, and I'll be on sabbatical for the next 2 months. If I'm able to pick this back up in the future I will do so!

• Designed and implemented new information architecture and subpage structure to support task- and audience-focused navigation, and to align with standard API doc patterns
• Created new Lift Wing API landing page (https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing/API):
  • Added sections for Access policy, Stability policy, Contributing guidelines, Changelog
  • Identified featured apps and added a section for them
  • Published contents of https://wikitech.wikimedia.org/wiki/User:TBurmeister_(WMF)/Sandbox/Machine_learning/API at https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing/API
  • Redirected https://wikitech.wikimedia.org/wiki/Machine_Learning/LiftWing/Usage to point to new page
  • Updated key incoming links that used to point to Machine_Learning/LiftWing/Usage

Hi @UsamaWalayat144242, you are welcome to work on this task, no need to ask for permission first. You can claim it by assigning it to yourself and marking its status as "In progress". Here are some resources to help you as you go:

This is a nice summary of the pending upstream changes to mkdocs in 2.0 (though it should be considered opinionated /not entirely unbiased): https://squidfunk.github.io/mkdocs-material/blog/2026/02/18/mkdocs-2.0/

I also noticed that links in the README at https://gerrit.wikimedia.org/g/research/mwaddlink should be updated to reflect new doc locations, and there's currently a link to https://wikitech.wikimedia.org/wiki/Add_Link which may or may not be in scope for these doc updates

Status update:

• Iterated on content, structure, and design of Lift Wing API landing page. The current (final?) draft brings it into alignment with the API doc patterns outlined in the task description checklist.
• Wrote new overview content and started user guide for "find and understand models" user journey (still an messy draft)
• Started work on breaking the existing Usage page into two user guides, separated by audience (internal vs. external). The external guide includes the required authentication section, and both contain examples. For this doc collection, these pages will replace the standard "quick start" guide, since the way to start quickly differs by audience.

For information about a revision (data computed about the revision), I would lean towards "revision metadata", which is already in use in some places (like https://meta.wikimedia.org/wiki/Page_metadata#Revision_metadata), but conceptually the term "metadata" definitely can include computed or ML-generated data that captures attributes or characteristics of a revision.

Note: This task is related to T406369, but it's TBD whether any of that work is blocked by these model card content updates. There may be a dependency (as noted in the task description) related to how generated API reference documentation links to model cards (we would need to know that the card exists and contains the correct info to link to from each revscoring Lift Wing API endpoint).

@BPirkle I agree with your assessment that I'm approaching from top-down and you from bottom-up; let's rely on @HCoplin-WMF to help us meet in the middle when the time is right! :-)

Yes, I think so, especially since that's the existing pattern for all the Lift Wing API docs and their corresponding model cards.

I just noticed that this service also has some documentation here:
https://meta.wikimedia.org/wiki/Machine_learning_models/Production/add-a-link_model

Hi @Hugoa, the page layout looks really nice, and the information you chose to keep in each box makes sense to summarize each data service/data store. I verified that the information previously contained in the "How to access" paragraph sections for each data service is present on the page for each of those services, so there's no loss of information happening with this change. Removing that "how to access" information from this page is actually great because it reduces duplicate information, and will make it clearer that the page for each data service (not this page) is where to find and maintain that type of content. Thanks for doing this!

Thanks for working on this @Hugoa! I'll take a look on Tuesday (I'm not working Monday), if no one else has had a chance to review before then.

Thanks for the tips and typo fixes :-)

Do we have a clear set of requirements for what types of cross-API browse and discovery journeys we want to support (this is T400743)?

Early, work in progress brainstorming doc for how we may benefit from a data model that describes Wikimedia APIs in a standard way, and ideas for how having that could enable different on-wiki browse options for discovering APIs without having to understand all of them: https://docs.google.com/document/d/18SnHnLi2hJBoEPePRoX0Ca7tWXGRN7TWIE0HyynZLtQ/edit?tab=t.0 (Google doc, publicly visible and open to comments)

Related task: T414527

Hi! I've been exploring related questions from the perspective of: how can we support on-wiki API discovery for users who have no familiarity with our APIs? This type of information-seeking is usually more browse-focused, rather than known-item searching, so we need to understand the attributes that are useful for API users to browse by. We can get this information through user research, but past experience indicates that the key attributes that are most likely relevant are:

• API type (i.e. REST vs. Action)
• Available content formats
• Type of data / data domain
  • To capture the full range of what our APIs offer, this top-level concept must be broader than "text" or "images"; it's a rough division corresponding to the very broad grouping of the most common API use cases: wiki content itself, revisions/editing activity/contributions, data about the wikis or the wiki content (metrics), and generated data like ML predictions. See also meta:Research:Data_introduction (which already attempts to group some APIs into these buckets)
• Access limits / requirements
• Language / wiki project coverage

I removed a property describing the LDF endpoint from the Wikidata item for WDQS: https://www.wikidata.org/w/index.php?title=Q20950365&diff=prev&oldid=2466100467 (feel free to revert if that isn't the right move)

I just completed the majority of the work of merging the documentation for these two extensions into one page at https://www.mediawiki.org/wiki/Extension:OATHAuth.
I have a couple questions and review requests for specific doc sections:

I added the Security category tag to all the above pages that didn't have it, so they can now at least be viewed collectively at https://meta.wikimedia.org/wiki/Category:Security. I updated https://meta.wikimedia.org/wiki/Security to suggest using the category to browse docs.

First draft of a revised Lift Wing API landing page is now visible and being worked on at https://wikitech.wikimedia.org/wiki/User:TBurmeister_(WMF)/Sandbox/Machine_learning/API.

Thanks for working on this, @Junkyard1625! Re: your suggestion that the documentation toolkit should refer to the doc type categories: unfortunately those categories aren't consistently created (nor used) across all the wikis and other places where Wikimedia technical documentation is published, but that documentation toolkit does seek to provide guidance relevant for all those places. So, referring to categories that are only on Wikitech would be too specific for the Toolkit. It's definitely something we can work towards though (having more consistent doc type categories across wikis and other places where tech docs live). Thanks again for all your work on this!

Thanks for doing this! Please go ahead and mark this task as Resolved (I don't want to do it for you, that would take away one of the best parts of working on a task :-))

Hi @MuskanNishad, thanks so much for working on improving Wikimedia technical documentation! If you're still working on this task, could you claim it (assign it to yourself) so that is clear to others? Thanks again!

@Manoj0112 that's great, thanks for wanting to help improve Wikimedia tech docs! Please assign this task to yourself to indicate that you are working on it. If you have questions or need to verify information on the page, I recommend using one of the communication channels outlined there since this documentation is owned by the Cloud Services team: https://wikitech.wikimedia.org/wiki/Help:Toolforge/Java#Communication_and_support.

Thank you @SuhaniSingh24 for investigating this task. Since, as you discovered, the docs have already been revised, I'm marking this task as resolved.

Given that there's an existing category for Security on Meta-Wiki, and it has been pretty consistently applied to differentiate end-user pages from team pages (see https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Documentation), I think perhaps using that category and showing a list of pages in it on https://meta.wikimedia.org/wiki/Security might be the best solution for this (for now), since a full doc survey and IA design for this topic area is not something our teams have planned for this fiscal year.

Rough draft IA based only on existing pages on Meta so far:

Questions to cover: which user groups are required, through technically enforced rules, to have:

• A confirmed email
• 2FA enabled

... more?

These UIs and the on-wiki documentation pages have all been updated as part of T399657.

Thank you @Pppery!

This is perhaps caused by removing "wikimedia-webauthn-ui-login-prompt" from WikimediaMessages in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikimediaMessages/+/1218349/1/i18n/wikimediaoverrides/en.json#56?