Proposal: Automatically synchronize issues between frontend and backend repositories?

[marcvergees]

Proposal: Automatically synchronize issues between frontend and backend repositories?

We've had an ongoing internal discussion about the overhead of creating the same issue in both the frontend and backend repositories whenever a feature or bug spans both codebases.

At the moment, the process is entirely manual: if an issue affects both repositories, someone has to create it twice and keep both copies reasonably in sync. This is repetitive and easy to forget.

The challenge

Not every issue belongs in both repositories.

Some examples:

• Backend-only

  • Database migrations
  • API implementation
  • Authentication logic
  • Performance improvements

• Frontend-only

  • UI redesign
  • Accessibility fixes
  • Client-side validation
  • Styling

• Cross-repository

  • New features requiring both API and UI changes
  • Breaking API changes
  • Form schema updates
  • End-to-end bug fixes

Because of this, simply mirroring every issue would probably create unnecessary noise.

Possible approach

One idea would be to create a GitHub Action (or another automation) that only mirrors issues when explicitly requested.

For example, when creating an issue, we could use one of several mechanisms:

• a label such as sync:frontend, sync:backend, or cross-repo

• a dedicated issue template field

• a checkbox like:

  • ☑ Create corresponding issue in frontend
  • ☑ Create corresponding issue in backend

The workflow would then:

1. Detect that the issue should be synchronized.
2. Create a corresponding issue in the other repository.
3. Include a link between both issues.
4. Optionally synchronize status changes (closed/reopened) or comments if we decide that's valuable.

This keeps synchronization opt-in rather than automatic.

Things to consider

There are a few questions we'd need to answer before implementing anything:

• Should synchronization be opt-in or opt-out?
• Should only the issue title/body be copied, or also labels, assignees, milestones, etc.?
• Should closing one issue automatically close its counterpart?
• Should comments be synchronized?
• How should we handle issues that later become frontend-only or backend-only?
• Would a GitHub Action be sufficient, or would a GitHub App provide more flexibility?

Alternative

Instead of creating duplicate issues, another option would be to have a single "source of truth" issue in one repository and simply reference it from the other. This reduces duplication but also makes project boards and repository-specific planning a bit more difficult.

Open for discussion

I think it's worth designing a solution that handles all three cases cleanly:

• frontend-only issues
• backend-only issues
• cross-repository issues

rather than assuming every issue should exist in both repositories.

Curious to hear everyone's thoughts:

• Is the current manual process actually painful enough to automate?
• If so, what should be the trigger for synchronization?
• Are there edge cases we're missing?

[chetanr25]

Thanks for writing this up. My take is that we might not need automation here at all.

There is no rule that a PR must link an issue from its own repository. GitHub lets us link and reference issues across repositories, so a frontend PR can point to a backend issue directly. That already removes most of the reason to duplicate issues.

In practice the backend API always comes first. Building the frontend before the API exists makes no sense. So the natural flow would be:

1. Create the issue in FireForm (backend), since that is where the work starts.
2. If the feature needs frontend changes, we have two options:
   • open a separate issue in the frontend repo or
   • describe the frontend work inside the same backend issue, and the frontend PR just references that issue.

This keeps one source of truth for each feature instead of two copies we have to keep in sync. Duplicated issues drift apart over time, and closing one while forgetting the other creates confusion. A single issue with cross-repo links avoids that problem without any workflow, action, or app to maintain.

So to answer the questions directly: I don't think the manual process is painful enough to automate. The pain comes from duplicating, not from linking. If we stop duplicating and just reference the backend issue from frontend PRs, the problem mostly goes away.

[abhishek-8081]

Greetings @marcvergees @chetanr25 @vharkins1 , I went through the discussion and wanted to share my thoughts.

I agree with Chetan that the real problem here is duplication, not syncing. If we stop creating identical issues in both repos, most of the pain goes away on its own. Automation that mirrors issues doesn't fix that — it just makes two copies that drift apart automatically instead of manually.

I also agree that backend should always be the source of truth. The API has to exist before the frontend can do anything, so it makes sense for the issue to live in FireForm first.

That said, I think there's one gap in the pure "just reference the backend issue" approach — frontend project board tracking. If no issue exists in the frontend repo, contributors working there have to jump to the backend repo to find their work. That gets messy as more people join.

What I think can work

For cross-repo features, something like this:

1. Create the issue in FireForm as usual, since that's where the work starts
2. Open a small linked issue in fireform-frontend — just a title like Frontend: [feature name] (see fireform-core/FireForm#N) and a one-line description. No duplicating the full body.
3. All discussion happens in the backend issue. The frontend issue exists only for assignment and board tracking.
4. Both PRs close their own issues independently when done.

This keeps one source of truth for discussion and gives frontend contributors visibility into their work without any automation to maintain.

One small thing worth being careful about

When writing PR descriptions, use Related to fireform-core/FireForm#N instead of Closes fireform-core/FireForm#N — unless that PR is the very last one completing the feature. If a frontend PR uses Closes and merges before the backend PR, GitHub will automatically close the backend issue even though the backend work isn't finished yet.

• Teams with backend/frontend splits consistently use the backend repo as the canonical home for cross-repo issues, and just reference it from the other side.
• For larger orgs that need a central view, some use a dedicated tracker repo or their existing .github repo as the single place for cross-repo epics. FireForm already has a .github repo in the org, so that option exists without adding anything new if we ever need it down the line.

Overall I think Chetan's direction is right. The only additions I'd suggest are the minimal frontend issue for board tracking and being careful about the closing keyword order in PRs.

[chetanr25]

The Issues are automatically closed as soon as PR is merged? Didn't knew it existed.
also, I always use blank PR template hence i write if the PR is related or closes the issue by myself. (Just a preference)

[chetanr25]

Talking about Projects tab, I think we are using 🚀 GSoC '26 | 16-Week Engineering Track (view) which is centralised to the whole org. Since the issue about the frontend will be mentioned in the backend repository itself and the same issue can be tagged, by default that issue is tracked in projects.

Plus we can always open issue on frontend if necessary. That won't be an issue.

Coming to auto close issue, is that true @marcvergees?

[marcvergees]

Exactly like @abhishek-8081 was pointing out there are a few ways to autoclose issues. First of all, you can create and issue and create a branch from that issue from the page of the issue, that way there's kinda a connection between the future PR of this branch and the issue, so as soon it's merged, it'll be closed automatically.

The other option to close it is using keywords, as @abhishek-8081 was explaining.

[chetanr25]

Understood. We can always use Related instead of all the mentioned keywords. If the contributors had already mentioned any of those keywords without fixing the whole issue, maintainers can always edit or ask them to edit.

If the maintainers merged the PR before they saw the keyword used. they can always open the Issue again.