Moscle.dev

---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC: [Your Topic Title]

## Summary

A short, concise description of the feature or change proposed. This should be used to provide a high-level understanding of the proposal.

## Motivation

Explain the context and why you're making this proposal. What is the problem that needs solving? What use cases does it support? What is the expected outcome?

## Proposal Sketch / Detailed Design

For early-stage RFCs, provide at least a sketch of how to address the problem to help center the discussion on a concrete starting point. 

For more detailed RFCs, this section should contain enough information for others to understand and evaluate the proposal. It should cover the key points and design considerations, including a discussion of the architecture, an explanation of design details, and a reasoning behind your choices.

### Components Diagram

Provide a components diagram if possible.

### Sequence Diagram

Provide a sequence diagram if possible.

### Class Diagram

Provide a class diagram if it adds value and understanding to the proposal.

### OpenAPI Spec

Include an OpenAPI specification if the proposal involves an API.

## Rationale and Alternatives

Discuss the reasons for choosing the proposed design along with the trade-offs it involves. Moreover, describe the alternatives that have been considered and why they were discarded.

## Open Questions

Discuss aspects of the design which are still unresolved or require further discussion. It can be divided into two sections, questions that you hope to answer before finalizing the RFC and questions that would be resolved during the implementation phase.

## Drawbacks

What are the potential downsides of this proposal? What are the implications for users or existing systems?

## Adoption Strategy

If the proposal gets accepted, describe the path for adoption in your current system. What is the integration strategy? 

## Action Plans

List the key actions that need to be completed once the RFC is approved. Also include dates for discussions, reviews, and approvals if possible.

- [ ] Design discussion at YYYY-MM-DD
- [ ] RFC review at YYYY-MM-DD
- [ ] RFC approval at YYYY-MM-DD

---
name: RFC
about: Suggest an idea for this project
title: "[RFC]"
labels: enhancement
assignees: ''
---
# RFC Title

## Summary

Provide a brief single-paragraph explanation of the change.

## Motivation

Describe the motivation behind this RFC. What is the current state, and why is this change beneficial? What use cases does it support? What is the expected outcome?

## Proposal Sketch

At this stage, the proposal does not need to be fully formed. A sketch is enough to center the discussion. Detail the proposed solution at a high level. If any new concepts or terms are introduced, define them here.

## Open Questions

What parts of the design are still unclear or need resolving? What do you hope to resolve through discussion with the community before progressing this RFC to a full proposal?

## Trade-offs

What are the potential trade-offs or impacts of this proposal? How does it affect other areas of the system, if any?

## Unresolved Questions

What parts of the proposal are TBD (to be decided)?