How to Suggest a New Feature for Kaneo: A Complete Guide to GitHub Issues and Community Discussions

The recommended way to suggest a new feature for Kaneo is to first discuss your idea in the community Discord, then open a GitHub issue using the built-in feature request template.

Kaneo is an open-source project management platform that thrives on community contributions. Whether you have a small UI improvement in mind or a major architectural change, following the established workflow in the usekaneo/kaneo repository ensures your voice is heard and your proposal gets proper consideration.

Step 1: Discuss Your Idea in Discord (Optional but Recommended)

Before investing time in a formal proposal, gauge community interest and gather early feedback.

• Join the Kaneo Discord server: discord.gg/rU4tSyhXXU
• Start a conversation in the appropriate channel
• Benefits: avoid duplicate work, refine your concept, find potential collaborators

Discussions in Discord are informal but often lead to stronger, more focused GitHub issues.

Step 2: Open a GitHub Issue with the Feature Request Template

Navigate to the repository's Issues tab and select the Feature request template. This template lives at .github/ISSUE_TEMPLATE/feature_request.yml and enforces a structured format that maintainers can quickly parse.

Direct link: Feature request template

Step 3: Fill Out the Template Fields Completely

The template requires five key sections. Treat each as mandatory for maximum impact:

Field	Purpose	Tips
Title	Concise feature summary	Keep under 10 words; use action verbs
Description	Problem + proposed solution	Include specific use cases and user flows
Motivation	Value proposition	Explain who benefits and why it matters
Implementation notes	Technical direction	Optional but valued; show you've thought it through
Checklist	Contribution compliance	Confirms you've read guidelines and checked for duplicates

Example of a High-Quality Feature Request

Here's how a complete feature request looks when submitted:

**Title:** Add support for custom task colors

**Description**
Users would like to assign custom colors to tasks for quick visual categorisation. The current system only supports a limited set of preset colors.

**Motivation**
- Improves board ergonomics for power users.
- Enables better integration with personal workflows and accessibility tools.

**Implementation notes**
- Extend the `Task` database schema with a `color` column (string, nullable).
- Update the task editor UI to include a color picker component (Radix UI + Tailwind).
- Add validation in the API using Valibot: optional `color` string matching HEX format.

**Checklist**
- [x] I have read the [CONTRIBUTING guidelines](https://github.com/usekaneo/kaneo/blob/main/CONTRIBUTING.md).
- [x] This feature does not already exist.
- [x] I have provided enough detail for the maintainers to understand the request.

Step 4: Label and Submit Your Issue

The feature request template automatically applies the enhancement label. You may add additional labels like discussion if your proposal needs community input before implementation.

After submission, monitor the thread for:

• Questions from maintainers about scope or trade-offs
• Suggestions for alternative implementations
• Offers from other contributors to collaborate

Responsive engagement significantly increases the likelihood of your feature being adopted.

Step 5: Consider Contributing the Implementation

If you receive positive feedback and want to accelerate the process:

1. Fork the usekaneo/kaneo repository
2. Create a feature branch following the naming convention: feat/your-feature-name
3. Implement according to the design discussed in the issue
4. Submit a pull request linking back to your feature request

Reference CONTRIBUTING.md for detailed workflow requirements, including:

• Commit message conventions
• Code style requirements
• Test coverage expectations

Key Files for Feature Suggestions

• CONTRIBUTING.md — contribution guidelines and repository etiquette
• .github/ISSUE_TEMPLATE/feature_request.yml — the structured issue template
• README.md — project overview and quick start information

Summary

• Start with Discord for informal validation of your feature idea
• Use the GitHub feature request template at .github/ISSUE_TEMPLATE/feature_request.yml for formal proposals
• Complete all template fields, especially implementation notes if you have technical insight
• Engage actively after submission to refine the proposal with maintainer feedback
• Consider implementing the feature yourself if design approval is granted

Following this structured approach to suggesting a new feature for Kaneo demonstrates respect for maintainer time and maximizes your proposal's chance of success.

Frequently Asked Questions

Do I have to join Discord before suggesting a feature?

No, Discord discussion is optional but highly recommended. You can submit a GitHub issue directly using the feature request template. However, early Discord conversations often lead to stronger proposals and can prevent wasted effort if similar features are already in development.

What happens if my feature request gets no response?

Kaneo maintainers typically respond to well-structured issues within days. If your issue stalls, politely bump it after a week with additional context or implementation details. Low-quality submissions—vague descriptions, missing motivation, or unchecked duplicates—are more likely to be overlooked.

Can I suggest a feature and implement it myself immediately?

You can, but the process works better with community input first. Opening an issue before coding ensures your approach aligns with project architecture and avoids rejected pull requests due to design mismatches. The CONTRIBUTING.md file explicitly recommends discussing significant changes before implementation.

What makes a feature request more likely to be accepted?

Four factors increase acceptance odds: clear user benefit documented in the motivation section, feasible scope that doesn't require major rewrites, implementation notes showing technical awareness, and active follow-up demonstrating commitment to seeing the feature through.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}