Wish Template - Propose a new feature or tool, either as an addition to an existing platform or as a standalone project.

_wish.md

Wish Name Of Feature/Tool

Status

Type

• Enhancement for existing platform
• New standalone tool

Enhancement for existing platform

Enhance an existing platform:

• Wishlist proposal: wish-propose-feature
• Link to related RFC: (if any)
• Why submit here instead:
  • Cross-platform feature
  • Platform doesn't accept feature requests
  • Feature too large for regular channels
  • Other

New standalone tool

Build a new repository based on this wish proposal:

• Wishlist proposal: wish-propose-tool
• Repository Tags:
  • wish-implementation
  • wish-(feature/tool)-name

Related project(s)

Repository	Status	Developer
Project	Alpha	@developer
-	-	-

Ownership

• Original Author: @username
• Current Maintainer(s): @username
• Status: Actively Maintained | Looking for Maintainer | Abandoned
• Transfer Requests: Open issues with tag maintainer-request in linked wishlist

Funding

Type

• 🏆 Grant Funded
• 💰 Bounty Available
• 💎 Sponsored
• 🎁 Accepting Donations
• 🌱 Looking for Funding
• ⭐ No Funding Needed
• ⏳ To Be Decided

Details

Available via Provider - Grant #001

licence

<!-- add your licence -->

wish-propose-feature.md

Propose Feature

Metadata

• Feature Name: (unique identifier, title of wish e.g., 0001_awesome_feature)
• Author(s): [@username]
• Start Date: YYYY-MM-DD
• Target repository: (target platform repository)
• Related Components: (if applicable)

Summary

One paragraph explanation of the feature. Keep it clear and concise, focusing on what the feature does rather than how it does it.

Motivation

Problem Statement

• Current limitations or issues
• User impact
• Business/Technical requirements

Use Cases

• Primary use case
• Secondary use cases
• User scenarios

Expected Outcome

• What success looks like
• Measurable objectives
• User benefits

Detailed Design

Overview

High-level description of how the feature works.

Technical Specification

• API design
• Data structures
• Algorithms
• Dependencies

Implementation Details

// Example code or pseudocode

How we teach this

• What names and terminology work best for these concepts and why? How is this idea best presented?
• Would the acceptance of this proposal mean the <platform_name> documentation must be re-organized or altered?
• How should this feature be taught to existing <platform_name> users?

Drawbacks

Why should we not do this?

• Implementation costs
• Maintenance overhead
• Breaking changes
• Migration challenges

Alternatives

What other designs have been considered? What is the impact of not doing this?

This section could also include prior art, that is, how other frameworks in the same domain have solved this problem.

• Other approaches considered
• Trade-offs
• Why this solution is preferred

Unresolved Questions

Optional, but suggested for first drafts:

• Open technical questions
• Implementation uncertainties
• Future considerations

wish-propose-tool.md

Propose Tool

Metadata

• Tool Name: (title of wish e.g., some_awesome_tool)
• Author(s): [@username]
• Start Date: YYYY-MM-DD
• Suggested repository name: (name-of-repository or title-of-wish)

Summary

One paragraph explanation of the tool. Focus on its purpose and primary value proposition.

Motivation

Problem Statement

• Market gap or need
• Current solutions' limitations
• Target audience

Use Cases

• Primary use case
• Secondary use cases
• User personas

Goals

• Primary objectives
• Success metrics
• Value proposition

Technical Architecture

System Overview

graph TD
    A[Component A] --> B[Component B]
    B --> C[Component C]

Loading

Core Components

• Component descriptions
• Interactions
• Dependencies

Technical Stack

• Languages
• Frameworks
• Services
• Infrastructure

Implementation Plan

Phase 1: MVP

• Core features
• Basic functionality
• Initial release

Phase 2: Enhancement

• Additional features
• Scalability improvements
• Integration capabilities

Phase 3: Production

• Production readiness
• Performance optimization
• Security hardening

Project Structure

/
├── src/
├── tests/
├── docs/
├── examples/
└── scripts/

Development Requirements

• Development environment
• Build tools
• Testing framework
• CI/CD pipeline

Testing Strategy

• Unit testing approach
• Integration testing
• Performance testing
• Security testing

Drawbacks

• Development challenges
• Resource requirements
• Maintenance considerations
• Potential limitations

Alternatives

• Existing solutions
• Similar solutions
• Build vs. buy analysis
• Integration alternatives

Deployment Strategy

• Hosting requirements
• Distribution method
• Update mechanism
• Monitoring strategy

Documentation

• README structure
• API documentation
• User guides
• Contributing guidelines

Unresolved Questions

Optional, but suggested for first drafts:

• Technical uncertainties
• Resource allocation
• Timeline estimates
• Risk factors