| commit | 0d84ea98d61e34b542b0e5b824220a15b7ca61f5 | [log] [tgz] |
|---|---|---|
| author | Robert Griesemer <gri@golang.org> | Fri Aug 12 15:17:44 2016 -0700 |
| committer | Robert Griesemer <gri@golang.org> | Fri Aug 12 22:19:30 2016 +0000 |
| tree | 90ed7368d8dd5d56bd9a384607ff4200ea961522 | |
| parent | 26619f99328117ed67386b41a858cf783961b70a [diff] |
design/16339-alias-decls.md: fix minor typo Change-Id: I865aa0622fc503653e1c84e6db8c1ed19c23005f Reviewed-on: https://go-review.googlesource.com/26970 Reviewed-by: Robert Griesemer <gri@golang.org>
The Go project's development process is design-driven. Significant changes to the language, libraries, or tools must be first discussed, and sometimes formally documented, before they can be implemented.
This document describes the process for proposing, documenting, and implementing changes to the Go project.
To learn more about Go's origins and development process, see the talks How Go Was Made, The Evolution of Go, and Go, Open Source, Community from GopherCon 2015.
The proposal process should be used for any notable change or addition to the language, libraries and tools. Since proposals begin (and will often end) with the filing of an issue, even small changes can go through the proposal process if appropriate. Deciding what is appropriate is matter of judgment we will refine through experience. If in doubt, file a proposal.
Programs written for Go version 1.x must continue to compile and work with future versions of Go 1. The Go 1 compatibility document describes the promise we have made to Go users for the future of Go 1.x. Any proposed change must not break this promise.
Go is a mature language and, as such, significant language changes are unlikely to be accepted. A “language change” in this context means a change to the Go language specification. (See the release notes for examples of recent language changes.)
Create an issue describing the proposal.
Like any GitHub issue, a Proposal issue is followed by an initial discussion about the suggestion. For Proposal issues:
It's always fine to label a suggestion issue with Proposal to opt in to this process.
It's always fine not to label a suggestion issue with Proposal. (If the suggestion needs a design doc or is declined but worth remembering, it is trivial to add the label later.)
If a Proposal issue leads to a design doc:
design/NNNN-shortname.md, where NNNN is the GitHub issue number and shortname is a short name (a few dash-separated words at most). Clone this repository with git clone https://go.googlesource.com/proposal and follow the usual Gerrit workflow for Go.Once comments and revisions on the design doc wind down, there is a final discussion about the proposal.
The author (and/or other contributors) do the work as described by the “Implementation” section of the proposal.
If you're already familiar with writing design docs for the Go project, the process has not changed much. The main thing that has changed is where the proposal is published.
In the situation where you'd write and circulate a design doc as a Google doc before, now you:
design/NNNN-shortname.md.Worst case, by bypassing the initial discussion you've possibly written an unnecessary design doc. Not a big deal.
If you need help with this process, please contact the Go contributors by posting to the golang-dev mailing list. (Note that the list is moderated, and that first-time posters should expect a delay while their message is held for moderation.)
If you want to talk to someone off-list, contact Andrew Gerrand at adg@golang.org.
To learn about contributing to Go in general, see the contribution guidelines.