Filter out issues that have assignee or linked PR

[ben-grande]

New contributors shouldn't spend time on issues somebody else is currently working on.

---

@andrewdavidwong

I don't think the label pr submitted is required anymore, since linked:pr exists.

I understand there are some cases of a contributor being assigned, submitting a PR and abandoning it, but for the most part, I think that the filter helps. Let's suppose a PR is abandoned, what can be done to make it appear in the filter again?

• Can't remove linked PR from issue
• Can remove the assignee, but the filter is no:assignee -linked:pr, so both conditions needs to match. A bit of a problem as there is a lot of issues with PR submitted that have no assignee, and they aren't for the most part, abandoned

I propose that every issue that has linked:pr to have an assignee, so that I can make the filter: no:assignee -linked:pr become just no:assignee, then we drop assignee when the PR is abandoned.

[andrewdavidwong]

I don't think the label pr submitted is required anymore, since linked:pr exists.

I guess it's only useful (if it's useful at all) in cases in which the person doesn't properly link their PR (for example, just posts a comment with a link to the PR) or when they submit a patch via some non-GitHub method (e.g., email, chat).

A bit of a problem as there is a lot of issues with PR submitted that have no assignee, and they aren't for the most part, abandoned

There are two main reasons for this:

1. If a community member submits a PR but never interacts with the issue, I can't assign them to the issue. (Their name simply doesn't appear in the possible-asignee list and can't be added manually.)
2. The Qubes OS Project has a rule that no one is supposed to assign issues to official team members without permission. In other words, we aren't supposed to assign issues to each other (unless explicitly asked). Instead, we're supposed to assign issues to ourselves. However, in practice, many people don't do this.

I propose that every issue that has linked:pr to have an assignee

This would probably require changing/removing the rule in point 2. However, even if we do that, there would still be the problem that I, at least, often don't know who's working on what until I see a PR from them (and sometimes not even until the issue is closed).

[ben-grande]

2. The Qubes OS Project has a rule that no one is supposed to assign issues to official team members without permission.

I always interpreted this rule differently, but I joined after it came into place. Given that a subject was more known to a specific developer, it would tend to assign it to them. But we are treating "assignee" as someone who is currently working on a subject, so when someone does a PR to it, they are assigned to it.

I propose that every issue that has linked:pr to have an assignee

This would probably require changing/removing the rule in point 2. However, even if we do that, there would still be the problem that I, at least, often don't know who's working on what until I see a PR from them (and sometimes not even until the issue is closed).

But if someone is working on something, and has a linked PR, you can assign it to them (my proposal). Before a PR is made, if nobody says nothing, them I understand it is not possible to assign, but this is something that contributors/developers need to change. The new contributors have been commenting on the issues they plan to work on.

[andrewdavidwong]

But if someone is working on something, and has a linked PR, you can assign it to them (my proposal). Before a PR is made, if nobody says nothing, them I understand it is not possible to assign, but this is something that contributors/developers need to change.

That sounds reasonable to me.

@marmarek, what do you think?

[unman]

I have seen issues where someone as commented on it, submitted a PR, and then another user has taken as different approach, and submitted an alternative PR. Often this is where the comments flow. How will assigning it to one or the other help here?

[marmarek]

But if someone is working on something, and has a linked PR, you can assign it to them (my proposal). Before a PR is made, if nobody says nothing, them I understand it is not possible to assign, but this is something that contributors/developers need to change.

Sounds okay.

I have seen issues where someone as commented on it, submitted a PR, and then another user has taken as different approach, and submitted an alternative PR. Often this is where the comments flow. How will assigning it to one or the other help here?

First, assigning will help to not duplicate the work (another contributor working on issue unaware somebody else work on it already). But if somebody intentionally take a different approach to the same issue, there needs to be a discussion which one is preferable (and here also assigning helps to see there is a need/place for such discussion). The result could be changing the assignment, or even assigning both - if it turns out the alternative approach is actually complementary, not an alternative.

[andrewdavidwong]

I have seen issues where someone as commented on it, submitted a PR, and then another user has taken as different approach, and submitted an alternative PR. Often this is where the comments flow. How will assigning it to one or the other help here?

First, assigning will help to not duplicate the work (another contributor working on issue unaware somebody else work on it already). But if somebody intentionally take a different approach to the same issue, there needs to be a discussion which one is preferable (and here also assigning helps to see there is a need/place for such discussion). The result could be changing the assignment, or even assigning both - if it turns out the alternative approach is actually complementary, not an alternative.

IMHO, we should assign both people in such situations. An assignment on an issue should not be interpreted to mean "this person's work has been approved." Rather, it should mean "this person has claimed to be working on this issue in some way or indicated such through their actions." Review of the work is up to the code reviewers, not the issue tracker managers.

If multiple people choose to work on the same issue and submit competing PRs, it's up to the devs to decide which is better and which should be merged (or that neither is acceptable). Assigning both people to the PR should be more of a mechanical action that basically just means something like "both of these people submitted PRs."