Skip to content

Merge main into work #2

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: feat/subtask-timeout
Choose a base branch
from
Open

Merge main into work #2

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 91 additions & 17 deletions .roo/rules-issue-writer/1_workflow.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -30,10 +30,11 @@
- Any error messages or logs

For Feature Requests, ensure you have:
- Specific problem description with impact
- Detailed proposed solution
- Clear acceptance criteria in Given/When/Then format
- Effort estimation with reasoning
- Specific problem description with impact (who is affected, when it happens, current vs expected behavior, impact)
- Additional context if available (mockups, screenshots, links)

IMPORTANT: Do NOT ask for solution design, acceptance criteria, or technical details
unless the user explicitly states they want to contribute the implementation.

Use multiple ask_followup_question calls if needed to gather all information.
Be specific in your questions based on what's missing.
Expand Down Expand Up @@ -63,8 +64,31 @@
</step>

<step number="4">
<name>Explore Codebase for Context</name>
<name>Determine if User Wants to Contribute</name>
<instructions>
Before exploring the codebase, determine if the user wants to contribute the implementation:

<ask_followup_question>
<question>Are you interested in implementing this feature yourself, or are you just reporting the problem for the Roo team to solve?</question>
<follow_up>
<suggest>Just reporting the problem - the Roo team can design the solution</suggest>
<suggest>I want to contribute and implement this feature myself</suggest>
<suggest>I'm not sure yet, but I'd like to provide technical analysis</suggest>
</follow_up>
</ask_followup_question>

Based on their response:
- If just reporting: Skip to step 6 (Draft Issue - Problem Only)
- If contributing: Continue to step 5 (Explore Codebase)
- If providing analysis: Continue to step 5 but make technical sections optional
</instructions>
</step>

<step number="5">
<name>Explore Codebase for Contributors</name>
<instructions>
ONLY perform this step if the user wants to contribute or provide technical analysis.

Use codebase_search FIRST to understand the relevant parts of the codebase:

For Bug Reports:
Expand Down Expand Up @@ -95,15 +119,20 @@
- Current implementation details
- Your proposed implementation plan
- Related code that might be affected

Then gather additional technical details:
- Ask for proposed solution approach
- Request acceptance criteria in Given/When/Then format
- Discuss technical considerations and trade-offs
</instructions>
</step>

<step number="5">
<name>Draft Complete Issue Content</name>
<step number="6">
<name>Draft Issue Content</name>
<instructions>
Create the complete issue body following the exact template structure.
Create the issue body based on whether the user is just reporting or contributing.

For Bug Reports, format as:
For Bug Reports, format is the same regardless of contribution intent:
```
## App Version
[version from user]
Expand Down Expand Up @@ -146,7 +175,30 @@
- **Proposed Fix:** [Detail the fix from your implementation plan.]
```

For Feature Requests, format as:
For Feature Requests - PROBLEM REPORTERS (not contributing):
```
## What specific problem does this solve?

[Detailed problem description following the template guidelines]

**Who is affected:** [user groups]
**When this happens:** [specific scenarios]
**Current behavior:** [what happens now]
**Expected behavior:** [what should happen]
**Impact:** [time wasted, errors, productivity loss]

## Additional context

[Any mockups, screenshots, links, or other supporting information]

## Related Discussions

[If any related discussions were found, list them here]
- Closes #[discussion number] - [discussion title]
- Related to #[discussion number] - [discussion title]
```

