Check for an existing pull request before executing a privileged watch or blacklist

[gparyani]

Often, upon reporting a particular spam post as a true positive, I submit a request for a watch or blacklist entry. As I'm a non-privileged user, the request is filed as a pull request which must be approved by another user with privileges before being merged.

However, it often happens that someone with privileges also submits a request for the same watch or blacklist entry after I have already submitted mine. This is a common occurrence for me since I participate in Charcoal through Tavern on the Meta, and there is no indication in Charcoal HQ that a pull request has been filed if the original request was made in a different room (Tavern or SOCVR). As their request is incorporated into the respective list immediately, it creates a merge conflict with my non-privileged pull request. This creates extra work for users as they then have to procedurally decline those unnecessary pull requests.

Can we make SmokeDetector, upon receiving a privileged request for a watch or blacklist entry, check for an existing pull request requesting the same thing, and if so, not immediately incorporate the entry into the list and prompt the user to instead approve the existing request?

[tripleee]

I'm not against this, but at the current load level, it seems like more work than just closing a few expired PRs occasionally.

I do acknowledge that having your PR rejected may feel bad, especially if you were way ahead of whoever came up with the same idea later and just pushed it through.

_{Sent with GitHawk}

[gparyani]

@tripleee It can create a weaker case for granting privileges if the checking admin doesn't go in and check every single request, as it makes it seem like a higher number of their non-privileged requests were declined, even though many of them were just procedural declines since another privileged user added the exact same entry to the list.

[tripleee]

Again, if the volumes were larger, that would be a problem; but for better or for worse, we are not yet operating on that scale. (As a matter of fact I recently assessed around 80 old PRs manually; total time spent maybe 15 minutes.)

_{Sent with GitHawk}

[iBug]

What if the other way round: Every PR created outside CHQ generates a message so regulars are informed of its existence - an easy way for a decent solution of the actual problem.

[gparyani]

@iBug If that were the case, I'd argue that it should be even broader: post a CHQ message for every PR created, not only using the commands in a different room but also manual requests created through other means, and also for issues.

[tripleee]

Getting a ping when a Github issue is filed would actually be pretty nice. I have been doing that manually from time to time when I created an issue.

[gparyani]

I consider the gist of this issue resolved now that the above change has been made to metasmoke.

[makyen]

While I agree that there's been work done that makes this a lower priority, the request in the initial comment doesn't appear to be complete and I don't see agreement that this shouldn't be implemented. As far as I'm aware, it's still a desired feature.