reference: find a better way to present flag descriptions and example sections
I maintainer di solito rispondono entro 1 giorno
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Documentazione
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- docker
- Ambito
- documentation
Direzione di ricerca
Non sono indicati file o test. Inizia esaminando l’issue correlata 16469 e le pagine di riferimento attuali di Docker, quindi confronta il modo in cui i progetti strutturano le descrizioni e gli esempi dei flag; il lavoro è completato quando viene concordato e documentato un approccio di presentazione coerente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
- relates to https://github.com/docker/docs/issues/16469
Our reference docs currently use "descriptive" titles for flag descriptions. The idea behind that was to make these sections more discoverable, so that users that search for a specific "task" / "feature" would discover the flag they need to use for that.
For example;
Set the pull policy (--pull)
Using "Set the pull policy" allows the user to find the --pull flag, either from the right-hand TOC, or using search (within the docs, or through Google), and we also link to that section from the "options" table at the top of the page;
So, the current approach allows for two separate navigation entries into the content. However this approach also makes the right-hand navigation a bit unwieldy; the titles are long, and trying to find the right section for a specific flag from the right-hand TOC (not the table) is "messy".
We can probably improve some of that, but we need to brainstorm a bit on the right approach, and make sure that all projects that have pages in the reference section use the same approach.
A. Keep as-is, but add additional entries to the right-hand TOC
This could be a short-term solution; we keep the current headings, but repeat the links from the "options" table in the right-hand TOC. This means that (some) sections will appear twice in the TOC;
- once using
--flagnameas title (e.g.--pull) - once using the heading title (
Set the pull policy (--pull))
This approach
- 👍 makes the
--flagnameseasier to discover in the right-hand navigation - 👍 example titles continue to be listed in the navigation to help discoverability
- 👎 possibly confusing (two links to the same section)
B. Use --flagname for the headings, and put the examples as separate headings inside that
This approach would "split" the flagname and examples. Both are linkable;
--workdir, -w
Set the working directory inside the container.
Set a custom working directory for a container
Description of this example, mention
WORKDIRetc etc$ docker container run --workdir=/foo .....
- 👍 makes the
--flagnameseasier to discover in the right-hand navigation - 👎 / ❓ if we show both the
--flagnameand the "Set a custom working directory for a container" in the TOC, the TOC may still be cluttered
C. Separate examples and flag descriptions
Similar to A., but actually make the flag description and examples related to the flag separate sections (not nested).
- 👍 makes the
--flagnameseasier to discover in the right-hand navigation - 👍 example titles continue to be listed in the navigation to help discoverability
- 👎 navigating to the flag description only provides a (basic) description for the flag; sometimes an example is more useful to understand "why to use this flag"
- ☝️ we can still link from the flag description section to the corresponding example(s), but this requires additional maintenance, and may make the flag description section a bit "cluttered" (short description, followed by potentially multiple links to the examples).
D. Other options?
Perhaps there's other options?
- Lingua principale
- Markdown
- Stelle
- 4.7k
- Fork
- 8.5k
- Merge medio
- 2g 8h
- PR unite (30g)
- 129
Preparare l'ambiente
- Include un Dockerfile o un file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di docker/docs
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
[docs-scanner] Inconsistent information about what gets deleted when Docker Offload v1 session endsForse di nuovo libera Una pull request per questa issue è stata chiusa senza essere unita. Aperta
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
status/triage
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
I maintainer di solito rispondono entro 1 giorno
-
[docs-scanner] Confusing explanation of approval-required outcome vs permit in MCP policyForse già presa @dave123981 l’ha presa 2 giorni fa. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
[docs-scanner] Contradictory information about MCP approval fields in audit recordsForse già presa @dave123981 l’ha presa 2 giorni fa. Aperta
Difficoltà 1/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
🧩 Docs job fails type-checking `generate-plugin-docs.ts`Forse già presa @X-Guardian l’ha presa oggi. Apertadiscussion
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
Installation guide's prerequisites leave out ca-certificates, which a no-recommends system needsApertabot-found documentation priority: P3
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 94/100
madenvel/KalinkaPlayer#544 ·
-
14.3.x
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
githubnext/gh-aw-workshop#5522 ·
I maintainer di solito rispondono entro 1 giorno