Some checks are pending
Go Benchmark / Performance Regression Check (push) Waiting to run
Cerberus Integration / Cerberus Security Stack Integration (push) Waiting to run
Upload Coverage to Codecov / Backend Codecov Upload (push) Waiting to run
Upload Coverage to Codecov / Frontend Codecov Upload (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (go) (push) Waiting to run
CodeQL - Analyze / CodeQL analysis (javascript-typescript) (push) Waiting to run
CrowdSec Integration / CrowdSec Bouncer Integration (push) Waiting to run
Docker Build, Publish & Test / build-and-push (push) Waiting to run
Docker Build, Publish & Test / Security Scan PR Image (push) Blocked by required conditions
Quality Checks / Auth Route Protection Contract (push) Waiting to run
Quality Checks / Codecov Trigger/Comment Parity Guard (push) Waiting to run
Quality Checks / Backend (Go) (push) Waiting to run
Quality Checks / Frontend (React) (push) Waiting to run
Rate Limit integration / Rate Limiting Integration (push) Waiting to run
Security Scan (PR) / Trivy Binary Scan (push) Waiting to run
Supply Chain Verification (PR) / Verify Supply Chain (push) Waiting to run
WAF integration / Coraza WAF Integration (push) Waiting to run
31 lines
1.7 KiB
Markdown
Executable File
31 lines
1.7 KiB
Markdown
Executable File
---
|
||
description: "Guidance for writing and formatting the `docs/features.md` file."
|
||
applyTo: "docs/features.md"
|
||
---
|
||
|
||
# Features Documentation Guidelines
|
||
|
||
When creating or updating the `docs/features.md` file, please adhere to the following guidelines to ensure clarity and consistency:
|
||
|
||
## Structure
|
||
|
||
- This document should provide a short, to the point overview of each feature. It is used for marketing of the project. A quick read of what the feature is and why it matters. It is the "elevator pitch" for each feature.
|
||
- Each feature should have its own section with a clear heading.
|
||
- Use bullet points or numbered lists to break down complex information.
|
||
- Include relevant links to other documentation or resources for further reading.
|
||
- Use consistent formatting for headings, subheadings, and text styles throughout the document.
|
||
- Avoid overly technical jargon; the document should be accessible to a broad audience. Keep novice users in mind.
|
||
- This is not the place for deep technical details or implementation specifics. Keep those for individual feature docs.
|
||
|
||
## Content
|
||
- Start with a brief summary of the feature.
|
||
- Explain the purpose and benefits of the feature.
|
||
- Keep descriptions concise and focused.
|
||
- Ensure accuracy and up-to-date information.
|
||
|
||
## Review
|
||
- Changes to `docs/features.md` should be reviewed by at least one other contributor before merging.
|
||
- Review for correctness, clarity, and consistency with the guidelines in this file.
|
||
- Confirm that each feature description reflects the current behavior and positioning of the project.
|
||
- Ensure the tone remains high-level and marketing‑oriented, avoiding deep technical implementation details.
|