User:Waldyrious/Docs

About
MediaWiki documentation is not only infamously incomplete, but also terribly scattered. We have:
 * code comments
 * structured code comments, and corresponding auto-generated docs
 * Note from Jan 2023: the auto-generated docs used to be published for both PHP and JS, but since 1.35 only the JS version has been published in the tagged versions listed in that page. That said, the PHP docs are still present in the  versions (example for 1.35) as well as in the master version. This may be an unintentional issue.
 * MediaWiki pages (manually maintained)
 * the folder
 * some configuration settings described in Extension:Configure
 * message documentation described in the file
 * English Wikipedia
 * Likely others

Ideally, we should be able to have up-to-date and complete documentation wherever we decide to host it. We need a strategy on where to maintain each type of documentation. Recently I proposed a division of MW documentation into 3 main types: Manual (prose/overview), Tutorial (step by step) and Reference (index-like). One of the things I'd like to do is move every non-guide-like content into a separate namespace, e.g. Reference. For more details, I've collected some external resources about good documentation and how to structure them, in this google doc.

Related, but less structurally impactful: some years ago there was some discussion about whether to use a flat or nested hierarchy for Manual pages: Project:Manual. My take on this is that we can easily have both, using redirects and disambiguation pages when needed.

TODO: read Technical communications/Dev wiki consolidation and integrate ideas here as fit. See also this thread.

Like-minded initiatives in the community:
 * User:Zakgreant/MediaWiki Technical Documentation Plan
 * WMF Projects/Technical Documentation
 * User:Yuvipanda/whatcanidoforwikipedia.org
 * MZMcBride's proposal for a developers.wikimedia.org
 * Get involved (mockup)
 * How to contribute
 * Project:New contributors/One ontology (split from the link in the TODO above)
 * User:Krinkle/Content structure, Thread:Project:Current issues/Restructure MediaWiki.org (or: Document how it was and execute it) and Requests for comment/Documentation overhaul
 * Zurich Hackathon etherpad: http://etherpad.wikimedia.org/p/wddh (by Moiz Syed et. al)
 * 65074: Set up dev.wikimedia.org portal (previously Data & Developer Hub)
 * Moving mediawiki documentation from meta to mediawiki.org
 * Engineering Community Team/Developer Relations team
 * In T149372 I proposed defining the structure for MW documentation (something like what's proposed on this page), and mentioned the need to:"[establish] clear expectations for documentation structures and workflows (where it should live, what components it should cover, who has writable access to it, how it can be translated, etc.) in a way that ensures that it can be written in a modular fashion by people who are not the developers themselves. This would, on the one hand, remove bottlenecks and avoid putting the burden of documentation upon a single person/group, and on the other hand, remove barriers to contributors to documentation, no matter who they are." Unfortunately, there were many other concerns (the issue's scope was probably too broad) and the discussion ended up going anywhere.
 * Documentation/Style guide
 * d:Wikidata:Requests for comment/Improving Wikidata documentation for different types of user
 * Technical documentation templates and suggestions
 * User:Pavithraes/Sandbox/Technical documentation prioritization
 * On-wiki documentation & documentation as code: strengths, weaknesses, and compromises (session in the Wikimedia Technical Conference 2019)
 * Documentation/Find docs

Summana suggested on IRC to "ask User:KatieIreneC and Yury Katkov what they think about the developer profiles categorization; they are an education researcher (studying how people learn tech skills) and a MediaWiki enterprise community shepherd, respectively". She also mentioned this link which offers a different categorization (systematic, pragmatic and oportunistic). I intend to analize that and hopefully come up with better terms and a more systematic description (e.g an axis-based system where people can be put according to whether they exhibit more or less of the traits the axes describe).

Proposed structure
Given the above, I believe the structure described in the table below would be encompassing enough to cover most of our docs, and provide a consistent and intuitive top-level navigation system.

Since this is a three-axis structure, it would probably be best implemented using categories, with portals for each of the axes (with some manually curated text and also automatic lists using Extension:CategoryTree and/or Extension:DynamicPageList) so readers can browse by the criteria that makes more sense to them. So we'd have a category hierarchy like: ...where only the leaf categories would be added to each page.
 * MediaWiki documentation
 * by reader type
 * User
 * Sysadmin
 * Developer
 * by documentation type
 * Tutorial
 * Manual
 * Reference
 * Interactive tools
 * Communication (this would of course have other parent categories, not only the documentation one)
 * by topic
 * Classes
 * Extensions
 * Parser
 * Database

Overview of existing resources
NOTE: it would probably make more sense for a complete listing to be sorted by topic. Documentation type and reader type are secondary attributes (this is how many of the disambiguation pages work already). For now, the division as presented below is the most useful in order to identify gaps in documentation (and pages in need to be merged), but after the survey is complete, the user-facing documentation portal should be build using topics as the main organization unit. In fact, maybe we could even prepare a template for disambiguation pages, and the doc portal would consist mostly (apart from a header and footer) of transcluded disambiguation pages.

Reference
or ) available in core and in (WMF-enabled? bundled with mediawiki?) extensions
 * Help:Magic words -- details on parser functions built-in on MediaWiki
 * Help:Extension:ParserFunctions -- details on parser functions from Extension:ParserFunctions
 * Help:Magic words -- double-underscore variables, e.g.
 * Help:Magic words -- magic words, e.g.
 * Manual:Hooks & Category:Hooks by file -- what the names say
 * Extension hook registry -- hooks created by extensions
 * -- probably should be synced with the above
 * Manual:User rights -- default user groups and corresponding rights (excerpt from DefaultSettings.php related to $wgGroupPermissions)
 * Manual:User rights -- list of user rights
 * Manual:User rights -- list of user groups
 * Manual:Namespace constants -- mediawiki's default namespaces and corresponding constants
 * Extension default namespaces -- namespaces introduced by extensions
 * Extension:Scribunto/Lua reference manual -- name says all
 * Extension:Scribunto/Victor's API proposal -- proposal for base mediawiki functions in Lua (not sure what's its status: implemented? in progress? abandoned?)
 * Learning Lua from JavaScript#Differences -- differences from Javascript
 * and -- default list of interwiki prefixes
 * -- list of special pages
 * Manual:$wgSpecialPageGroups -- same as above, sorted into groups
 * Special:SpecialPages -- same as above, but only complete if you hold all user rights
 * meta:Help:Special page -- has some documentation (brief description of what each page does), but with a somewhat loose structure
 * Category:New contributors
 * List of Wikimedia Data Dumps on Meta: https://meta.wikimedia.org/wiki/Data_dumps

Interactive tools

 * Sandbox pages, mySandbox gadget
 * API Sandbox
 * eval.php
 * uselang=qqx
 * Wikimedia technical search
 * Debugging toolbar

Communication

 * Mailing lists
 * IRC
 * Talk pages
 * Technical Village pumps
 * Bugzilla
 * Gerrit
 * Hackathons and other events