I'd rather gopherbot stopped automatically adding reviewers to my CLs.
I appreciate the intent, and I think it's a great idea for people who are new to contributing to Go. But I'm comfortable using Gerrit and finding reviewers, and I don't want my reviewers confused because Gopherbot asked them to look at my CLs out of order.
One workaround is to use git mail -r mdempsky. Or whichever reviewers you want to specify.
CC @andybons
One workaround is to use git mail -r mdempsky.
To clarify, the workaround you're suggesting here is to use the -r flag to specify reviewers at upload time, or to add myself as the reviewer specifically? (I only use git-codereview for the commit hooks; I'm not familiar with its workflow for uploading patches.)
Or whichever reviewers you want to specify.
I usually prefer to wait until I've confirmed that my CL passes trybots before sending them to reviewers.
Also, part of the problem is when I upload a patch series, I want to mail out the patches in order and at a pace that I feel confident my reviewers can keep up with. I don't want to mail them all out right away.
I usually prefer to wait until I've confirmed that my CL passes trybots before sending them to reviewers.
Have you considered marking the CL as a WIP until it's ready for review? I don't think git-codereview mail has such a flag, but we could add it. That would also clearly signal to humans that you're still testing.
At the moment with gerrit if you mark a change WIP, you can't kick off the trybots (instead of the usual "reply" button you get a "start review" button). Example:

@mvdan @thanm: note that GopherBot already understands DO NOT REVIEW in commit messages, and should not assign reviewers to a change whose commit message includes that string.
Stepping back, are we actually getting value out of the auto-assignment of CLs?
@andybons I do think there's some value in making sure that CLs don't go unnoticed in between all the activity. But that only applies to CLs that go unnoticed to begin with. Maybe gopherbot could simply wait 48h to assign reviewers if there are none; that's plenty of time for an author to run the tests, or assign reviewers, or whatever they decide to do.
@mvdan assigning after 48hrs automatically could create confusion (do we add messaging for every change letting people know? Only to new contributors?).
I'd rather us move to a pull model where one could find owners via a Gerrit UI plugin and assign themselves. It would be straightforward to implement as dev.golang.org/owners supports CORS requests.
I do think it's important that the bot give contributors _some_ idea of how to proceed with their CL and when to expect that it will be reviewed. (I know I'm pretty terrible at keeping up with cmd/go reviews.)
I don't feel strongly about whether that should take the form of auto-assignment or a nudge toward some self-service page or tool.
What about instead removing it for all google.com and golang.org users?
(to slightly amend Brad's idea, I think using the approvers list would be slightly better, so that non-googlers can also benefit)
Oh, what @mvdan says would be even better.
Change https://golang.org/cl/196138 mentions this issue: cmd/gopherbot: add opt-out from automatic reviewers
Opting-out for all approvers sounds reasonable to me. I just didn't want to be presumptive about whether others feel the same as I do about Gopherbot automatically adding reviewers to my CLs. (E.g., I know that as someone who pushes CLs directly to Gerrit using git push rather than any git-codereview-based workflow already makes me an atypical go-review.googlesource.com user.)
Most helpful comment
(to slightly amend Brad's idea, I think using the approvers list would be slightly better, so that non-googlers can also benefit)