I'd much much rather we keep the code of conduct very simple and short.

Okay! Should this be in the Tree Hygiene page instead?

Specifically, we don't need to say anything about brigading, since that's already a multiple-count violation of the code of conduct (it's not professional, it's not respectful, it's not dignified, it doesn't respect people's work, it's not kind, it's not courteous, and when it happens people are not listening and acknowledging people's points before responding).

If we wanted to add "brigading is a multiple-count violation of the code of conduct (it's not professional, it's not respectful, it's not dignified, it doesn't respect people's work, it's not kind, it's not courteous, etc)." to the tree hygiene doc or issue hygiene doc I guess that'd be fine. I doubt it's going to do much good though. Nobody is going to read it before brigading and we don't need to point to anything if someone is asking a PR to be spammed, just close the PR with "this PR is being brigaded, which is unprofessional. I've closed this PR for now." if it's not a PR you wanted to land, and if it's a PR you do want to land just lock it to collaborators.

Specifically, we don't need to say anything about brigading, since that's already a multiple-count violation of the code of conduct (it's not professional, it's not respectful, it's not dignified, it doesn't respect people's work, it's not kind, it's not courteous, and when it happens people are not listening and acknowledging people's points before responding).

I wasn't thinking we should single out brigading, but that we should have a PR equivalent of https://github.com/flutter/flutter/blob/master/docs/contributing/issue_hygiene/README.md#do-not-add-me-too-or-same-or-is-there-an-update-comments-to-bugs. Brigading is obviously bad, but people sometimes leave non-brigading versions of the same kind of comments that the brigading PR had (e.g. "Please land this PR, I need it for my project." is the sort of thing I have seen people write in non-abusive contexts), and they are just as unhelpful on PRs as they are on issues. It seemed odd that we didn't say anywhere not to do that.

Maybe it could just be:

Do not add "me too" or "same" or "is there an update" comments to bugs

Since PRs are usually required to link an issue, I think it makes sense to defer to an issue hygiene rule if a similar situation arises in a pull request.

Edit:

Bugs includes known defects, as well as feature requests, planned work, and proposals.

Perhaps no change is necessary (but it would make sense to add something specifically for PRs if this is something that comes up pretty often).

Yeah changing "bugs" to "Issues and PRs" seems harmless.

That text exists just so our GitHub banner can point to it, but honestly it doesn't seem to have had much effect, largely I expect because of the problem I mentioned earlier — the people we are trying to reach don't read. Issues get tons of "any updates" comments.

honestly it doesn't seem to have had much effect, largely I expect because of the problem I mentioned earlier — the people we are trying to reach don't read. Issues get tons of "any updates" comments.

FWIW I think that text has one valuable purpose even if it has no effect on our rate of "any updates" comments. (And I suspect it does have some effect — as many as we get, it feels like less than in some other very popular GitHub repos — but it's hard to know.)

That's that it backs people up when they intervene to collapse those comments. By making a clear statement of policy, it makes it a lot easier to feel confident one is doing the right thing, and the locally-socially-accepted thing, by collapsing them. That leads to more of those comments being collapsed. And at least for me, I find that the systematic collapsing of noise comments makes a noisy issue thread in this tracker a lot more pleasant to read than a comparably noisy issue thread most anywhere else on GitHub, including the Dart trackers.

(The for-real code of conduct is an important contributor there too. But, for my own experience (and I'm sure others' experience is different): I think the approach to mere noise actually makes a bigger difference than the handling of more egregious bad behavior, because it's so much more pervasive.)

Totally.

I'm not sure if it's worth it to look into Google Testing errors for a change as tiny as this one.

I'll plan on closing in a week from now if nothing seems to improve.

Google testing was bundling this change with another PR that was causing the failures. I marked the check as skipped since this doc only change is pretty low risk. Should submit now.