meta: add ability to block issues

[anonrig]

I'm proposing the ability to block an issue from progressing by any collaborator.

cc @nodejs/tsc

[nodejs-github-bot]

Review requested:

• @nodejs/tsc

[juanarbol]

Not a TSC member, but as a "collaborator" +1.

[aduh95]

I'm not sure that's a great change as it's not enforceable by automation. The reason dissent comment are no longer accepted as a valid form of objection was because it was easy to miss / misinterpret, and that change kinda reintroduces it. I wonder if a better rule would be "we should not use issues to discuss new features" or something like that

[ovflowd]

I'm not sure that's a great change as it's not enforceable by automation. The reason dissent comment are no longer accepted as a valid form of objection was because it was easy to miss / misinterpret, and that change kinda reintroduces it. I wonder if a better rule would be "we should not use issues to discuss new features" or something like that

I concur — and for full transparency (as the author of the changes that bypassed your 👎), I proposed and merged that PR because I completely forgot there had been a block raised earlier. Honestly, the block on the issue happened weeks ago, and by the time we had the meeting with the Foundation, I only remembered my own concerns. So that's on me.

But this really backs up what @aduh95 said — if something isn’t enforceable by automation, it’s super easy to bypass it by accident. (Just to be clear, I genuinely didn’t mean to ignore your 👎!)

[juanarbol]

"we should not use issues to discuss new features"

GitHub activity is a bit hard to keep track. Some issues are labeled as "feature request", do you have any specific in mind?

[anonrig]

I'm not sure that's a great change as it's not enforceable by automation. The reason dissent comment are no longer accepted as a valid form of objection was because it was easy to miss / misinterpret, and that change kinda reintroduces it. I wonder if a better rule would be "we should not use issues to discuss new features" or something like that

We can easily ask the collaborator to add a "blocked" label and make this enforceable by automation.

[jasnell]

I agree that this change is not ideal. For one, a change can be discussed in many issues. It's untenable to keep track of every issue. Our actual approval process is based on review of the actual PRs in which the changes are made. Those PRs are the source of truth and where blocks should be explicitly placed. Otherwise it becomes too easy to game, e.g., "I mentioned in some random comment in some random issue discussing the possibility of making this change and said it was a bad idea, therefore this shouldn't ever land" is not a healthy approach.

[jasnell]

The wording here is problematic. We cannot block anything from being implemented. We block PRs from being merged. None of us have the right or ability to block anyone from implementing anything.

[jasnell]

This part is already covered adequately elsewhere in the guidelines.

[jasnell]

we should not use issues to discuss new features

This would be equally untenable. Feature requests, bugs, tracking issues, etc all focus on using issues to discuss and track potential changes, including new features. We should not handicap our own processes -- that have worked well for well over a decade -- as a knee jerk reaction to a single incident that largely comes down to a simple miscommunication and misunderstanding.

[BridgeAR]

I believe having a more lenient process is better in this case. We can express our concerns and raise the topic to the TSC. If we agree on not doing something, let's just close the issue as won't implement. Of course someone could still open a PR and it could be landed in case the reviewers have different oppinions at that time.

[mcollina]

This has two problems:

1. the technical aspect - GitHub folds comments. It's really hard to track who objected to the issue.
2. the community aspect - imagine a situation where a 3rd party open an issue, and then see a bunch of -1 from collaborators.

I can't see how this would work in a generic/scalable way, but on a smaller setting (like the TSC repo) could be viable.