Lack of reliable feedback channel for PRs

[zeuner]

Describe the bug

When PR is filed against a package, committers are expected to wait at least a week for maintainer feedback (
https://github.com/NixOS/nixpkgs/blob/master/maintainers/README.md?plain=1#L20). However, it turns out that GitHub cannot or does not ensure that maintainers can always reliably comment on the PR. There are configurations where even with access to a GitHub account, commenting on a PR is technically blocked. As far as I'm informed, this can even be configured by the PR author, so there is even the danger of users purposefully creating a PR that does not accept feedback by maintainers of affected packages.

Steps To Reproduce

Steps to reproduce the behavior:

1. File a PR affecting a package
2. Use GitHub's facilities to prevent comments by maintainers
3. After one week, merge the PR according to the guidelines for maintainer involvement

Expected behavior

Maintainers are always given a possibility to provide community-visible feedback on PRs affecting packages they maintain, possibly through additional channels (e.g. from their linked mail or matrix accounts).

Screenshots

An example of a PR with unreliable commenting facilities:

Additional context

This might be due to an incompatibility between GitHub's access controls and the nixpkgs-defined maintainer responsibilities.

Metadata

Not applicable since it's a GitHub platform issue that is expected to apply independently from the local nixpkgs setup.

Notify maintainers

@zimbatm @7c6f434c @fricklerhandwerk @FRidh

---

Note for maintainers: Please tag this issue in your PR.

---

Add a 👍 reaction to issues you find important.

[FliegendeWurst]

Use GitHub's facilities to prevent comments by maintainers

I think this only happens if the PR author blocked you. (Or the PR was locked and closed due to mass ping)

[7c6f434c]

I wonder whether GitHub actions (for evaluation, see #355847 ) can easily add a comment if the author has blocked any of the maintainers that would be review-requested.

[zimbatm]

The issue is that @zeuner's maintainer is missing the github and githubId fields. So ofborg and other tools are unable to make the association and tag him.

That's what these fields are for @zeuner.

The last time somebody tried to fix that association, zeuner threatened to sue the NixOS Foundation over GDPR violation. It might have been a heat of the argument type of thing, but please be careful before posting any links and let zeuner decide what they want to do.

[zeuner]

The issue is that @zeuner's maintainer is missing the github and githubId fields. So ofborg and other tools are unable to make the association and tag him.

That's what these fields are for @zeuner.

The last time somebody tried to fix that association, zeuner threatened to sue the NixOS Foundation over GDPR violation. It might have been a heat of the argument type of thing, but please be careful before posting any links and let zeuner decide what they want to do.

@zimbatm

Let's keep this discussion on-topic. Apart from misrepresenting the actual facts (maybe a misunderstanding, obviously something better discussed privately), what you write doesn't seem to have much to do with the issue at hand: The lack of a reliable mechanism that ensures maintainers can always provide feedback on PRs that touch packages they maintain.

[zeuner]

Use GitHub's facilities to prevent comments by maintainers

I think this only happens if the PR author blocked you. (Or the PR was locked and closed due to mass ping)

This seems to confirm what I wrote above: The PR author having control over maintainers' ability to comment.

The problem might be that the blocking mechanism serves a different purpose, which might be incompatible with what expected from committers and maintainers. Users usually would block someone with whom they don't want to communicate. This is fine, but it collides with the nixpkgs community spirit at least at the point where the user still files PRs that touch packages maintained by those with whom they do not want to communicate with.

[zeuner]

Use GitHub's facilities to prevent comments by maintainers

I think this only happens if the PR author blocked you. (Or the PR was locked and closed due to mass ping)

This seems to confirm what I wrote above: The PR author having control over maintainers' ability to comment.

The problem might be that the blocking mechanism serves a different purpose, which might be incompatible with what expected from committers and maintainers. Users usually would block someone with whom they don't want to communicate. This is fine, but it collides with the nixpkgs community spirit at least at the point where the user still files PRs that touch packages maintained by those with whom they do not want to communicate with.

[zeuner]

I wonder whether GitHub actions (for evaluation, see #355847 ) can easily add a comment if the author has blocked any of the maintainers that would be review-requested.

If we solve this through automatism, maybe it can even be done in a more generic way, not depending on maintainer GitHub accounts. Like: A bot account writes a comment when the one week feedback period is over. This comment is only posted if no maintainer GitHub account was blocked within that week (not sure whether this is possible to determine, though). The bot account could also react to a procmail and/or matrix-commander component to forward review comments received over other communication channels registered by maintainers.

[piegamesde]

If GitHub block information was publicly available that'd be quite a safety issue, therefore I doubt that anything can be done about this with CI or automation.

there is even the danger of users purposefully creating a PR that does not accept feedback by maintainers of affected packages.

I highly doubt anybody actually would do this, and if it happened it would a very clear case for the moderation team. So let's put any bad-faith scenarios aside.

[eclairevoyant]

I highly doubt anybody actually would do this

It could be done accidentally if the PR author didn't check the maintainer list beforehand, so having a side-channel to provide PR feedback (irrespective of blocking) may still be useful. (If, indeed, the cause is user-blocking one of the maintainers.)

Though, I suppose there already is a side-channel option - create a discourse thread and point it at the PR. Is that workable?