|author||Russ Cox <firstname.lastname@example.org>||Wed Jun 28 10:36:55 2017 -0400|
|committer||Brad Fitzpatrick <email@example.com>||Wed Jun 28 15:39:41 2017 +0000|
design/12914-monotonic: fix example in comment t.Sub(u) would be -20 milliseconds. The right computation is u.Sub(t), but rewrite to be even clearer. Thanks to Karsten Weiss for catching this. Change-Id: I5c87ce3bbaa9a05402b0534e6ed2474848062c2a Reviewed-on: https://go-review.googlesource.com/46970 Run-TryBot: Russ Cox <firstname.lastname@example.org> TryBot-Result: Gobot Gobot <email@example.com> Reviewed-by: Brad Fitzpatrick <firstname.lastname@example.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.
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:
NNNNis the GitHub issue number and
shortnameis a short name (a few dash-separated words at most). Clone this repository with
git clone https://go.googlesource.com/proposaland 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:
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.)
To learn about contributing to Go in general, see the contribution guidelines.