You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/AGENTS.md
+32-6Lines changed: 32 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,16 +1,21 @@
1
1
# Orleans documentation guidance
2
2
3
-
These rules apply to documentation and samples under `docs/`.
3
+
These rules apply recursively to documentation, snippets, and samples under
4
+
`docs/`. The repository-level guidance also applies.
4
5
5
6
## Code examples
6
7
7
8
- Put reusable examples in a `snippets` project near the page that consumes them.
8
9
- Include snippets with `:::code` and named snippet regions instead of duplicating fenced code in Markdown.
9
-
- Make examples self-contained: declare builders, configuration, services, and values used by the displayed region.
10
+
- Keep snippets minimal, complete, and current. Make examples self-contained:
11
+
declare builders, configuration, services, and values used by the displayed
12
+
region.
10
13
- Compile every affected snippet project. Don't publish pseudo-code as if it were a copyable example.
11
14
- Maintained documentation and snippet projects target `net10.0`.
12
15
- Every `Microsoft.Orleans.*` package reference must use the approved version `10.2.2`. Keep the Orleans package family aligned and centralize versions where the project structure supports it.
13
-
- Use an older Orleans package only for a narrow migration example whose purpose requires that version, and document the reason next to the exception.
16
+
- Use an older Orleans package only for a narrow migration example whose purpose
17
+
requires that version. Keep it under `migration` and document the reason in
18
+
`OrleansDocumentationVersionException` in that project.
14
19
- Keep direct dependency versions at or above the minimums required by the selected Orleans packages.
15
20
- Don't demonstrate an unreleased API using an older package that doesn't contain it. Link to its API reference until a compilable source- or package-based example is available.
16
21
@@ -29,7 +34,9 @@ These rules apply to documentation and samples under `docs/`.
29
34
- Link public .NET symbols to generated API documentation using DocFX xref syntax instead of formatting the symbol only as inline code.
30
35
- Use `<xref:Namespace.Type>` for types and `<xref:Namespace.Type.Member*>` for members or overload groups.
31
36
- Add `?displayProperty=nameWithType` when the fully qualified display name improves clarity.
32
-
- Use inline code for literals, configuration keys, provider names, and syntax that isn't a linkable public symbol.
37
+
- Use inline code for literals, configuration values, CLI commands, filenames,
38
+
provider names, and syntax that isn't a linkable public symbol. Avoid
39
+
repeatedly linking a symbol when an earlier contextual link is clearer.
33
40
- Confirm the xref target exists in the generated API surface before publishing.
34
41
35
42
Examples:
@@ -44,13 +51,32 @@ Configure it with <xref:Orleans.Hosting.AzureTableSiloBuilderExtensions.AddAzure
44
51
45
52
- Keep ordinary conceptual and how-to documentation timeless. Name Orleans releases only in migration or upgrade guidance where the release boundary matters.
0 commit comments