Problem/Motivation
In #3463660: [policy, no patch] Document high-level API concepts in an easier format we decided to consolidate high level documentation into markdown files, and then publish them via gitlab pages. Opening this to plan the concrete steps to do that.
Steps to reproduce
Proposed resolution
Initially I think we should do something along these lines, better plans are welcome:
1. Convert docs for one subystem to markdown. In #3463660: [policy, no patch] Document high-level API concepts in an easier format I used the example of the cache API because I'm familiar with it and the docs are very much split between api.drupal.org and the handbook, but we could pick another one. Issue for this at #3582253: Markdown docs for cache API
2. Set up gitlab pages for core on gitlab pages to publish the files in that directory. This should give us a single page that's published then.
3. Review and fix the format/structure of that page so that we're reasonably happy with it.
4. Open issues to do other subsystems.
As we're doing this, we should also remove the .api.php high level documentation, and replace the handbook pages with links or redirects to the new markdown documentation, so that we go from documentation in two places to having it in on place, instead of three. But that should probably be part of step 4
Comments
Comment #2
catchCache docs notes via the other issue:
Existing docs are in these two places:
https://api.drupal.org/api/drupal/core%21core.api.php/group/cache/11.x
https://www.drupal.org/docs/8/api/cache-api/cache-api
This would move to a new docs/cache.md file.
Symfony and Laravel pages for comparison:
https://symfony.com/doc/current/components/cache.html
https://laravel.com/docs/11.x/cache
Comment #3
catchComment #4
phenaproximaI would suggest starting with adding the necessary infrastructure to core. A
docsdirectory, based on mkdocs (or Zensical, a cross-compatible mkdocs fork used by Drupal CMS), plus CI jobs to preview and publish those docs. We could probably take prior art from Drupal CMS.Then, in a second issue, we add a single subsystem's documentation -- Cache API sounds like a great choice -- fully manually, no AI whatsoever.
Why no AI? Because we want to be sure we do it properly once, and arrive at what we agree is a good result; that way, any AI-assisted follow-up conversions have at least one good example to look at.
Comment #5
catchI haven't used it, but gitlab_templates has a solution to build gitlab pages too, haven't compared it to what Drupal CMS does. Copy and pasting from one of those sounds good though.
https://project.pages.drupalcode.org/gitlab_templates/jobs/pages/
I'll open a new issue for the cache API now. I can be postponed on this one although the actual docs could be worked on in parallel.
Comment #6
phenaproximaCMS is similar, but goes its own way. For core, I'm in favor of following the path gitlab_templates has laid out.
Comment #7
catchComment #8
nicxvan commented