Introduce Cmdlet Maturity Model for FabricTools #183
Description
Background
FabricTools currently contains a large and growing number of cmdlets (~300), developed over time by multiple contributors. These cmdlets vary significantly in terms of quality, testing coverage, stability, and production readiness.
At the moment, there is no explicit way to communicate:
- how mature a given cmdlet is,
- what guarantees (if any) it provides,
- or what is required to improve its quality level.
This makes it harder for:
- users to know which cmdlets are safe to use in production,
- contributors to understand expectations,
- maintainers to prioritize improvements.
Proposal
Introduce a formal Cmdlet Maturity Model that categorizes each cmdlet into a clearly defined maturity level, based on objective and verifiable criteria.
The proposed maturity levels are:
| Level | Name |
|---|---|
| 0 | Experimental |
| 1 | Prototype |
| 2 | Standardized |
| 3 | Unit Tested |
| 4 | Integration Tested |
| 5 | Production Ready |
Each level defines specific characteristics such as:
- adherence to PowerShell and FabricTools coding standards,
- presence and quality of comment-based help,
- parameter validation and error handling,
- unit and integration test coverage,
- CI enforcement,
- stability and backward compatibility guarantees.
Goals
- Provide clear expectations for cmdlet quality and stability
- Make cmdlet maturity transparent to users
- Give contributors a clear path for improving cmdlets
- Improve overall consistency and maintainability of the module
- Enable future CI checks and quality gates
Scope (Initial)
- Define and document the maturity model in the repository
- Agree on objective criteria for each maturity level
- Decide how maturity is represented (e.g. metadata, comments, docs)
- Mark existing cmdlets with an initial maturity level (best-effort)
Out of Scope (for this issue)
- Refactoring all existing cmdlets to higher maturity levels
- Enforcing maturity levels via CI (can be a follow-up issue)
- Removing or deprecating cmdlets
Acceptance Criteria
- Maturity levels and their characteristics are documented in the repo
- A single source of truth exists (e.g.
docs/maturity-model.md) - Contributors understand how to move a cmdlet from one level to another
- The model is agreed upon by maintainers
Follow-up Ideas (Optional)
- CI validation of claimed maturity level
- Filters or documentation views by maturity level
- Contributor checklist per maturity level
- “Production Ready” quality badge for cmdlets