Migrate docs to Zensical, expand dev docs#357
Open
PGijsbers wants to merge 14 commits into
Open
Conversation
Normal deployment of the REST API is unaffected by ES. It is only when developers want to use it for migration tests that it matters.
PGijsbers
added
documentation
Contributor
WalkthroughThis PR restructures project documentation and migrates the documentation build tooling from mkdocs-material to Zensical. Changes include a reorganized mkdocs.yml navigation, updated Dockerfiles and pyproject.toml extras, and new/rewritten documentation covering contributing guidelines, code of conduct, CI/CD, development setup, code architecture, database schema, project overview, migration guide, and a phased roadmap. Some previously existing docs (project overview, database index) had content removed. Pre-commit configuration was adjusted to handle Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've found 5 issues, and left some high level feedback:
- There are a few spelling/typo issues in the new docs (e.g.,
Pyhon-based API,uv pip instal -e ".[dev]", missing space inThecodefield) that are worth correcting for clarity and polish. - The
!! tip "Can't connect to Docker?"block indocs/development/documentation.mdlikely won't render as an admonition with Zensical; consider changing it to a standard admonition syntax (e.g.,!!! tip) to match the rest of the docs. - In
docs/development/setup.mdthepyproject.tomllink is empty ([pyproject.toml]()); it would be helpful to point this to the actual file or remove the link if not needed.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- There are a few spelling/typo issues in the new docs (e.g., `Pyhon-based API`, `uv pip instal -e ".[dev]"`, missing space in `The`code` field`) that are worth correcting for clarity and polish.
- The `!! tip "Can't connect to Docker?"` block in `docs/development/documentation.md` likely won't render as an admonition with Zensical; consider changing it to a standard admonition syntax (e.g., `!!! tip`) to match the rest of the docs.
- In `docs/development/setup.md` the `pyproject.toml` link is empty (`[pyproject.toml]()`); it would be helpful to point this to the actual file or remove the link if not needed.
## Individual Comments
### Comment 1
<location path="docs/migration.md" line_range="20-22" />
<code_context>
-# RFC 9457 Errors
-Errors will follow the RFC9457 standard. However, the original "code" is preserved through a custom field.
+## Standardized Errors
+The Pyhon-based API will return different HTTP status codes depending on the error (for example, returning `404 NOT FOUND` if a requested dataset does not exist).
+Moreover, the body of the response will contain a JSON body that adheres to the RFC9457 standard.
+
</code_context>
<issue_to_address>
**issue (typo):** Correct the typo in "Pyhon-based API".
```suggestion
## Standardized Errors
The Python-based API will return different HTTP status codes depending on the error (for example, returning `404 NOT FOUND` if a requested dataset does not exist).
Moreover, the body of the response will contain a JSON body that adheres to the RFC9457 standard.
```
</issue_to_address>
### Comment 2
<location path="docs/roadmap.md" line_range="2" />
<code_context>
+The REST API is currently under development.
+It's does not yet have feature parity with the PHP-based REST API.
+We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026.
+The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services.
</code_context>
<issue_to_address>
**issue (typo):** Fix grammar in "It's does not yet have feature parity".
Please change this sentence to either "It does not yet have feature parity" or "It's not yet at feature parity" to fix the grammatical error.
```suggestion
It does not yet have feature parity with the PHP-based REST API.
```
</issue_to_address>
### Comment 3
<location path="docs/roadmap.md" line_range="4" />
<code_context>
+The REST API is currently under development.
+It's does not yet have feature parity with the PHP-based REST API.
+We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026.
+The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services.
+
+## Phase 1: Achieve Feature Parity
</code_context>
<issue_to_address>
**issue (typo):** Correct "will be depend on" to "will depend on".
This wording is ungrammatical; please update it as suggested in the summary.
```suggestion
The sunset date of the PHP-based REST API will depend on the progress of this reimplementation and that of some other required server services.
```
</issue_to_address>
### Comment 4
<location path="docs/roadmap.md" line_range="34" />
<code_context>
+
+
+## Other Services
+Besides the REST API, there are a few other components which need to be developed:
+
+ - A logstash pipeline to populate ES indices based on the database data and/or a message queue. Currently, the PHP-based REST API directly puts documents into ES indices, which makes it prone to getting out of sync, and requires an ES server to run to use/test the API in ways which otherwise to not require an ES index.
+ - Evaluation Engine. A service which computes meta-features for datasets, including the "qualities" and "features" you find with datasets.
</code_context>
<issue_to_address>
**suggestion (typo):** Tidy up grammar in the sentence about ES indices and usage.
The phrase "in ways which otherwise to not require an ES index" is grammatically incorrect. Please change it to "in ways which otherwise would not require an ES index".
```suggestion
- A logstash pipeline to populate ES indices based on the database data and/or a message queue. Currently, the PHP-based REST API directly puts documents into ES indices, which makes it prone to getting out of sync, and requires an ES server to run to use/test the API in ways which otherwise would not require an ES index.
```
</issue_to_address>
### Comment 5
<location path="docs/development/project_overview.md" line_range="15" />
<code_context>
+
+
+The REST API should always be deployed with access to a database.
+In production, these services are deployed in a kubernetes cluster.
+A typical request flow would then follow this pattern:
+
</code_context>
<issue_to_address>
**nitpick (typo):** Capitalize "Kubernetes".
Please capitalize "Kubernetes" here to match standard usage.
```suggestion
In production, these services are deployed in a Kubernetes cluster.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+20
to
+22
| ## Standardized Errors | ||
| The Pyhon-based API will return different HTTP status codes depending on the error (for example, returning `404 NOT FOUND` if a requested dataset does not exist). | ||
| Moreover, the body of the response will contain a JSON body that adheres to the RFC9457 standard. |
Contributor
There was a problem hiding this comment.
issue (typo): Correct the typo in "Pyhon-based API".
Suggested change
| ## Standardized Errors | |
| The Pyhon-based API will return different HTTP status codes depending on the error (for example, returning `404 NOT FOUND` if a requested dataset does not exist). | |
| Moreover, the body of the response will contain a JSON body that adheres to the RFC9457 standard. | |
| ## Standardized Errors | |
| The Python-based API will return different HTTP status codes depending on the error (for example, returning `404 NOT FOUND` if a requested dataset does not exist). | |
| Moreover, the body of the response will contain a JSON body that adheres to the RFC9457 standard. |
| @@ -0,0 +1,35 @@ | |||
| The REST API is currently under development. | |||
| It's does not yet have feature parity with the PHP-based REST API. | |||
Contributor
There was a problem hiding this comment.
issue (typo): Fix grammar in "It's does not yet have feature parity".
Please change this sentence to either "It does not yet have feature parity" or "It's not yet at feature parity" to fix the grammatical error.
Suggested change
| It's does not yet have feature parity with the PHP-based REST API. | |
| It does not yet have feature parity with the PHP-based REST API. |
| The REST API is currently under development. | ||
| It's does not yet have feature parity with the PHP-based REST API. | ||
| We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026. | ||
| The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services. |
Contributor
There was a problem hiding this comment.
issue (typo): Correct "will be depend on" to "will depend on".
This wording is ungrammatical; please update it as suggested in the summary.
Suggested change
| The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services. | |
| The sunset date of the PHP-based REST API will depend on the progress of this reimplementation and that of some other required server services. |
| ## Other Services | ||
| Besides the REST API, there are a few other components which need to be developed: | ||
|
|
||
| - A logstash pipeline to populate ES indices based on the database data and/or a message queue. Currently, the PHP-based REST API directly puts documents into ES indices, which makes it prone to getting out of sync, and requires an ES server to run to use/test the API in ways which otherwise to not require an ES index. |
Contributor
There was a problem hiding this comment.
suggestion (typo): Tidy up grammar in the sentence about ES indices and usage.
The phrase "in ways which otherwise to not require an ES index" is grammatically incorrect. Please change it to "in ways which otherwise would not require an ES index".
Suggested change
| - A logstash pipeline to populate ES indices based on the database data and/or a message queue. Currently, the PHP-based REST API directly puts documents into ES indices, which makes it prone to getting out of sync, and requires an ES server to run to use/test the API in ways which otherwise to not require an ES index. | |
| - A logstash pipeline to populate ES indices based on the database data and/or a message queue. Currently, the PHP-based REST API directly puts documents into ES indices, which makes it prone to getting out of sync, and requires an ES server to run to use/test the API in ways which otherwise would not require an ES index. |
|
|
||
|
|
||
| The REST API should always be deployed with access to a database. | ||
| In production, these services are deployed in a kubernetes cluster. |
Contributor
There was a problem hiding this comment.
nitpick (typo): Capitalize "Kubernetes".
Please capitalize "Kubernetes" here to match standard usage.
Suggested change
| In production, these services are deployed in a kubernetes cluster. | |
| In production, these services are deployed in a Kubernetes cluster. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #357 +/- ##
=======================================
Coverage 94.56% 94.56%
=======================================
Files 77 77
Lines 3774 3774
Branches 247 247
=======================================
Hits 3569 3569
Misses 137 137
Partials 68 68 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 10
🧹 Nitpick comments (3)
docker/docs/Dockerfile (1)
1-3: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winSpecify a non-root USER in the Dockerfile.
Trivy flags that the container runs as root (DS-0002). Since this Dockerfile is being modified for the Zensical migration, consider adding a
USERdirective to run as a non-root user. If thezensical/zensicalbase image provides a non-root user, reference it explicitly; otherwise create one.🔒 Suggested non-root USER directive
FROM zensical/zensical ENTRYPOINT ["zensical"] CMD ["serve", "--dev-addr=0.0.0.0:8000"] + +USER ${ZENSICAL_USER:-zensical}If the base image does not define a non-root user, create one explicitly:
FROM zensical/zensical + +RUN useradd --create-home --shell /bin/bash zensical +USER zensical + ENTRYPOINT ["zensical"] CMD ["serve", "--dev-addr=0.0.0.0:8000"]🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docker/docs/Dockerfile` around lines 1 - 3, The Dockerfile currently launches the container as root because it only sets FROM, ENTRYPOINT, and CMD; add a USER directive in this Dockerfile so the runtime uses a non-root account. Check whether the zensical/zensical base image already defines a suitable non-root user and reference it explicitly, otherwise create a dedicated user in the image before the ENTRYPOINT/CMD setup.Source: Linters/SAST tools
docs/development/code.md (1)
145-148: 📐 Maintainability & Code Quality | 🔵 TrivialFill or remove the empty SQLAlchemy section.
### SQLAlchemyis currently blank, so this reads like a missing section rather than intentional structure.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/development/code.md` around lines 145 - 148, The SQLAlchemy section in the documentation is empty, so either add the intended content under the “SQLAlchemy” heading or remove that heading entirely if it is not meant to exist. Update the nearby “ORM usage” section in the same docs file so the structure reads intentionally, and keep the heading hierarchy consistent with the rest of the document.docs/development/documentation.md (1)
1-13: 📐 Maintainability & Code Quality | 🔵 TrivialUpdate the page title to Zensical.
The page already describes Zensical, so keeping the old
mkdocs-materialheading makes it look stale.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@docs/development/documentation.md` around lines 1 - 13, The page heading still says “Documentation with mkdocs-material” even though the content is about Zensical, so update the top-level title in the documentation page to match Zensical. Use the existing documentation page content as the source of truth and adjust the main heading near the start of the file so the page title aligns with the referenced framework.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/contributing/index.md`:
- Around line 45-53: The “Help Wanted” restriction in the contributing guide is
too broad and reads as if it blocks all community contributions, which conflicts
with the earlier docs exception. Update the wording in the contributing docs
section so it applies only to code contributions, or add an explicit exemption
for documentation fixes, keeping the restriction aligned with the existing
minor-docs allowance.
- Around line 30-31: The link in the contributing docs points to the project
overview instead of the documentation workflow page. Update the reference in the
text near the “Developer Documentation” link so it targets the documentation
contribution page (the one currently using project_overview.md) and make sure
the surrounding wording still matches the docs workflow guidance.
In `@docs/development/documentation.md`:
- Around line 45-47: The admonition in the documentation is using an invalid
MkDocs marker, so it will not render as a tip. Update the existing tip block in
the documentation to use the proper MkDocs admonition syntax with the valid tip
marker, and keep the content under that block unchanged; this is the section
that starts with the “Can’t connect to Docker?” tip.
- Around line 35-39: The documentation example uses the module invocation form
instead of the CLI entrypoint; update the build-and-serve instructions in
documentation.md to use the same zensical serve command as the package
entrypoint and docker/docs/Dockerfile. Locate the command block in the docs
section and replace the python -m invocation with the CLI form so the documented
usage matches the actual runtime entrypoint.
In `@docs/development/setup.md`:
- Around line 21-26: The setup snippet in docs/development/setup.md has two
issues: the pyproject.toml reference is missing its target, and the uv install
command misspells install. Update the documentation around the dependency
installation example so the pyproject.toml link points to the actual file, and
correct the uv command in the same snippet to use the proper uv pip install
invocation while keeping the existing ".[dev]" extra. Use the surrounding setup
example to locate the markdown block.
In `@docs/index.md`:
- Around line 7-20: The heading structure in the docs page skips a level, which
breaks the outline. Update the section headings under the page title in the
markdown content so they use a consistent hierarchy, either by promoting the
current ### sections to ## or by inserting an intermediate ## section before
them. Keep the existing section titles in place and ensure the structure in
docs/index.md remains sequential.
In `@docs/installation.md`:
- Around line 9-12: The Swagger Docs URL is currently presented as if it is
always available on localhost:8001, but that only applies when the
port-published compose setup is used. Update the installation instructions in
the docs so the Swagger URL appears only under the branch that uses
compose.ports.yaml, or explicitly state that http://localhost:8001/docs is
reachable only after publishing the port with the port overlay. Use the
surrounding install steps and the REST API/Swagger docs text to keep the scope
clear.
In `@docs/migration.md`:
- Around line 39-47: Clarify the RFC 9457 field contract in the migration docs:
the `type` field should be described as the problem URI, not the legacy numeric
error code. Update the wording in this section to state that
`src/core/errors.py` still emits the numeric identifier separately in `code`,
and that clients should use `type` to identify the problem while treating `code`
as deprecated migration support.
In `@docs/roadmap.md`:
- Around line 1-4: Tighten the opening paragraph in the roadmap copy by fixing
the two grammar issues: change the phrasing in the introductory text so “It’s
does not yet” becomes a correct sentence, and update the sentence about the
PHP-based REST API sunset so “will be depend” is corrected. Keep the same
meaning while cleaning the wording in the paragraph content.
In `@mkdocs.yml`:
- Around line 18-40: The nested Development navigation label is duplicated,
causing redundant breadcrumbs; update the inner Development section in mkdocs
nav to a distinct name like Guides or Workflow. Adjust the nav entry that groups
Getting Started, Writing Code, Writing Tests, CI/CD, and Documentation so the
top-level Development item remains unchanged while the nested group uses a
unique label.
---
Nitpick comments:
In `@docker/docs/Dockerfile`:
- Around line 1-3: The Dockerfile currently launches the container as root
because it only sets FROM, ENTRYPOINT, and CMD; add a USER directive in this
Dockerfile so the runtime uses a non-root account. Check whether the
zensical/zensical base image already defines a suitable non-root user and
reference it explicitly, otherwise create a dedicated user in the image before
the ENTRYPOINT/CMD setup.
In `@docs/development/code.md`:
- Around line 145-148: The SQLAlchemy section in the documentation is empty, so
either add the intended content under the “SQLAlchemy” heading or remove that
heading entirely if it is not meant to exist. Update the nearby “ORM usage”
section in the same docs file so the structure reads intentionally, and keep the
heading hierarchy consistent with the rest of the document.
In `@docs/development/documentation.md`:
- Around line 1-13: The page heading still says “Documentation with
mkdocs-material” even though the content is about Zensical, so update the
top-level title in the documentation page to match Zensical. Use the existing
documentation page content as the source of truth and adjust the main heading
near the start of the file so the page title aligns with the referenced
framework.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro
Run ID: 37f4ca06-3cd5-45c2-a00d-1f853553d33d
📒 Files selected for processing (22)
.pre-commit-config.yamldocker/docs/Dockerfiledocker/python/Dockerfiledocs/contributing/code_of_conduct.mddocs/contributing/index.mddocs/contributing/project_overview.mddocs/database/index.mddocs/development/CI_CD.mddocs/development/code.mddocs/development/database/index.mddocs/development/database/openml.mddocs/development/database/openml_expdb.mddocs/development/documentation.mddocs/development/project_overview.mddocs/development/setup.mddocs/development/tests.mddocs/index.mddocs/installation.mddocs/migration.mddocs/roadmap.mdmkdocs.ymlpyproject.toml
💤 Files with no reviewable changes (2)
- docs/database/index.md
- docs/contributing/project_overview.md
Comment on lines
+30
to
+31
| in the "[Code](#code)" section of this page. Then, visit the "[Developer Documentation](../development/project_overview.md)" | ||
| page to learn how to contribute documentation changes. |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
sed -n '1,120p' docs/development/project_overview.md
printf '\n---\n'
sed -n '1,160p' docs/development/documentation.mdRepository: openml/server-api
Length of output: 8078
Point this link at the docs workflow page Update the destination to ../development/documentation.md; project_overview.md is the repo overview, not the page that explains how to contribute documentation.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributing/index.md` around lines 30 - 31, The link in the
contributing docs points to the project overview instead of the documentation
workflow page. Update the reference in the text near the “Developer
Documentation” link so it targets the documentation contribution page (the one
currently using project_overview.md) and make sure the surrounding wording still
matches the docs workflow guidance.
Comment on lines
+45
to
+53
| !!! info "Help Wanted?" | ||
|
|
||
| We learned that working with community contributions during the development of | ||
| the first feature-complete release of the REST API is complicated. | ||
| While we are entirely grateful that so many people take an interest and want to help, | ||
| the majority of the work is figuring out what the desired behavior and interface of the | ||
| REST API should be. Making these decisions requires a lot of context about the OpenML platform, | ||
| ecosystem, and its history. For this reason, we restrict community contributions in this | ||
| project to issues that are marked "Good First Issue" or "Help Wanted" for now. |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟠 Major | ⚡ Quick win
Scope the “Help Wanted” restriction to code contributions.
As written, this reads like a blanket rule for all community contributions and conflicts with the earlier allowance for minor documentation PRs. Narrow it to code work, or explicitly exempt docs fixes.
🔧 Suggested wording
- For this reason, we restrict community contributions in this project to issues that are marked "Good First Issue" or "Help Wanted" for now.
+ For code contributions, we currently restrict new work to issues that are marked "Good First Issue" or "Help Wanted".📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| !!! info "Help Wanted?" | |
| We learned that working with community contributions during the development of | |
| the first feature-complete release of the REST API is complicated. | |
| While we are entirely grateful that so many people take an interest and want to help, | |
| the majority of the work is figuring out what the desired behavior and interface of the | |
| REST API should be. Making these decisions requires a lot of context about the OpenML platform, | |
| ecosystem, and its history. For this reason, we restrict community contributions in this | |
| project to issues that are marked "Good First Issue" or "Help Wanted" for now. | |
| !!! info "Help Wanted?" | |
| We learned that working with community contributions during the development of | |
| the first feature-complete release of the REST API is complicated. | |
| While we are entirely grateful that so many people take an interest and want to help, | |
| the majority of the work is figuring out what the desired behavior and interface of the | |
| REST API should be. Making these decisions requires a lot of context about the OpenML platform, | |
| ecosystem, and its history. For this reason, for code contributions, we currently restrict new work | |
| to issues that are marked "Good First Issue" or "Help Wanted". |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/contributing/index.md` around lines 45 - 53, The “Help Wanted”
restriction in the contributing guide is too broad and reads as if it blocks all
community contributions, which conflicts with the earlier docs exception. Update
the wording in the contributing docs section so it applies only to code
contributions, or add an explicit exemption for documentation fixes, keeping the
restriction aligned with the existing minor-docs allowance.
Comment on lines
35
to
39
| You can then build and serve the documentation with | ||
|
|
||
| ```bash | ||
| python -m mkdocs serve | ||
| python -m zensical serve | ||
| ``` |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== files ==\n'
git ls-files 'docs/development/documentation.md' 'docker/docs/Dockerfile' 'pyproject.toml' 'setup.py' 'setup.cfg' 'zensical*' | sed 's#^`#-` #'
printf '\n== docs/development/documentation.md (relevant lines) ==\n'
sed -n '1,120p' docs/development/documentation.md | cat -n | sed -n '25,55p'
printf '\n== docker/docs/Dockerfile ==\n'
sed -n '1,220p' docker/docs/Dockerfile | cat -n
printf '\n== search for zensical entrypoints/usages ==\n'
rg -n --hidden --glob '!**/.git/**' -S 'python -m zensical|zensical serve|console_scripts|entry_points|name = "zensical"|project\.scripts|tool\.poetry\.scripts' .Repository: openml/server-api
Length of output: 1533
🌐 Web query:
zensical python -m zensical __main__ console script serve PyPI
💡 Result:
Zensical is a modern static site generator designed for technical documentation, written in Rust and Python and distributed as a Python package on PyPI [1][2]. The command zensical serve is the primary method for running a built-in web server to preview your documentation site locally [3][4]. When executed, this command starts a local server that hosts the generated site, typically binding to localhost by default [3]. Key details regarding its usage include: - Installation: It can be installed using pip or uv (e.g., pip install zensical) [2][4]. - CLI Usage: You can specify the host and port for the preview server using the --dev-addr flag (e.g., zensical serve --dev-addr localhost:7777) [4]. - Integration: It is often managed via task runners or automation tools like Makefiles, which wrap the zensical serve command to simplify the developer workflow [4]. - Containerization: In environments such as Docker, the zensical command is often used as the entrypoint with serve as the default argument (e.g., CMD ["serve", "--dev-addr=0.0.0.0:8000"]) to expose the preview server [5]. Regarding main, as a standard Python package with a console script entry point, zensical leverages the Python entry point mechanism to execute the CLI directly from the terminal without needing to manually invoke the module (i.e., you run zensical rather than python -m zensical) [1][4]. Documentation and further technical specifications can be found at the official Zensical website [1][2].
Citations:
- 1: https://pypi.org/project/zensical/
- 2: https://zensical.org/docs/get-started/
- 3: https://zensical.org/docs/setup/basics/
- 4: https://github.com/practicalli/engineering-playbook/blob/main/docs/technical-writing/static-site/zensical.md
- 5: https://github.com/zensical/zensical/blob/master/Dockerfile
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== pyproject.toml ==\n'
sed -n '1,260p' pyproject.toml | cat -n
printf '\n== package/module files ==\n'
fd -a '(__main__\.py|zensical)' . || true
printf '\n== search for project metadata mentioning zensical ==\n'
rg -n --hidden --glob '!**/.git/**' -S 'zensical|tool\.poetry|project\.name|project.scripts|console_scripts|__main__' pyproject.toml docs docker .Repository: openml/server-api
Length of output: 7071
Use the CLI form here zensical serve matches docker/docs/Dockerfile and the package’s entrypoint; python -m zensical serve should be replaced in docs/development/documentation.md.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/development/documentation.md` around lines 35 - 39, The documentation
example uses the module invocation form instead of the CLI entrypoint; update
the build-and-serve instructions in documentation.md to use the same zensical
serve command as the package entrypoint and docker/docs/Dockerfile. Locate the
command block in the docs section and replace the python -m invocation with the
CLI form so the documented usage matches the actual runtime entrypoint.
Comment on lines
+45
to
+47
| !! tip "Can't connect to Docker?" | ||
|
|
||
| If the docker container is running but you cannot access it, it's likely that you did not correctly specify the compose files to include `compose.ports.yaml`. |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== Relevant section ==\n'
sed -n '35,55p' docs/development/documentation.md
printf '\n== Admonition markers in docs ==\n'
rg -n '!!!|!! ' docs . -g '!**/.git/**' || true
printf '\n== Docs tooling/config hints ==\n'
rg -n 'mkdocs|admonition|material|pymdown|markdown_extensions|tip' mkdocs.yml docs . -g '!**/.git/**' || trueRepository: openml/server-api
Length of output: 9439
Use !!! tip here !! tip is not a valid MkDocs admonition marker, so this block won’t render as a tip.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/development/documentation.md` around lines 45 - 47, The admonition in
the documentation is using an invalid MkDocs marker, so it will not render as a
tip. Update the existing tip block in the documentation to use the proper MkDocs
admonition syntax with the valid tip marker, and keep the content under that
block unchanged; this is the section that starts with the “Can’t connect to
Docker?” tip.
Comment on lines
+21
to
+26
| We can use [`uv`](https://docs.astral.sh/uv/) to easily install the required dependencies from our [pyproject.toml](). | ||
|
|
||
| ```bash | ||
| python -m pip install uv | ||
| uv pip instal -e ".[dev]" | ||
| ``` |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
printf '\n== files ==\n'
git ls-files docs/development/setup.md pyproject.toml
printf '\n== docs/development/setup.md (lines 1-80) ==\n'
cat -n docs/development/setup.md | sed -n '1,80p'
printf '\n== pyproject.toml (top section) ==\n'
cat -n pyproject.toml | sed -n '1,220p'Repository: openml/server-api
Length of output: 9771
Fix the install snippet in docs/development/setup.md:21-26 — the pyproject.toml link is empty and uv pip instal should be uv pip install; the dev extra is defined in pyproject.toml, so ".[dev]" is fine.
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 21-21: No empty links
(MD042, no-empty-links)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/development/setup.md` around lines 21 - 26, The setup snippet in
docs/development/setup.md has two issues: the pyproject.toml reference is
missing its target, and the uv install command misspells install. Update the
documentation around the dependency installation example so the pyproject.toml
link points to the actual file, and correct the uv command in the same snippet
to use the proper uv pip install invocation while keeping the existing ".[dev]"
extra. Use the surrounding setup example to locate the markdown block.
Source: Linters/SAST tools
Comment on lines
+7
to
+20
| ### What's changed? | ||
| For an overview about how the REST API is changing, visit the | ||
| [migration guide](migration.md). | ||
|
|
||
|
|
||
| ### Why a new REST API? | ||
| The current production REST API has been with us for over a decade, and is still trotting along. | ||
| However, it's built on a number of technologies which fell out of favor and some of its design decisions do not match current-day expectations. | ||
| The current REST API would need significant refactoring to bring it up-to-date. | ||
|
|
||
| Instead, we chose to reimplement the REST API in Python, since most of our core developers are more familiar with it than PHP, it has good packages and tooling for modern software development, and it's more familiar to the ML community. | ||
| We hope that a Python-based REST API will be easier to understand, maintain, and extend by future contributors. | ||
|
|
||
|
|
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Fix the heading hierarchy.
Jumping straight from the page title to ### breaks the outline and will trip MD001. Promote these subsections to ##, or add an intermediate ## section.
Suggested fix
-### What's changed?
+## What's changed?
...
-### Why a new REST API?
+## Why a new REST API?📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| ### What's changed? | |
| For an overview about how the REST API is changing, visit the | |
| [migration guide](migration.md). | |
| ### Why a new REST API? | |
| The current production REST API has been with us for over a decade, and is still trotting along. | |
| However, it's built on a number of technologies which fell out of favor and some of its design decisions do not match current-day expectations. | |
| The current REST API would need significant refactoring to bring it up-to-date. | |
| Instead, we chose to reimplement the REST API in Python, since most of our core developers are more familiar with it than PHP, it has good packages and tooling for modern software development, and it's more familiar to the ML community. | |
| We hope that a Python-based REST API will be easier to understand, maintain, and extend by future contributors. | |
| ## What's changed? | |
| For an overview about how the REST API is changing, visit the | |
| [migration guide](migration.md). | |
| ## Why a new REST API? | |
| The current production REST API has been with us for over a decade, and is still trotting along. | |
| However, it's built on a number of technologies which fell out of favor and some of its design decisions do not match current-day expectations. | |
| The current REST API would need significant refactoring to bring it up-to-date. | |
| Instead, we chose to reimplement the REST API in Python, since most of our core developers are more familiar with it than PHP, it has good packages and tooling for modern software development, and it's more familiar to the ML community. | |
| We hope that a Python-based REST API will be easier to understand, maintain, and extend by future contributors. |
🧰 Tools
🪛 markdownlint-cli2 (0.22.1)
[warning] 7-7: Heading levels should only increment by one level at a time
Expected: h2; Actual: h3
(MD001, heading-increment)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/index.md` around lines 7 - 20, The heading structure in the docs page
skips a level, which breaks the outline. Update the section headings under the
page title in the markdown content so they use a consistent hierarchy, either by
promoting the current ### sections to ## or by inserting an intermediate ##
section before them. Keep the existing section titles in place and ensure the
structure in docs/index.md remains sequential.
Source: Linters/SAST tools
Comment on lines
+9
to
+12
| It should suffice to run the services from a fresh clone by running `docker compose up python-api -d`. | ||
| If you want to make sure to bind the exposed container ports to the host machine then you will need to use the `compose.ports.yaml` file too (`docker compose -f compose.yaml -f compose.ports.yaml up python-api -d`). | ||
| The REST API will then be exposed on port 8001 on the host machine. To visit the Swagger Docs, visit http://localhost:8001/docs. | ||
|
|
||
| Once the containers are started, you can run tests with `docker compose exec python-api python -m pytest -m "not php_api" tests`. | ||
| For migration testing, which compares output of the Python-based REST API with the old PHP-based one, also start the PHP server (`docker compose --profile "apis" up -d`) and include tests with the `php_api` marker/fixture: `docker compose exec python-api python -m pytest tests`. | ||
|
|
||
| !!! note | ||
| The REST API will then be exposed on port 8001 on the host machine. | ||
| To visit the Swagger Docs which show REST API endpoint documentation, visit http://localhost:8001/docs. |
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Scope the Swagger URL to the port-published setup.
docker compose up python-api -d does not necessarily expose 8001 on the host; only the compose.ports.yaml overlay does. Move the docs URL under that branch, or say explicitly that it only works after publishing the port.
Suggested fix
-It should suffice to run the services from a fresh clone by running `docker compose up python-api -d`.
-If you want to make sure to bind the exposed container ports to the host machine then you will need to use the `compose.ports.yaml` file too (`docker compose -f compose.yaml -f compose.ports.yaml up python-api -d`).
-The REST API will then be exposed on port 8001 on the host machine.
-To visit the Swagger Docs which show REST API endpoint documentation, visit http://localhost:8001/docs.
+It should suffice to run the services from a fresh clone by running `docker compose up python-api -d`.
+If you also need the Swagger docs on the host, include `compose.ports.yaml` too:
+`docker compose -f compose.yaml -f compose.ports.yaml up python-api -d`.
+Once the port is published, the REST API will be exposed on port 8001 and the Swagger docs will be available at `http://localhost:8001/docs`.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| It should suffice to run the services from a fresh clone by running `docker compose up python-api -d`. | |
| If you want to make sure to bind the exposed container ports to the host machine then you will need to use the `compose.ports.yaml` file too (`docker compose -f compose.yaml -f compose.ports.yaml up python-api -d`). | |
| The REST API will then be exposed on port 8001 on the host machine. To visit the Swagger Docs, visit http://localhost:8001/docs. | |
| Once the containers are started, you can run tests with `docker compose exec python-api python -m pytest -m "not php_api" tests`. | |
| For migration testing, which compares output of the Python-based REST API with the old PHP-based one, also start the PHP server (`docker compose --profile "apis" up -d`) and include tests with the `php_api` marker/fixture: `docker compose exec python-api python -m pytest tests`. | |
| !!! note | |
| The REST API will then be exposed on port 8001 on the host machine. | |
| To visit the Swagger Docs which show REST API endpoint documentation, visit http://localhost:8001/docs. | |
| It should suffice to run the services from a fresh clone by running `docker compose up python-api -d`. | |
| If you also need the Swagger docs on the host, include `compose.ports.yaml` too: | |
| `docker compose -f compose.yaml -f compose.ports.yaml up python-api -d`. | |
| Once the port is published, the REST API will be exposed on port 8001 and the Swagger docs will be available at `http://localhost:8001/docs`. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/installation.md` around lines 9 - 12, The Swagger Docs URL is currently
presented as if it is always available on localhost:8001, but that only applies
when the port-published compose setup is used. Update the installation
instructions in the docs so the Swagger URL appears only under the branch that
uses compose.ports.yaml, or explicitly state that http://localhost:8001/docs is
reachable only after publishing the port with the port overlay. Use the
surrounding install steps and the REST API/Swagger docs text to keep the scope
clear.
Comment on lines
+39
to
+47
| As per the RFC9457 standard, the `type` field now includes the unique code for the error. | ||
| You will notice that the response still contains a `code` of "111" (though as a top level property not embedded in the "error" scope). | ||
|
|
||
| The `title` field is a human readable summary of the general issue and the `detail` field may provide additional information for the specific request. | ||
| The URIs provided through `type` _will_ be resolvable in the future, providing a page with more information. | ||
|
|
||
| !!! warning | ||
|
|
||
| The`code` field is only included to support the migration of clients, but should be considered **deprecated**. Prefer to use the `type` field to identify the error. |
Contributor
There was a problem hiding this comment.
🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick win
Clarify the RFC 9457 field contract.
type is the problem URI, not the legacy numeric code. src/core/errors.py still emits the legacy identifier separately in code, so this sentence should not tell clients to treat type as the unique code.
Suggested fix
-As per the RFC9457 standard, the `type` field now includes the unique code for the error.
+As per RFC 9457, the `type` field identifies the problem type URI; the legacy numeric identifier remains in the deprecated `code` field.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| As per the RFC9457 standard, the `type` field now includes the unique code for the error. | |
| You will notice that the response still contains a `code` of "111" (though as a top level property not embedded in the "error" scope). | |
| The `title` field is a human readable summary of the general issue and the `detail` field may provide additional information for the specific request. | |
| The URIs provided through `type` _will_ be resolvable in the future, providing a page with more information. | |
| !!! warning | |
| The`code` field is only included to support the migration of clients, but should be considered **deprecated**. Prefer to use the `type` field to identify the error. | |
| As per RFC 9457, the `type` field identifies the problem type URI; the legacy numeric identifier remains in the deprecated `code` field. | |
| You will notice that the response still contains a `code` of "111" (though as a top level property not embedded in the "error" scope). | |
| The `title` field is a human readable summary of the general issue and the `detail` field may provide additional information for the specific request. | |
| The URIs provided through `type` _will_ be resolvable in the future, providing a page with more information. | |
| !!! warning | |
| The`code` field is only included to support the migration of clients, but should be considered **deprecated**. Prefer to use the `type` field to identify the error. |
🧰 Tools
🪛 LanguageTool
[grammar] ~40-~40: Use a hyphen to join words.
Context: ...tains a code of "111" (though as a top level property not embedded in the "erro...
(QB_NEW_EN_HYPHEN)
[grammar] ~42-~42: Use a hyphen to join words.
Context: ...r" scope). The title field is a human readable summary of the general issue an...
(QB_NEW_EN_HYPHEN)
[style] ~43-~43: Consider using a more formal alternative.
Context: ...le in the future, providing a page with more information. !!! warning Thecode field is o...
(MORE_INFO)
🪛 markdownlint-cli2 (0.22.1)
[warning] 47-47: Code block style
Expected: fenced; Actual: indented
(MD046, code-block-style)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/migration.md` around lines 39 - 47, Clarify the RFC 9457 field contract
in the migration docs: the `type` field should be described as the problem URI,
not the legacy numeric error code. Update the wording in this section to state
that `src/core/errors.py` still emits the numeric identifier separately in
`code`, and that clients should use `type` to identify the problem while
treating `code` as deprecated migration support.
Comment on lines
+1
to
+4
| The REST API is currently under development. | ||
| It's does not yet have feature parity with the PHP-based REST API. | ||
| We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026. | ||
| The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services. |
Contributor
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win
Tighten the opening paragraph copy.
There are two obvious grammar errors here: It's does not yet and will be depend. Please clean these up before publishing.
Suggested fix
-The REST API is currently under development.
-It's does not yet have feature parity with the PHP-based REST API.
+The REST API is currently under development.
+It does not yet have feature parity with the PHP-based REST API.
...
-The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services.
+The sunset date of the PHP-based REST API will depend on the progress of this reimplementation and that of some other required server services.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| The REST API is currently under development. | |
| It's does not yet have feature parity with the PHP-based REST API. | |
| We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026. | |
| The sunset date of the PHP-based REST API will be depend on the progress of this reimplementation and that of some other required server services. | |
| The REST API is currently under development. | |
| It does not yet have feature parity with the PHP-based REST API. | |
| We are currently working on Phase 1 and Phase 2 in parallel, and to deploy to production before the end of 2026. | |
| The sunset date of the PHP-based REST API will depend on the progress of this reimplementation and that of some other required server services. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/roadmap.md` around lines 1 - 4, Tighten the opening paragraph in the
roadmap copy by fixing the two grammar issues: change the phrasing in the
introductory text so “It’s does not yet” becomes a correct sentence, and update
the sentence about the PHP-based REST API sunset so “will be depend” is
corrected. Keep the same meaning while cleaning the wording in the paragraph
content.
Comment on lines
18
to
40
| nav: | ||
| - OpenML Server: | ||
| - index.md | ||
| - Getting Started: installation.md | ||
| - Changes: migration.md | ||
| - Database: | ||
| - database/index.md | ||
| - openml: database/openml.md | ||
| - openml_expdb: database/openml_expdb.md | ||
| - Migration Guide: migration.md | ||
| - Roadmap: roadmap.md | ||
| - Deployment: | ||
| - installation.md | ||
| - Development: | ||
| - Project Overview: development/project_overview.md | ||
| - Development: | ||
| - "Getting Started": development/setup.md | ||
| - "Writing Code": development/code.md | ||
| - "Writing Tests": development/tests.md | ||
| - "CI/CD": development/CI_CD.md | ||
| - Documentation: development/documentation.md | ||
| - Database: | ||
| - development/database/index.md | ||
| - openml: development/database/openml.md | ||
| - openml_expdb: development/database/openml_expdb.md | ||
| - Contributing: | ||
| - contributing/index.md | ||
| - Setup: contributing/setup.md | ||
| - Tests: contributing/tests.md | ||
| - Documentation: contributing/documentation.md | ||
| - Project Overview: contributing/project_overview.md | ||
| - Code of Conduct: contributing/code_of_conduct.md | ||
|
|
Contributor
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify all nav-referenced markdown files exist
files=(
"docs/index.md"
"docs/migration.md"
"docs/roadmap.md"
"docs/installation.md"
"docs/development/project_overview.md"
"docs/development/setup.md"
"docs/development/code.md"
"docs/development/tests.md"
"docs/development/CI_CD.md"
"docs/development/documentation.md"
"docs/development/database/index.md"
"docs/development/database/openml.md"
"docs/development/database/openml_expdb.md"
"docs/contributing/index.md"
"docs/contributing/code_of_conduct.md"
)
missing=0
for f in "${files[@]}"; do
if [ -f "$f" ]; then
echo "✓ $f"
else
echo "✗ $f (MISSING)"
missing=$((missing + 1))
fi
done
if [ "$missing" -gt 0 ]; then
echo ""
echo "Total missing files: $missing"
fiRepository: openml/server-api
Length of output: 605
Rename the nested Development nav item
The nested Development entry duplicates the top-level label, so breadcrumbs like Development > Development > Getting Started read redundantly. Rename the inner section to something like Guides or Workflow.
♻️ Suggested rename
- Project Overview: development/project_overview.md
- - Development:
+ - Guides:
- "Getting Started": development/setup.md
- "Writing Code": development/code.md
- "Writing Tests": development/tests.md
- "CI/CD": development/CI_CD.md
- Documentation: development/documentation.md📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
Suggested change
| nav: | |
| - OpenML Server: | |
| - index.md | |
| - Getting Started: installation.md | |
| - Changes: migration.md | |
| - Database: | |
| - database/index.md | |
| - openml: database/openml.md | |
| - openml_expdb: database/openml_expdb.md | |
| - Migration Guide: migration.md | |
| - Roadmap: roadmap.md | |
| - Deployment: | |
| - installation.md | |
| - Development: | |
| - Project Overview: development/project_overview.md | |
| - Development: | |
| - "Getting Started": development/setup.md | |
| - "Writing Code": development/code.md | |
| - "Writing Tests": development/tests.md | |
| - "CI/CD": development/CI_CD.md | |
| - Documentation: development/documentation.md | |
| - Database: | |
| - development/database/index.md | |
| - openml: development/database/openml.md | |
| - openml_expdb: development/database/openml_expdb.md | |
| - Contributing: | |
| - contributing/index.md | |
| - Setup: contributing/setup.md | |
| - Tests: contributing/tests.md | |
| - Documentation: contributing/documentation.md | |
| - Project Overview: contributing/project_overview.md | |
| - Code of Conduct: contributing/code_of_conduct.md | |
| nav: | |
| - OpenML Server: | |
| - index.md | |
| - Migration Guide: migration.md | |
| - Roadmap: roadmap.md | |
| - Deployment: | |
| - installation.md | |
| - Development: | |
| - Project Overview: development/project_overview.md | |
| - Guides: | |
| - "Getting Started": development/setup.md | |
| - "Writing Code": development/code.md | |
| - "Writing Tests": development/tests.md | |
| - "CI/CD": development/CI_CD.md | |
| - Documentation: development/documentation.md | |
| - Database: | |
| - development/database/index.md | |
| - openml: development/database/openml.md | |
| - openml_expdb: development/database/openml_expdb.md | |
| - Contributing: | |
| - contributing/index.md | |
| - Code of Conduct: contributing/code_of_conduct.md |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@mkdocs.yml` around lines 18 - 40, The nested Development navigation label is
duplicated, causing redundant breadcrumbs; update the inner Development section
in mkdocs nav to a distinct name like Guides or Workflow. Adjust the nav entry
that groups Getting Started, Writing Code, Writing Tests, CI/CD, and
Documentation so the top-level Development item remains unchanged while the
nested group uses a unique label.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Switch to Zensical from mkdocs because mkdocs 1.x is not maintained and mkdocs 2.0 will not be compatible with mkdocs material.
Also expanded the documentation pages significantly.