Feature Request Process for CONTRIBUTING.md

Feature Request Process

A structured feature request process prevents scope creep, ensures community input, and helps maintainers prioritize work effectively.

Feature Proposal Format

## Suggesting Features

### Before Submitting

- Search existing issues and discussions for similar proposals
- Consider whether this belongs in the core project or a plugin/extension

### Proposal Format

**Title:** Clear, specific title (not "Improve UX")

**Problem:** What problem does this solve?

**Proposed Solution:** How should it work?

**Alternatives Considered:** What other approaches did you consider?

**Additional Context:** Mockups, examples from other tools, etc.

Discussion Period

For significant features, require a discussion period:

Feature proposals remain open for discussion for at least 7 days before implementation begins. This gives the community time to provide input, suggest alternatives, and identify potential issues.

RFC Process (for Larger Projects)

For projects that need more formality:

1. Open a Discussion -- Describe the feature at a high level
2. Write an RFC -- If there is interest, create a detailed RFC document
3. Review Period -- 14 days for community and maintainer feedback
4. Decision -- Maintainers approve, request changes, or decline
5. Implementation -- Approved RFCs move to implementation

Prioritization

Be transparent about how features are prioritized:

• Impact -- How many users benefit?
• Effort -- How complex is the implementation?
• Alignment -- Does it fit the project's direction?
• Community support -- How many thumbs-up does it have?

Declining Features

Explain that not all features will be accepted, and that this is not personal: "We may decline feature requests that do not align with the project's goals. This does not mean the idea is bad -- it may be better suited as a separate plugin or project."