For Feature Requests - CONTRIBUTORS (implementing the feature):
```
## What specific problem does this solve?

Expand All @@ -158,6 +210,17 @@
**Expected behavior:** [what should happen]
**Impact:** [time wasted, errors, productivity loss]

## Additional context

[Any mockups, screenshots, links, or other supporting information]

---

## 🛠️ Contributing & Technical Analysis

✅ **I'm interested in implementing this feature**
✅ **I understand this needs approval before implementation begins**

## How should this be solved?

[Based on your independent analysis, describe your proposed solution here. Disregard the author's proposal.]
Expand All @@ -182,7 +245,7 @@

[Add multiple scenarios as needed]

## Estimated Effort and Complexity
## Technical Considerations

**Size:** [estimate]
**Reasoning:** [why this size]
Expand All @@ -198,13 +261,24 @@
- Similar patterns in codebase: [examples]
- Implementation Steps: [Provide a detailed, step-by-step guide for your proposed solution.]

## Technical Considerations
**Performance implications:**
[Any performance considerations]

[Any additional technical details]
**Compatibility concerns:**
[Any compatibility issues]

## Trade-offs and Risks

[Alternatives considered and potential issues]
**Alternatives considered:**
- [Alternative 1]: [Why not chosen]
- [Alternative 2]: [Why not chosen]

**Potential risks:**
- [Risk 1]: [Mitigation strategy]
- [Risk 2]: [Mitigation strategy]

**Breaking changes:**
[Any breaking changes or migration needs]

## Related Discussions

Expand All @@ -215,7 +289,7 @@
</instructions>
</step>

<step number="6">
<step number="7">
<name>Review and Confirm with User</name>
<instructions>
Present the complete drafted issue to the user for review:
Expand All @@ -238,7 +312,7 @@
</instructions>
</step>

<step number="7">
<step number="8">
<name>Create GitHub Issue</name>
<instructions>
Once user confirms, create the issue using the GitHub MCP tool:
Expand All @@ -251,7 +325,7 @@
"owner": "RooCodeInc",
"repo": "Roo-Code",
"title": "[Create a descriptive title based on the issue content]",
"body": "[The complete formatted issue body from step 4]",
"body": "[The complete formatted issue body from step 6]",
"labels": [Use ["bug"] for bug reports or ["proposal", "enhancement"] for features]
}
</arguments>
Expand Down
95 changes: 55 additions & 40 deletions .roo/rules-issue-writer/2_github_issue_templates.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -69,9 +69,9 @@

<feature_request_template>
<name>Detailed Feature Proposal</name>
<description>Propose a specific, actionable feature or enhancement for implementation</description>
<description>Report a specific problem that needs solving in Roo Code</description>
<labels>["proposal", "enhancement"]</labels>
<fields>
<required_fields>
<field name="problem-description" type="textarea" required="true">
<label>What specific problem does this solve?</label>
<description>
Expand All @@ -95,9 +95,30 @@
</description>
<placeholder>Be specific about the problem, who it affects, and the impact. Avoid generic statements like "it's slow" or "it's confusing."</placeholder>
</field>
<field name="proposed-solution" type="textarea" required="true">
<label>How should this be solved?</label>
<field name="additional-context" type="textarea" required="false">
<label>Additional context (optional)</label>
<description>Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.</description>
</field>
</required_fields>

<contributor_fields>
<field name="willingness-to-contribute" type="checkbox">
<label>Interested in implementing this?</label>
<description>
**Important:** If you check "Yes" below, the technical sections become REQUIRED.
We need detailed technical analysis from contributors to ensure quality implementation.
</description>
<option>Yes, I'd like to help implement this feature</option>
</field>
<field name="implementation-approval" type="checkbox">
<label>Implementation requirements</label>
<option>I understand this needs approval before implementation begins</option>
</field>
<field name="proposed-solution" type="textarea" required_if_contributing="true">
<label>How should this be solved? (REQUIRED if contributing, optional otherwise)</label>
<description>
**If you want to implement this feature, this section is REQUIRED.**

**Describe your solution in detail.** Explain not just what to build, but how it should work.

✅ **Good examples:**
Expand All @@ -117,9 +138,11 @@
</description>
<placeholder>Describe the specific changes and how they will work. Include user interaction details if relevant.</placeholder>
</field>
<field name="acceptance-criteria" type="textarea" required="true">
<label>How will we know it works? (Acceptance Criteria)</label>
<field name="acceptance-criteria" type="textarea" required_if_contributing="true">
<label>How will we know it works? (Acceptance Criteria - REQUIRED if contributing, optional otherwise)</label>
<description>
**If you want to implement this feature, this section is REQUIRED.**

**This is crucial - don't skip it.** Define what "working" looks like with specific, testable criteria.

**Format suggestion:**
Expand All @@ -146,35 +169,11 @@
Use the Given/When/Then format above or your own clear structure.
</placeholder>
</field>
<field name="estimated-effort" type="textarea" required="true">
<label>Estimated effort and complexity</label>
<field name="technical-considerations" type="textarea" required_if_contributing="true">
<label>Technical considerations (REQUIRED if contributing, optional otherwise)</label>
<description>
**Help us understand the scope.** This helps with planning and prioritisation.
**If you want to implement this feature, this section is REQUIRED.**

**Please include:**
- **Size estimate:** XS/Small/Medium/Large/XL
- **Reasoning:** What makes it this size? Which parts are complex?
- **Main challenges:** What's the trickiest bit to implement?
- **Dependencies:** Does this require other changes or external libraries?

**Example:**
```
Size: Large
Reasoning: Touches task execution engine, UI components, and state management
Main challenges: Preventing memory leaks with parallel execution and managing shared resources
Dependencies: Might need to add a new dependency for the new feature
```
</description>
<placeholder>
Size: [your estimate]
Reasoning: [why this size?]
Main challenges: [what's tricky?]
Dependencies: [what else is needed?]
</placeholder>
</field>
<field name="technical-considerations" type="textarea" required="false">
<label>Technical considerations (optional but helpful)</label>
<description>
Share technical insights that could help planning:
- Implementation approach or architecture changes
- Performance implications
Expand All @@ -184,9 +183,11 @@
</description>
<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"</placeholder>
</field>
<field name="trade-offs-and-risks" type="textarea" required="false">
<label>Trade-offs and risks (optional)</label>
<field name="trade-offs-and-risks" type="textarea" required_if_contributing="true">
<label>Trade-offs and risks (REQUIRED if contributing, optional otherwise)</label>
<description>
**If you want to implement this feature, this section is REQUIRED.**

What could go wrong or what alternatives did you consider?
- Alternative approaches and why you chose this one
- Potential negative impacts (performance, UX, etc.)
Expand All @@ -195,10 +196,24 @@
</description>
<placeholder>e.g., "Alternative: use library X but it is 500KB larger", "Risk: might slow older devices", "Breaking: changes API response format"</placeholder>
</field>
<field name="additional-context" type="textarea" required="false">
<label>Additional context (optional)</label>
<description>Mockups, screenshots, links, user quotes, or other relevant information that supports your proposal.</description>
</field>
</fields>
</contributor_fields>
</feature_request_template>

<template_changes_summary>
<change type="focus_shift">
Template now focuses on problem reporting first, with solution contribution as optional
</change>
<change type="required_fields">
Only problem description and context are required for basic submission
</change>
<change type="contributor_section">
Technical fields (solution, acceptance criteria, etc.) are only required if user wants to contribute
</change>
<change type="clear_exit_point">
Users can submit after describing the problem without technical details
</change>
<change type="guidance_separation">
Implementation guidance moved to contributor section only
</change>
</template_changes_summary>
</github_issue_templates>
48 changes: 36 additions & 12 deletions .roo/rules-issue-writer/3_best_practices.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,14 +1,38 @@
<best_practices>
- Always search for existing similar issues before creating a new one
- Search GitHub Discussions (especially feature-requests category) for related topics
- Include specific version numbers and environment details
- Use code blocks with syntax highlighting for code snippets
- Reference specific files and line numbers from codebase exploration
- Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
- For bugs, always test if the issue is reproducible
- For features, ensure the proposal aligns with project goals
- Include screenshots or mockups when relevant (ask user to provide)
- Link to related issues or PRs if found during exploration
- Add "Closes #[number]" for discussions that would be fully addressed by the issue
- Add "Related to #[number]" for partially related discussions
<problem_reporting_focus>
- Focus on helping users describe problems clearly, not solutions
- The Roo team will design solutions unless the user explicitly wants to contribute
- Don't push users to provide technical details they may not have
- Make it easy for non-technical users to report issues effectively
</problem_reporting_focus>

<general_practices>
- Always search for existing similar issues before creating a new one
- Search GitHub Discussions (especially feature-requests category) for related topics
- Include specific version numbers and environment details
- Use code blocks with syntax highlighting for code snippets
- Make titles descriptive but concise (e.g., "Dark theme: Submit button invisible due to white-on-grey text")
- For bugs, always test if the issue is reproducible
- Include screenshots or mockups when relevant (ask user to provide)
- Link to related issues or PRs if found during exploration
- Add "Closes #[number]" for discussions that would be fully addressed by the issue
- Add "Related to #[number]" for partially related discussions
</general_practices>

<contributor_specific>
- Only explore codebase if user wants to contribute
- Reference specific files and line numbers from codebase exploration
- Ensure technical proposals align with project architecture
- Include implementation steps and technical analysis
- Provide clear acceptance criteria in Given/When/Then format
- Consider trade-offs and alternative approaches
</contributor_specific>

<communication_guidelines>
- Be supportive and encouraging to problem reporters
- Don't overwhelm users with technical questions upfront
- Clearly indicate when technical sections are optional
- Guide contributors through the additional requirements
- Make the "submit now" option clear for problem reporters
</communication_guidelines>
</best_practices>
Loading
Loading