feature_request.yml 9.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194
  1. name: Detailed Feature Proposal
  2. description: Propose a specific, actionable feature or enhancement for implementation
  3. labels: ["proposal", "enhancement"]
  4. body:
  5. - type: markdown
  6. attributes:
  7. value: |
  8. **Thank you for proposing a feature for Roo Code!**
  9. This template is for specific, actionable proposals following our [Issue-First Approach](https://github.com/RooCodeInc/Roo-Code/blob/main/CONTRIBUTING.md).
  10. **Quality over speed:** We prefer detailed, clear proposals over quick ones. Vague proposals often get closed or require multiple rounds of clarification, which wastes everyone's time.
  11. **Before submitting:**
  12. - Search existing [Issues](https://github.com/RooCodeInc/Roo-Code/issues) and [Discussions](https://github.com/RooCodeInc/Roo-Code/discussions) to avoid duplicates
  13. - For general ideas, use [GitHub Discussions](https://github.com/RooCodeInc/Roo-Code/discussions/categories/feature-requests) first, or use the #collaboration-board channel in our [Discord](https://discord.gg/roocode)
  14. - Join [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph** (`hrudolph`) for guidance
  15. **Review process:** A maintainer (especially @hannesrudolph) will review this proposal. **Do not start implementation until approved and assigned.** We're a small team with limited resources, so every code addition needs careful consideration. We're always happy to receive clear, actionable proposals though!
  16. - type: markdown
  17. attributes:
  18. value: |
  19. ## ❌ Common mistakes that lead to proposal rejection:
  20. - **Vague problem descriptions:** "UI is bad" -> Should be: "Submit button is invisible on dark theme"
  21. - **Solution without context:** "Add feature X" -> Should explain the problem first, then the solution
  22. - **Missing user impact:** "This would be cool" -> Should explain who benefits and how
  23. - **No acceptance criteria:** How do we know when it's done? What does success look like?
  24. If you're unsure how a good proposal should look like, you can check out our [Roadmap](https://github.com/orgs/RooCodeInc/projects/1/views/1?query=sort%3Aupdated-desc+is%3Aopen&filterQuery=is%3Aissue%2Copen%2Cclosed+label%3A%22feature+request%22+status%3A%22Issue+%5BUnassigned%5D%22%2C%22Issue+%5BIn+Progress%5D%22) where we have a list of all open feature requests that are ready to be implemented or currently being worked on.
  25. - type: textarea
  26. id: problem-description
  27. attributes:
  28. label: What specific problem does this solve?
  29. description: |
  30. **Be concrete and detailed.** Explain the problem from a user's perspective.
  31. ✅ **Good examples (specific, clear impact):**
  32. - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
  33. - "AI can only read one file per request, forcing users to make multiple requests for multi-file projects, increasing wait time from 30s to 5+ minutes"
  34. - "Dark theme users can't see the submit button because it uses white text on light grey background"
  35. ❌ **Poor examples (vague, unclear impact):**
  36. - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
  37. - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
  38. - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
  39. **Your problem description should answer:**
  40. - Who is affected? (all users, specific user types, etc.)
  41. - When does this happen? (specific scenarios/steps)
  42. - What's the current behaviour vs expected behaviour?
  43. - What's the impact? (time wasted, errors caused, etc.)
  44. placeholder: Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."
  45. validations:
  46. required: true
  47. - type: textarea
  48. id: proposed-solution
  49. attributes:
  50. label: How should this be solved?
  51. description: |
  52. **Describe your solution in detail.** Explain not just what to build, but how it should work.
  53. ✅ **Good examples:**
  54. - "Add parallel task execution: Allow up to 3 tasks to run simultaneously with a queue system for additional tasks. Show progress for each active task in the UI."
  55. - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
  56. - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
  57. ❌ **Poor examples:**
  58. - "Make it faster" -> How? What specific changes?
  59. - "Improve the UI" -> Which part? What specific improvements?
  60. - "Fix the prompt" -> What should the new prompt do differently?
  61. **Your solution should explain:**
  62. - What exactly will change?
  63. - How will users interact with it?
  64. - What will the new behaviour look like?
  65. placeholder: Describe the specific changes and how they will work. Include user interaction details if relevant.
  66. validations:
  67. required: true
  68. - type: textarea
  69. id: acceptance-criteria
  70. attributes:
  71. label: How will we know it works? (Acceptance Criteria)
  72. description: |
  73. **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
  74. **Format suggestion:**
  75. ```
  76. Given [context/situation]
  77. When [user action]
  78. Then [expected result]
  79. And [additional expectations]
  80. But [what should NOT happen]
  81. ```
  82. **Example:**
  83. ```
  84. Given I have 5 large tasks to run
  85. When I start all of them
  86. Then they execute in parallel (max 3 at once, can be configured)
  87. And I see progress for each active task
  88. And queued tasks show "waiting" status
  89. But the UI doesn't freeze or become unresponsive
  90. ```
  91. placeholder: |
  92. Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
  93. Use the Given/When/Then format above or your own clear structure.
  94. validations:
  95. required: true
  96. - type: textarea
  97. id: estimated-effort
  98. attributes:
  99. label: Estimated effort and complexity
  100. description: |
  101. **Help us understand the scope.** This helps with planning and prioritisation.
  102. **Please include:**
  103. - **Size estimate:** XS/Small/Medium/Large/XL (or hours/days if you prefer)
  104. - **Reasoning:** What makes it this size? Which parts are complex?
  105. - **Main challenges:** What's the trickiest bit to implement?
  106. - **Dependencies:** Does this require other changes or external libraries?
  107. **Example:**
  108. ```
  109. Size: Large (2-3 weeks)
  110. Reasoning: Touches task execution engine, UI components, and state management
  111. Main challenges: Preventing memory leaks with parallel execution and managing shared resources
  112. Dependencies: Might need to add a new dependency for the new feature
  113. ```
  114. placeholder: |
  115. Size: [your estimate]
  116. Reasoning: [why this size?]
  117. Main challenges: [what's tricky?]
  118. Dependencies: [what else is needed?]
  119. validations:
  120. required: true
  121. - type: textarea
  122. id: technical-considerations
  123. attributes:
  124. label: Technical considerations (optional but helpful)
  125. description: |
  126. Share technical insights that could help planning:
  127. - Implementation approach or architecture changes
  128. - Performance implications
  129. - Compatibility concerns
  130. - Systems that might be affected
  131. - Potential blockers you can foresee
  132. placeholder: e.g., "Will need to refactor task manager", "Could impact memory usage on large files", "Requires a large portion of code to be rewritten"
  133. - type: textarea
  134. id: trade-offs-and-risks
  135. attributes:
  136. label: Trade-offs and risks (optional)
  137. description: |
  138. What could go wrong or what alternatives did you consider?
  139. - Alternative approaches and why you chose this one
  140. - Potential negative impacts (performance, UX, etc.)
  141. - Breaking changes or migration concerns
  142. - Edge cases that need careful handling
  143. placeholder: 'e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"'
  144. - type: textarea
  145. id: additional-context
  146. attributes:
  147. label: Additional context (optional)
  148. description: Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.
  149. - type: checkboxes
  150. id: checklist
  151. attributes:
  152. label: Proposal checklist
  153. options:
  154. - label: I've searched existing Issues and Discussions for duplicates
  155. required: true
  156. - label: This is a specific, actionable proposal with clear problem and solution
  157. required: true
  158. - label: I've included concrete acceptance criteria
  159. required: true
  160. - label: I understand this needs approval before implementation begins
  161. required: true
  162. - type: checkboxes
  163. id: willingness-to-contribute
  164. attributes:
  165. label: Interested in implementing this?
  166. description: Optional - doesn't affect proposal consideration
  167. options:
  168. - label: Yes, I'd like to help implement this feature
  169. required: false