Auto create an issue if it is not there

[SmartManoj]

What specific problem does this solve?

Questioning necessity of having both a GitHub issue and PR

#3661 (comment)

How should this be solved?

Using Github Actions

How will we know it works? (Acceptance Criteria)

Given no issue creation
When PR created
Then Action will create it
And mark the PR as draft
But the PR should not be closed till the issue resolved.

Estimated effort and complexity

Size: XS
Reasoning: -
Main challenges: -
Dependencies: -

Technical considerations (optional but helpful)

No response

Trade-offs and risks (optional)

No response

Additional context (optional)

No response

Proposal checklist

• I've searched existing Issues and Discussions for duplicates
• This is a specific, actionable proposal with clear problem and solution
• I've included concrete acceptance criteria
• I understand this needs approval before implementation begins

Interested in implementing this?

• Yes, I'd like to help implement this feature

[elianiva]

I feel like this is the opposite of what issue-first should solve, no?

The point of issue-first approach is to allow people describe their problem before pulling up a PR that would be accepted or rejected.

Having an issue/feature proposal that describes exactly what users want help contributors save time by not doing the work if the issue/feature proposal is not an issue caused by RooCode, doesn't align with RooCode's goal, or any other reasons.

If we have a GH action that automatically creates an issue after someone made a PR, that would defeat the whole purpose of this.
For example, hypothetically, I pulled up a PR with massive changes to RooCode's UI/UX and I spent hours of work, and then the team rejected it because it's too big of a change that would impact many existing users, it would waste my time as a contributor because my work ended up not being used and the reviewers time because they have to digest my big PR that doesn't really align with where RooCode is going.

Having an issue-first approach should prevent this, because we can discuss them before doing any actual work. If the task is too big, we can discuss on how to split it. If the task is not aligned with where RooCode's is going I can simply close the issue and not do the work. This would save me a ton of time as a contributor.

I know it might feel annoying, but I'm just sharing my view why the devs would want this approach over just letting people come up with random PRs.

[SmartManoj]

PR first approach would be applicable for small cases like typo, small changes related to CI like #4142. Did you read this?

---

contributors save time by not doing the work if the issue/feature proposal is not an issue caused by RooCode, doesn't align with RooCode's goal, or any other reasons.

If it doesn't match with the RooCode's goal, it may be useful for some other users, or it may be an experience. Why will the contributors waste their own precious time?

---

For example, hypothetically, I pulled up a PR with massive changes to RooCode's UI/UX and I spent hours of work, and then the team rejected it because it's too big of a change that would impact many existing users,

There is no need to reject. If the design is nice, there should be a flag to switch to the new layout.

---

it would waste my time as a contributor because my work ended up not being used

You can still use it if you really like the design.

---

because they have to digest my big PR that doesn't really align with where RooCode is going.

They don't need to touch the PR unless the issue is finalized.

---

If the task is too big, we can discuss on how to split it.

One should not create (large) PRs. That's 101. Even if they did, it would be useful to someone who wants to use it quickly.

---

people come up with random PRs.

Why?

[elianiva]

PR first approach would be applicable for small cases like typo, small changes related to CI like #4142

While I do agree, it doesn't warrant an "action to automatically create an issue from a PR", that would just add noise. Even if we do "only create issue automatically for small PR", "small" here can mean different things, if you change a single line of code but that completely changes how things work then it's no longer "small". We can't really quantify these things without actually checking the PR ourselves.

You can "skip" issue-first approach as long as you consulted with the main devs beforehand. Really, the main point of issue first is not for the sake of having an issue+PR, but to align the goals between external contributors and the main devs.

I did some PRs that didn't require me to make an issue first because I've discussed the things I want to do with the devs on Discord. That's one way to do it, but I'd still recommend making an issue because it is better for visibility.

If it doesn't match with the RooCode's goal, it may be useful for some other users, or it may be an experience. Why will the contributors waste their own precious time?

Because at the end of the day it's still up to the main devs to decide where this project should go 🙂
If it is useful for some people and the devs don't see it as a good fit, they are always free to fork it.
RooCode itself was forked from Cline because one of the devs contributed to Cline, but Cline didn't accept it at the time.

There is no need to reject. If the design is nice, there should be a flag to switch to the new layout.

Hard disagree, any code is something the devs should maintain, they are liability. Adding random stuff while hiding them under a configuration is not a solution. You may not see it, but the code is there for the devs to maintain. If every feature gets accepted but hidden under a configuration, we'd end up with dozens of feature flag already. This is why an issue is needed as a place to align between external contributors and main developers.

You can still use it if you really like the design

That was only meant as an example. Again, people are always free to fork RooCode if their contributions are not accepted and they still want to keep their change. This isn't to say "we don't accept contributions", but more about keeping things aligned with RooCode's goal. What if I just - hypothetically - enshittify RooCode UI/UX? Of course you wouldn't accept that, but I like it, does that mean RooCode is not open to contributions? Absolutely not the case here.

The issue-first approach was added because we don't want people spend their time unnecessarily for something that end up not being used. Not only that, conflicts may arise because people don't know what's being worked on and what is not. I had it several times already before issue-first became the norm.

They don't need to touch the PR unless the issue is finalized.

Fair point, but this still leads to people wasting their time working on something that may or may not get accepted. Issue being finalized doesn't always necessarily mean their work is accepted. There could be some major adjustment that needs to be done after the issue being discussed, which means double the work because A. You've done the initial PR, B. You need to rework the PR after the discussion. Why go through that when you can just create an issue, wait for the green light, and then work on the issue. You can always ping the devs (or DM Hannes) on Discord if you want attention immediately.

One should not create PRs. That's 101. Even if they did, it would be useful to someone who wants to use it quickly.

Not entirely sure what you mean by this.

Why?

Because reasons I mentioned above, which are all detailed in https://github.com/RooCodeInc/Roo-Code/blob/main/CONTRIBUTING.md
Preventing unnecessary work, PR conflicts, unaligned goals, etc etc

[SmartManoj]

While I do agree, it doesn't warrant an "action to automatically create an issue from a PR", that would just add noise

not instantly, but using a label "needs discussion" to trigger it.

---

You can "skip" issue-first approach as long as you consulted with the main devs beforehand

That would only create noise.

---

If it is useful for some people and the devs don't see it as a good fit, they are always free to fork it.

That PR will create visibility for the fork.

---

I had it several times already before issue-first became the norm.

Would you please point out those PRs?

---

Why go through that when you can just create an issue, wait for the green light, and then work on the issue.

Here, waiting for the green light is not instant. The Perils of Waiting: Why Proactivity is Essential for Success
Eg: #4138 (comment), without blacklisting the command, the agent is not useful for that task as it keeps on killing other programs. It may not be the best solution as it is just a simple workaround. till the issue is solved, it may be useful for someone. Even it is not, you created a workaround and you shared with the community.

---

You can always ping the devs (or DM Hannes) on Discord if you want attention immediately.

That's wrong.

---

One should not create PRs.

large PRs

---

Preventing unnecessary work,

not if AI agent triaged the PR

---

PR conflicts

rare case, still a lesson for the contributor to create an issue first.

---

unaligned goals

Then it would serve as an example.