feat(docs): Experimental Feature process

.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...

experimental/README.md

@@ -0,0 +1,59 @@
+# Experimental modules and features
+
+This folder contains experimental modules and features for CALM.
+
+These modules and features:
+
+- 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.
+
+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
+
+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:
+- 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).