feature_request.yml 9.4 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191
  1. name: Detailed Feature Proposal
  2. description: Report a specific problem that needs solving in Roo Code
  3. labels: ["proposal", "enhancement"]
  4. body:
  5. - type: markdown
  6. attributes:
  7. value: |
  8. **Thank you for submitting a feature request for Roo Code!**
  9. This template helps you describe problems that need solving. Focus on the problem - the Roo team will work to design solutions unless you want to contribute the implementation yourself.
  10. **Quality over speed:** We prefer detailed, clear problem descriptions over quick ones. Vague requests 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) instead of this template.
  14. - type: markdown
  15. attributes:
  16. value: |
  17. ## ❌ Common mistakes that lead to request rejection:
  18. - **Vague problem descriptions:** "UI is bad" -> Should be: "Submit button is invisible on dark theme"
  19. - **Missing user impact:** "This would be cool" -> Should explain who benefits and how
  20. - **No specific context:** Describe exactly when and how the problem occurs
  21. - type: textarea
  22. id: problem-description
  23. attributes:
  24. label: What specific problem does this solve?
  25. description: |
  26. **Be concrete and detailed.** Explain the problem from a user's perspective.
  27. ✅ **Good examples (specific, clear impact):**
  28. - "When running large tasks, users wait 5+ minutes because tasks execute sequentially instead of in parallel, blocking productivity"
  29. - "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"
  30. - "Dark theme users can't see the submit button because it uses white text on light grey background"
  31. ❌ **Poor examples (vague, unclear impact):**
  32. - "The UI looks weird" -> What specifically looks weird? On which screen? What's the impact?
  33. - "System prompt is not good" -> What's wrong with it? What behaviour does it cause? What should it do instead?
  34. - "Performance could be better" -> Where? How slow is it currently? What's the user impact?
  35. **Your problem description should answer:**
  36. - Who is affected? (all users, specific user types, etc.)
  37. - When does this happen? (specific scenarios/steps)
  38. - What's the current behaviour vs expected behaviour?
  39. - What's the impact? (time wasted, errors caused, etc.)
  40. placeholder: Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."
  41. validations:
  42. required: true
  43. - type: textarea
  44. id: additional-context
  45. attributes:
  46. label: Additional context (optional)
  47. description: Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.
  48. - type: checkboxes
  49. id: checklist
  50. attributes:
  51. label: Request checklist
  52. options:
  53. - label: I've searched existing Issues and Discussions for duplicates
  54. required: true
  55. - label: This describes a specific problem with clear impact and context
  56. required: true
  57. - type: markdown
  58. attributes:
  59. value: |
  60. ---
  61. ## 🛠️ **Optional: Contributing & Technical Analysis**
  62. **🎯 Just reporting a problem?** You can click "Submit new issue" right now! The sections below are only needed if you want to contribute a solution via pull request.
  63. **⚠️ Only continue if you want to:**
  64. - Propose a specific solution design
  65. - Implement the feature yourself via pull request
  66. - Provide technical analysis to help with implementation
  67. **For contributors who continue:**
  68. - 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!
  69. - Join [Discord](https://discord.gg/roocode) and DM **Hannes Rudolph** (`hrudolph`) for guidance on implementation
  70. - Check 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) to see open feature requests ready to be implemented or currently being worked on
  71. - type: checkboxes
  72. id: willingness-to-contribute
  73. attributes:
  74. label: Interested in implementing this?
  75. description: |
  76. **Important:** If you check "Yes" below, the technical sections become REQUIRED.
  77. We need detailed technical analysis from contributors to ensure quality implementation.
  78. options:
  79. - label: Yes, I'd like to help implement this feature
  80. required: false
  81. - type: checkboxes
  82. id: implementation-approval
  83. attributes:
  84. label: Implementation requirements
  85. options:
  86. - label: I understand this needs approval before implementation begins
  87. required: false
  88. - type: textarea
  89. id: proposed-solution
  90. attributes:
  91. label: How should this be solved? (REQUIRED if contributing, optional otherwise)
  92. description: |
  93. **If you want to implement this feature, this section is REQUIRED.**
  94. **Describe your solution in detail.** Explain not just what to build, but how it should work.
  95. ✅ **Good examples:**
  96. - "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."
  97. - "Enable multi-file AI processing: Modify the request handler to accept multiple files in a single request and process them together, reducing round trips."
  98. - "Fix button contrast: Change submit button to use primary colour on dark theme (white text on blue background) instead of current grey."
  99. ❌ **Poor examples:**
  100. - "Make it faster" -> How? What specific changes?
  101. - "Improve the UI" -> Which part? What specific improvements?
  102. - "Fix the prompt" -> What should the new prompt do differently?
  103. **Your solution should explain:**
  104. - What exactly will change?
  105. - How will users interact with it?
  106. - What will the new behaviour look like?
  107. placeholder: Describe the specific changes and how they will work. Include user interaction details if relevant.
  108. - type: textarea
  109. id: acceptance-criteria
  110. attributes:
  111. label: How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)
  112. description: |
  113. **If you want to implement this feature, this section is REQUIRED.**
  114. **This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.
  115. **Format suggestion:**
  116. ```
  117. Given [context/situation]
  118. When [user action]
  119. Then [expected result]
  120. And [additional expectations]
  121. But [what should NOT happen]
  122. ```
  123. **Example:**
  124. ```
  125. Given I have 5 large tasks to run
  126. When I start all of them
  127. Then they execute in parallel (max 3 at once, can be configured)
  128. And I see progress for each active task
  129. And queued tasks show "waiting" status
  130. But the UI doesn't freeze or become unresponsive
  131. ```
  132. placeholder: |
  133. Define specific, testable criteria. What should users be able to do? What should happen? What should NOT happen?
  134. Use the Given/When/Then format above or your own clear structure.
  135. - type: textarea
  136. id: technical-considerations
  137. attributes:
  138. label: Technical considerations (REQUIRED if contributing, optional otherwise)
  139. description: |
  140. **If you want to implement this feature, this section is REQUIRED.**
  141. Share technical insights that could help planning:
  142. - Implementation approach or architecture changes
  143. - Performance implications
  144. - Compatibility concerns
  145. - Systems that might be affected
  146. - Potential blockers you can foresee
  147. 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"
  148. - type: textarea
  149. id: trade-offs-and-risks
  150. attributes:
  151. label: Trade-offs and risks (REQUIRED if contributing, optional otherwise)
  152. description: |
  153. **If you want to implement this feature, this section is REQUIRED.**
  154. What could go wrong or what alternatives did you consider?
  155. - Alternative approaches and why you chose this one
  156. - Potential negative impacts (performance, UX, etc.)
  157. - Breaking changes or migration concerns
  158. - Edge cases that need careful handling
  159. placeholder: 'e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"'