THE RESOURCE REVIEW
A curated selection of primary resources, assessed for authority, practical depth, and relevance—not a traffic or search-engine ranking.
Choose by your current task. “Best fit” reflects our editorial assessment of the linked resource. Product capabilities and commercial terms can change; check the source before adopting a tool. Reviewed 6 October 2026.
Broad community guidance spanning writing, accessibility, tools, and documentation operations.
A reference collection rather than a single linear course.
Give readers a clear learning route and connect writing practice to maintenance.
Structured technical-writing lessons and a detailed developer documentation style guide.
Its examples and conventions primarily serve technical practitioners.
Combine short explanations with editing exercises and an explicit house style.
Practical terminology and voice guidance for technology communication.
Product-specific conventions need judgment outside the Microsoft ecosystem.
Use consistent interface names and direct, helpful instructions.
An extensive API documentation course alongside practitioner discussion of tools, careers, and AI.
The broad blog archive needs a focused reading path.
Teach the full API journey, from a first request to reference and testing.
Distinguishes tutorials, how-to guides, reference, and explanation by user need.
A framework does not supply your product facts or publishing workflow.
Label each guide’s purpose and keep reference details easy to locate.
A concise introduction to four documentation purposes with linked explanations.
Conceptually overlaps with Diátaxis; it is not independent validation of the framework.
Show how one product feature can require several different document types.
Concrete authoring guidance, page structures, examples, and contribution policies.
Its content model is tailored to web technology documentation.
Give articles repeatable structures and identify technical facts that need verification.
Explains Git, reviews, and automated publishing as a collaborative documentation workflow.
Teams still need to choose tools and establish ownership.
Teach a small edit–review–publish cycle before adding advanced automation.
Publishes its content model, style guide, and contribution practices.
GitHub-specific structures should be adapted rather than copied wholesale.
Document contribution rules and supply reviewer checklists.
Makes documentation changes, technical-writer involvement, testing, and review visible.
Its contribution process reflects a large product organization.
Assign an owner and review path to every important guide.
Rich cross-references, extensibility, multiple output formats, and code-reference support.
More configuration and markup concepts than a minimal writing workflow.
Consider it when code references and structured cross-links are central.
A focused documentation generator built around Markdown and YAML configuration.
Advanced needs may depend on themes, plugins, and their maintenance.
Use a small Markdown project to teach publishing fundamentals.
A documentation-site framework with a dedicated getting-started and configuration guide.
A JavaScript site introduces a build toolchain that writers must maintain or delegate.
Evaluate it when documentation needs a more customized web experience.
Git-based builds, versioned documentation, previews, and publishing guidance.
Hosting automation cannot verify the accuracy of the prose it publishes.
Keep review previews and documentation versions tied to releases.
Configurable prose linting helps multiple authors apply a shared style.
It is not a general grammar checker or a test of technical truth.
Automate repeatable terminology checks while retaining human review.
Guidance for AsciiDoc authoring and conversion to several publishing formats.
Authors must learn a richer markup syntax and the chosen conversion workflow.
Evaluate structured plain-text authoring when manuals need reusable conventions.
Explains OpenAPI descriptions and the tools that turn them into usable API documentation.
The reviewed guide targets OpenAPI 3.0; match guidance to your actual specification version.
Pair a machine-readable contract with a tested task-based quickstart.
Documentation for OpenAPI linting, validation, transformation, and rendered reference.
Separate the open-source tools from commercial platform capabilities when evaluating a workflow.
Validate the API description before publishing generated reference pages.
Actionable writing guidance for headings, links, alternatives, instructions, and multimedia.
A writing checklist alone does not establish whole-site accessibility conformance.
Review semantic structure, meaningful links, and alternatives alongside visual presentation.
A real API reference that identifies base URL, libraries, sandbox behavior, and version context.
A product-specific example, not a universal API or writing standard.
Make environment, authentication, and version assumptions visible to readers.