From 063391ba188bba674b41654164e565d312a93145 Mon Sep 17 00:00:00 2001 From: markscott-ms Date: Thu, 20 Nov 2025 22:26:53 +0000 Subject: [PATCH 1/2] feat(docs): Experimental Feature process --- .../Experimental_Feature_Feedback.md | 42 +++++++++++++++ experimental/README.md | 54 +++++++++++++++++++ 2 files changed, 96 insertions(+) create mode 100644 .github/ISSUE_TEMPLATE/Experimental_Feature_Feedback.md create mode 100644 experimental/README.md diff --git a/.github/ISSUE_TEMPLATE/Experimental_Feature_Feedback.md b/.github/ISSUE_TEMPLATE/Experimental_Feature_Feedback.md new file mode 100644 index 000000000..77b8a55ff --- /dev/null +++ b/.github/ISSUE_TEMPLATE/Experimental_Feature_Feedback.md @@ -0,0 +1,42 @@ +--- +name: 🚀 Experimental Feature Feedback +about: Gather feedback on an experimental feature added to the codebase +type: Feature +--- + +## Experiment Feature Feedback + +### Description of Feature: +...what capabilities does the new feature provide, and why is it needed? + +### Feedback Timeline: +- [ ] Publicised at Monthly Working Group Meeting on: [Date] +- [ ] Publicised at Weekly Office Hours on: [Date] +- [ ] Announced on Architecture as Code Mailing List on: [Date] +- [ ] Feedback Period Ends on: [Date] +- [ ] Accepted as non-experimental / Removed from codebase on: [Date] + +[Experimental Feature Process](https://github.com/finos/architecture-as-code/tree/main/experimental/) + +### Target Project: +...where in the codebase is this feature located (e.g., CLI, calm-hub, calm-widgets, shared utilities, etc.)? + +### User Stories: +...describe the feature from an end-user perspective, using "As a [role], I want [feature] so that [benefit]" format... + +### Feedback Emphasis: +...what specific areas of the feature are you seeking feedback on? (e.g., usability, performance, edge cases, etc.) + +### Current Limitations: +...describe why this functionality isn't possible with the current implementation... + +### Implementation Details: +...provide details of the implementation approach, including: +- Technical design considerations +- API changes (if applicable) +- Data model changes (if applicable) +- Dependencies on other components +- New dependencies introduced (if any) + +### Additional Context: +...add any other context, diagrams, mockups, or screenshots about the feature here... diff --git a/experimental/README.md b/experimental/README.md new file mode 100644 index 000000000..e054247bc --- /dev/null +++ b/experimental/README.md @@ -0,0 +1,54 @@ +# Experimental modules and features + +This folder contains experimental modules and features for CALM. + +**These modules and features are not considered stable, and may be subject to change or removal without notice**. + +**They are intended for testing and feedback purposes only, and should not be used in production environments.** + +**They may not be fully documented, and may have limited support.** + +Also note that some experimental feature may reside in other parts of the codebase, and not necessarily in this folder. + +## Feedback and acceptance process + +When experimental modules or features are added to the CALM codebase, they follow a defined process to be evaluated and +then transitioned to non-experimental status, or removed. + +This is to encourage: + +- active ownership and development of experimental features +- a defined and recordable feedback flow +- a clean-up of abandoned experimental features + +### When an experimental module or feature is added + +- an Issue will be created summarising the experimental addition, guiding users on its intended usage, and inviting feedback +- the Issue will specify a defined timeframe for the Feedback Period. +- the timeframe for feedback will be a period of 3 months, measured from the first Monthly Working Group Meeting it is + publicised at. + +The Issue should be publicised at: +- mandatorily, a Monthly Working Group Meeting (this is the starting point for measuring the Feedback Period), ideally the first such meeting after the experimental module or feature is merged. +- the next Weekly Office Hours meeting. +- the Architecture as Code mailing list. + +### During the Feedback Period + +Maintainers will review feedback and potentially act on it to refine the experimental module or feature. + +If the experimental module or feature is changed, a maintainer may call to extend the Feedback Period by a month, to +allow for additional feedback on the change. This call should be made at a Weekly Office Hours. + +A brief reminder of the experimental module and its feedback Issue should be included at any Monthly Working Group Meetings. + +### When the Feedback Period ends +When the feedback period expires a Maintainer vote should take place on the ongoing status of the experiment. + +The vote will be between: + +- promote the feature to non-experimental +- remove the feature from the codebase + +If it is being promoted, then ideally at least two maintainers must be selected for the module. They must be documented +in the repository root's [README.md](../README.md). From e9709b695324d7bf5b8359fd627a3969a816bf03 Mon Sep 17 00:00:00 2001 From: markscott-ms Date: Fri, 21 Nov 2025 10:28:41 +0000 Subject: [PATCH 2/2] feat(docs): revision to Experimental Feature process --- experimental/README.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/experimental/README.md b/experimental/README.md index e054247bc..5204dde85 100644 --- a/experimental/README.md +++ b/experimental/README.md @@ -2,13 +2,18 @@ This folder contains experimental modules and features for CALM. -**These modules and features are not considered stable, and may be subject to change or removal without notice**. +These modules and features: -**They are intended for testing and feedback purposes only, and should not be used in production environments.** +- Are not considered stable +- Are subject to change or removal without notice +- Intended for testing and feedback purposes only +- Should not be used in production environments. +- May not be fully documented +- May have limited support. -**They may not be fully documented, and may have limited support.** - -Also note that some experimental feature may reside in other parts of the codebase, and not necessarily in this folder. +Also note that some experimental features may reside in other parts of the codebase, and not necessarily in this folder. +This should only be the case for legacy experimental features that have not yet been removed/promoted, or where +separation of code is not practical. ## Feedback and acceptance process @@ -29,7 +34,7 @@ This is to encourage: publicised at. The Issue should be publicised at: -- mandatorily, a Monthly Working Group Meeting (this is the starting point for measuring the Feedback Period), ideally the first such meeting after the experimental module or feature is merged. +- a Monthly Working Group Meeting (this is the starting point for measuring the Feedback Period), ideally the first such meeting after the experimental module or feature is merged. - the next Weekly Office Hours meeting. - the Architecture as Code mailing list.