project: document what the Go project wants from code review

[ianlancetaylor]

Pulled out of #21956 comment by @andybons at #21956 (comment) .

• Draft a feature comparison between Gerrit and GitHub with input from golang-dev@ as to what features are keeping the project off of GitHub for Code Review.
• Present a proposal that addresses the concerns raised by the members of the development team where you explain how these issues will be solved either by presenting a (very) convincing argument that they don’t really matter, or proposing changes to existing tooling. Concrete data also helps you in this case. Rallying for GitHub to implement features is also not out of the question.
• Outline who will do the work and what the timeline is. If it’s the Go team at Google, explaining why it’s more important than the many other things on our plate is part of the process.

Other actions not related to moving to GitHub:

• File bugs to improve documentation in cases where you feel it’s confusing or lacking.
• If you can, submit patches to make the documentation or tooling better.

[martisch]

I think isolation of actions with permissions is also good to address in requirements documentation of the review/submit management system.
e.g. currently being able to gardening/triaging issues on github does not also grant submit/+2 rights automatically (currently in Gerrit) and being able to e.g. close issues should i think ideally not allowing to delete a branch in the source of truth repository.

[ianlancetaylor]

Now that we have https://github.com/golang/go/wiki/GerritBot, this issue doesn't seem particularly interesting. Closing it out.