|
| 1 | +<!-- List of authors who contributed to this decision. Include full names and roles if applicable. --> |
| 2 | +authors: |
| 3 | +- Martin Stühmer |
| 4 | + |
| 5 | +<!-- |
| 6 | +The patterns this decision applies to. Each entry is a glob pattern that matches files affected by this decision. |
| 7 | +--> |
| 8 | +applyTo: |
| 9 | +- "**/README.md" |
| 10 | +- "src/**/README.md" |
| 11 | + |
| 12 | +<!-- The date this ADR was initially created in YYYY-MM-DD format. --> |
| 13 | +created: 2026-01-09 |
| 14 | + |
| 15 | +<!-- |
| 16 | +The most recent date this ADR was updated in YYYY-MM-DD format. |
| 17 | +IMPORTANT: Update this field whenever the decision is modified. |
| 18 | +--> |
| 19 | +lastModified: 2026-01-09 |
| 20 | + |
| 21 | +<!-- |
| 22 | +The current state of this ADR. If superseded, include references to the superseding ADR. |
| 23 | +Valid values: proposed, accepted, deprecated, superseded |
| 24 | +--> |
| 25 | +state: accepted |
| 26 | + |
| 27 | +<!-- |
| 28 | +A compact AI LLM compatible definition of this decision. |
| 29 | +This should be a precise, structured description that AI systems can easily parse and understand. |
| 30 | +Include the core decision, key rationale, and primary impact in 1-2 concise sentences. |
| 31 | +--> |
| 32 | +instructions: | |
| 33 | + Use templates/readme-project.md as the mandatory template for all NuGet package README files to ensure consistent documentation structure, comprehensive content, and absolute URLs for cross-platform compatibility. |
| 34 | + All project READMEs MUST include features, installation instructions, usage examples, requirements, and support information following the template structure. |
| 35 | + MUST preserve all automated content markers (e.g., <!-- packages:start -->) under all circumstances when updating existing README files. |
| 36 | +--- |
| 37 | +<!-- REQUIRED: Filename MUST follow the format: YYYY-MM-DD-Title (replace all spaces with hyphens) --> |
| 38 | +# NuGet Package README Template |
| 39 | + |
| 40 | +Establish a standardized template for NuGet package README files to ensure consistent, comprehensive, and professional documentation across all packages in the project ecosystem. |
| 41 | + |
| 42 | +## Context |
| 43 | + |
| 44 | +NuGet packages require clear and comprehensive documentation to help users understand the package functionality, installation process, and usage patterns. Without a standardized template, several issues arise: |
| 45 | + |
| 46 | +1. **Inconsistent Documentation**: Different packages have varying documentation quality and structure, making it difficult for users to find information consistently across packages |
| 47 | +2. **Missing Critical Information**: Ad-hoc README files often omit essential sections such as requirements, configuration, or troubleshooting guidance |
| 48 | +3. **URL Management**: Relative URLs break when viewed on NuGet.org, GitHub, or other platforms that display README content in different contexts |
| 49 | +4. **Maintenance Overhead**: Without a template, maintaining documentation standards requires manual review and correction of each README file |
| 50 | +5. **Onboarding Complexity**: New contributors and package authors must determine documentation structure and content independently, leading to variations and potential gaps |
| 51 | +6. **Professional Appearance**: Inconsistent documentation reduces the perceived quality and professionalism of packages |
| 52 | +7. **Discoverability**: Well-structured documentation with standard sections improves package discoverability and user adoption |
| 53 | + |
| 54 | +The need for a standardized approach became apparent as the project ecosystem expanded with multiple NuGet packages requiring consistent documentation standards. |
| 55 | + |
| 56 | +## Decision |
| 57 | + |
| 58 | +All NuGet package README files MUST use the standardized template located at `templates/readme-project.md` as the foundation for project documentation. |
| 59 | + |
| 60 | +The template provides a comprehensive structure including: |
| 61 | + |
| 62 | +* **Package Metadata**: Badges for version, downloads, and license status |
| 63 | +* **Project Description**: Clear explanation of package purpose and functionality |
| 64 | +* **Features**: Bullet-point list of key capabilities |
| 65 | +* **Installation Instructions**: Multiple installation methods (NuGet Package Manager, .NET CLI, PackageReference) |
| 66 | +* **Quick Start**: Minimal working example for immediate usage |
| 67 | +* **Usage Examples**: Detailed examples covering basic and advanced scenarios |
| 68 | +* **Configuration**: Setup and configuration guidance |
| 69 | +* **Requirements**: Minimum framework versions and dependencies |
| 70 | +* **Related Packages**: Cross-references to related packages in the ecosystem |
| 71 | +* **Documentation Links**: References to comprehensive documentation |
| 72 | +* **Contributing Guidelines**: Links to contribution processes |
| 73 | +* **Support Channels**: GitHub Issues, Discussions, and documentation links |
| 74 | +* **License Information**: Clear license declaration and reference |
| 75 | + |
| 76 | +All URLs in package READMEs MUST be absolute URLs pointing to GitHub or NuGet.org to ensure compatibility across all platforms where the README may be displayed. |
| 77 | + |
| 78 | +The template includes comprehensive comments explaining each section's purpose and providing guidance for content creation. |
| 79 | + |
| 80 | +### Preservation of Automated Content Markers |
| 81 | + |
| 82 | +When updating existing README files, all automated content markers MUST be preserved under all circumstances. These markers are HTML comments that define sections managed by automated tools or processes. |
| 83 | + |
| 84 | +Common marker patterns include: |
| 85 | +* `<!-- packages:start -->` and `<!-- packages:end -->` - Automated package list sections |
| 86 | +* `<!-- section:start -->` and `<!-- section:end -->` - Generic automated sections |
| 87 | +* Any other `<!-- marker:start -->` and `<!-- marker:end -->` pairs |
| 88 | + |
| 89 | +These markers and their content MUST NOT be modified or removed during manual template updates. Automated tools rely on these markers to maintain dynamic content sections. |
| 90 | + |
| 91 | +## Consequences |
| 92 | + |
| 93 | +### Positive |
| 94 | + |
| 95 | +* **Consistency**: All package READMEs follow the same structure, making information easy to find |
| 96 | +* **Completeness**: Template ensures all critical sections are included and properly documented |
| 97 | +* **Professional Quality**: Standardized documentation improves the perceived quality and professionalism of all packages |
| 98 | +* **Reduced Maintenance**: Template updates automatically improve documentation guidance for all packages |
| 99 | +* **Cross-Platform Compatibility**: Absolute URLs ensure README content displays correctly on NuGet.org, GitHub, and other platforms |
| 100 | +* **Faster Onboarding**: New package authors have clear guidance for creating documentation |
| 101 | +* **Better Discoverability**: Consistent structure with badges and clear descriptions improves package discoverability |
| 102 | +* **User Experience**: Users benefit from predictable documentation structure across all packages |
| 103 | +* **Quality Assurance**: Template comments guide authors toward complete and accurate documentation |
| 104 | +* **Automated Content Protection**: Marker preservation ensures automated tooling continues to function correctly |
| 105 | + |
| 106 | +### Negative |
| 107 | + |
| 108 | +* **Initial Effort**: Existing packages require updates to conform to the new template structure |
| 109 | +* **Flexibility Constraints**: Specialized packages may need to deviate from the standard template structure |
| 110 | +* **Maintenance Obligation**: Template changes require updating existing package READMEs to maintain consistency |
| 111 | +* **Learning Curve**: Authors must familiarize themselves with the template structure and guidelines |
| 112 | +* **Marker Awareness**: Authors must be aware of automated content markers and avoid modifying them manually |
| 113 | + |
| 114 | +## Alternatives Considered |
| 115 | + |
| 116 | +### Manual Documentation Without Template |
| 117 | + |
| 118 | +Each package author creates README files independently without a standardized template. |
| 119 | + |
| 120 | +**Rejected because**: |
| 121 | +* Leads to inconsistent documentation quality and structure |
| 122 | +* Critical information often omitted or poorly organized |
| 123 | +* Increases maintenance burden for ensuring documentation standards |
| 124 | +* Reduces professional appearance of package ecosystem |
| 125 | +* Makes it difficult for users to find information consistently |
| 126 | + |
| 127 | +### Minimal Template |
| 128 | + |
| 129 | +Provide a minimal template with only basic sections (title, description, installation). |
| 130 | + |
| 131 | +**Rejected because**: |
| 132 | +* Insufficient guidance for comprehensive documentation |
| 133 | +* Important sections like configuration, requirements, and support would be frequently omitted |
| 134 | +* Does not address cross-platform URL compatibility issues |
| 135 | +* Provides less value in standardizing documentation quality |
| 136 | + |
| 137 | +### Multiple Templates by Package Type |
| 138 | + |
| 139 | +Create different templates for different types of packages (libraries, tools, extensions). |
| 140 | + |
| 141 | +**Rejected because**: |
| 142 | +* Adds complexity in choosing the correct template |
| 143 | +* Reduces consistency across the package ecosystem |
| 144 | +* Most sections are relevant to all package types |
| 145 | +* Authors can omit irrelevant sections from the standard template |
| 146 | + |
| 147 | +### External Documentation Generation Tools |
| 148 | + |
| 149 | +Use automated documentation generation tools (DocFX, Sandcastle) instead of manual README files. |
| 150 | + |
| 151 | +**Rejected because**: |
| 152 | +* NuGet.org displays README content prominently, requiring manually crafted content |
| 153 | +* Generated documentation is often too technical or detailed for quick package evaluation |
| 154 | +* Adds build complexity and tooling dependencies |
| 155 | +* Does not replace the need for user-friendly introductory content |
| 156 | + |
| 157 | +## Related Decisions |
| 158 | + |
| 159 | +* [English as Project Language](./2025-07-11-english-as-project-language.md) - All README content must be written in English following this decision |
| 160 | +* [Folder Structure and Naming Conventions](./2025-07-10-folder-structure-and-naming-conventions.md) - README files are placed at the root of each project directory following folder structure conventions |
0 commit comments