Show matching issues and PRs together

[damithc]

Is it possible to show issues and the corresponding PRs together? For example, like this?

This will need analysing the PR description to find Fixes ... annotations.

Rationale: It will help the team spot anomalies (e.g., PR without an issue) and pending tasks (i.e., issues without PRs). It will also encourage devs to use Fixes ... annotations.

[yucongkoo]

Good suggestion. This feature does sound like a good to have, we would likely not need to analyse the PR descriptions in our application logic, instead we could change the query used to fetch PRs to also fetch the issues that the PR closes (I quickly searched up and we should be able to use closingIssuesReferences field in PR objects).

However, from the technical side, this increases the difference between the PR objects and Issue Objects, and in our application we are modelling them as the same Issue class (although they already have certain differences), so I think we should first do some refactoring to create different models for Issue and PR before we start implementing this change. I think that the refactoring would be non-trivial and might need quite big effort. What do the others think?

[IzN432]

It's probably best to eventually refactor it, but for now I think we can just check the issueOrPr field if we want to get this out the door.

Some things that we should discuss with regards to this feature:

1. How to handle multiple PRs fixing the same issue?

There can be multiple PRs fixing the same issue and one PR can fix multiple issues. My suggestion would be to simply display the issue under every PR that claims to fix it. This brings up a separate question of what count should we display? Inclusive or exclusive of duplicates?

2. How to handle closed PRs?

If a PR has been closed, we probably don't want to display any issues that it claims to fix under it, so we should probably just ignore closed PRs. This is separate from merged PRs, which we do want to display the fixed issues under.

3. How to handle if a PR fixes an issue assigned to another user?

Should we still display the issue under User A's PR if it fixes an issue assigned to User B? I think we should still display it.

4. How should this feature be toggled?

Should it be on at all times? Should we add a button to the filter bar? I think it would be okay to keep it on, since if the user wants to search or sort for a specific issue they can always just filter out PRs.

[damithc]

1. How to handle multiple PRs fixing the same issue?

There can be multiple PRs fixing the same issue and one PR can fix multiple issues. My suggestion would be to simply display the issue under every PR that claims to fix it. This brings up a separate question of what count should we display? Inclusive or exclusive of duplicates?

@IzN432

Multiple fixing one issue: All PRs can be shown under the same issue.
A PR fixing multiple issues: This one is tricky. We also don't want to show the same PR multiple times, as it can give the wrong impression about the number of PRs done by the author. So, perhaps list the issues together and show the PR below all those issues? On the PR card, we can indicate that it also fixes: #..., #....

2. How to handle closed PRs?

If a PR has been closed, we probably don't want to display any issues that it claims to fix under it, so we should probably just ignore closed PRs. This is separate from merged PRs, which we do want to display the fixed issues under.

The default view doesn't show closed PRs. If the user chooses to show closed PRs, no harm showing them under the issue they attempted to fix.

3. How to handle if a PR fixes an issue assigned to another user?

Should we still display the issue under User A's PR if it fixes an issue assigned to User B? I think we should still display it.

This is one anomaly this feature can help users catch. Perhaps we can show the mis-fitting issue in some special way so that it stands out?

4. How should this feature be toggled?

Should it be on at all times? Should we add a button to the filter bar? I think it would be okay to keep it on, since if the user wants to search or sort for a specific issue they can always just filter out PRs.

We can make it configurable but that can also be a done later, as a nice-to-have enhancement.
We should wait until the filter bar is moved to a new location (this route is under consideration right now) where the space is not so premium. In the current filter bar location, there isn't much space to add more configuration options.