I don't think the current contribution guide is exclusively about code, though. For example, the main repository has a doc/ folder, and there are files like src/cmd/compile/README.md which serve as technical documentation.

I think it's fair to highlight how to contribute documentation, but we should also be clear about where each kind of documentation lives.

This proposal seems like it has a good idea in it, but without concrete detail about what would happen it's hard to evaluate. In this sense it's a little like #32741. It seems like maybe we should close in the absence of a more concrete plan.

"How you can help" could be changed to include "Contributing code and documentation". That would be easy to do.

One concern is that technical writers may not be well versed with git. The current guidelines are very oriented towards developers, with initial steps using the command line to install a git plugin. I don't think there is a way around that though, because even if GitHub's tools are used ("Fork this project and edit this file") to submit the initial pull request, any followup changes would require Gerrit, correct?

The other concern is that we don't have any sort of style guide for documentation. I don't have anything concrete for that though.

@toothrot Anything else to add?

I'm not entirely convinced that the processes are too different. We review many documentation, tour, and example CLs today that have little or no code in them.

Is the proposal that they should be different and we should have some easier process for non-code contributions? If so, what? We already accept GitHub PRs these days at least, which made the process more familiar to a much larger audience.

Or is the proposal to add a grammar/English style guide? That would also be nice.

I sent a CL to change "Contributing code" to "Contributing code and documentation" though.

Change https://golang.org/cl/202823 mentions this issue: doc: clarify that contributing isn't just for code

I'm not 100% sure what this issue means to be about.
If the claim is that there should be a different process for documentation vs code, that's not our intent. We intend to use the same review for everything, as Brad documented in CL 202823.
(That is, we're not going to add a separate process specific to documentation or examples.)

Are there other concrete changes we should make for this issue, or should we close it now?

Will leave open for a week for final comments and otherwise close as done.

Closing as done.

Thanks