One of the current WMF goals is to [establish a single entry point for key technical documentation](https://www.mediawiki.org/wiki/Developer_Advocacy/Developer_Portal).
The site [doc.wikimedia.org](https://doc.wikimedia.org) mostly hosts [auto-generated docs thanks to CI](https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation).
The frontpage of `doc.wikimedia.org` however has seen some custom changes in the last 10 months (see [changelog](https://gerrit.wikimedia.org/r/plugins/gitiles/integration/docroot/+log/master/org/wikimedia/doc/opensource.yaml) of [YAML file](https://gerrit.wikimedia.org/r/plugins/gitiles/integration/docroot/+/master/org/wikimedia/doc/opensource.yaml) defining its content; initiated in 07392c22 by @Krinkle, offering a clean and adaptive layout, sections with boxes (which include programming language information and further links).
To avoid reinventing wheels and https://xkcd.com/927/ , we should explore if doc.wikimedia.org could serve as a base to iterate on.
* Cognitive: Would expanding that page / site try to cover too many use cases (scope becoming too broad) for a reader? (scope creep)
* Social: Shared sense of 'ownership' / gatekeeping / page scope,* Potential target group overload: Current page seems great if you know what you need (//reference//), by technologies / tech areas, for non-newcomers. If it's "I want to do..." it feels harder (//achieve/understand//), by task orientation, also for newcomers (outreach). as 'page maintainers'Would trying to cover different reader purposes ([document types](https://www.mediawiki.org/wiki/Documentation/Style_guide#Deciding_on_a_document_type)) be welcomed?
* Technic* Social: Would expanding the page / site be technically possible and feasible?Shared sense of 'ownership' / gatekeeping / page scope, Structure and organization tbd.as 'page maintainers'? Vague thoughts (not necessarily good ones):Good or bad to have "more chefs in the kitchen"?
** C** Would the top bar be turned into a navigation bar, and have e.g.potentially removing some listed stuff be acceptable? three such [sub]pages (each based on a YAML file) be linked in that top bar,(Scope; to create the topalso different levels of documentation categorizaepths covered in each section?)
* Technical: Would expanding the page / site be technically possible and feasible? Structure and organization tbd. Vague thoughts (not necessarily good ones):
** Could the top bar have a logo (`shared/DocHomePage.php`;be used for navigation, e.g. `lib/wmui-page.css`)include three or five [sub]page "tabs"/links (each based on a YAML file), as the top level of documentation categorization?
** Could there be indexing items per programming language, and then (separate step) allow (on-the-fly?) filtering the view per programming language?
** Could the controlled vocabulary entries per YAML item be expanded, e.g. to add a [document type](https://www.mediawiki.org/wiki/Documentation/Style_guide#Deciding_on_a_document_type) and a non-displayed steward/maintainer entry?
** Could there be 'indexing' items per programming language and document type, and then (separate step) allow (on-the-fly?) filtering the view via checkboxes per programming language and/or per document type (e.g. "show only api references")?
** Could an item have more than one `lang` entry?
** Would load significantly increase / performance decrease? (unlikely?)
** Could the CSS for programming languages be adjusted to have each programming language have a specific background color?
** Could there be a search function? (could be overhead)
** W** Could load significantly increase / performance decrease?the top bar have a logo (`shared/DocHomePage.php`; (unlikely?`lib/wmui-page.css`)