{"id":13467767,"url":"https://github.com/golang/proposal","last_synced_at":"2025-05-13T21:06:00.839Z","repository":{"id":35601425,"uuid":"39874513","full_name":"golang/proposal","owner":"golang","description":"Go Project Design Documents","archived":false,"fork":false,"pushed_at":"2025-02-27T21:09:20.000Z","size":6996,"stargazers_count":3396,"open_issues_count":4,"forks_count":396,"subscribers_count":350,"default_branch":"master","last_synced_at":"2025-04-28T12:12:46.454Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"HTML","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"bsd-3-clause","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/golang.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":"CONTRIBUTING.md","funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2015-07-29T05:09:38.000Z","updated_at":"2025-04-27T16:24:39.000Z","dependencies_parsed_at":"2024-08-28T00:28:30.376Z","dependency_job_id":"f196a4a4-bb5b-4bc6-95f5-1902e964c898","html_url":"https://github.com/golang/proposal","commit_stats":{"total_commits":392,"total_committers":77,"mean_commits":5.090909090909091,"dds":0.8520408163265306,"last_synced_commit":"d79dc87fa59e4b8614b56e57b84b4cb391bcc8f7"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/golang%2Fproposal","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/golang%2Fproposal/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/golang%2Fproposal/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/golang%2Fproposal/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/golang","download_url":"https://codeload.github.com/golang/proposal/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":251311332,"owners_count":21569009,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2024-07-31T15:01:00.293Z","updated_at":"2025-04-28T12:12:52.910Z","avatar_url":"https://github.com/golang.png","language":"HTML","funding_links":[],"categories":["Shell","HTML","文档","Documentation","Go","Programming Languages"],"sub_categories":["组织","To Organize"],"readme":"# Proposing Changes to Go\n\n## Introduction\n\nThe Go project's development process is design-driven.\nSignificant changes to the language, libraries, or tools\n(which includes API changes in the main repo and all golang.org/x repos,\nas well as command-line changes to the `go` command)\nmust be first discussed, and sometimes formally documented,\nbefore they can be implemented.\n\nThis document describes the process for proposing, documenting, and\nimplementing changes to the Go project.\n\nTo learn more about Go's origins and development process, see the talks\n[How Go Was Made](https://go.dev/talks/2015/how-go-was-made.slide),\n[The Evolution of Go](https://go.dev/talks/2015/gophercon-goevolution.slide),\nand [Go, Open Source, Community](https://go.dev/blog/open-source)\nfrom GopherCon 2015.\n\n## The Proposal Process\n\nThe proposal process is the process for reviewing a proposal and reaching\na decision about whether to accept or decline the proposal.\n\n1. The proposal author [creates a brief issue](https://go.dev/issue/new) describing the proposal.\\\n   Note: There is no need for a design document at this point.\\\n   Note: A non-proposal issue can be turned into a proposal by simply adding the proposal label.\\\n   Note: [Language changes](#language-changes) should follow a separate [template](go2-language-changes.md)\n\n2. A discussion on the issue tracker aims to triage the proposal into one of three outcomes:\n     - Accept proposal, or\n     - decline proposal, or\n     - ask for a design doc.\n\n   If the proposal is accepted or declined, the process is done.\n   Otherwise the discussion is expected to identify concerns that\n   should be addressed in a more detailed design.\n\n3. The proposal author writes a [design doc](#design-documents) to work out details of the proposed\n   design and address the concerns raised in the initial discussion.\n\n4. Once comments and revisions on the design doc wind down, there is a final\n   discussion on the issue, to reach one of two outcomes:\n    - Accept proposal or\n    - decline proposal.\n\nAfter the proposal is accepted or declined (whether after step 2 or step 4),\nimplementation work proceeds in the same way as any other contribution.\n\n## Detail\n\n### Goals\n\n- Make sure that proposals get a proper, fair, timely, recorded evaluation with\n  a clear answer.\n- Make past proposals easy to find, to avoid duplicated effort.\n- If a design doc is needed, make sure contributors know how to write a good one.\n\n### Definitions\n\n- A **proposal** is a suggestion filed as a GitHub issue, identified by having\n  the Proposal label.\n- A **design doc** is the expanded form of a proposal, written when the\n  proposal needs more careful explanation and consideration.\n\n### Scope\n\nThe proposal process should be used for any notable change or addition to the\nlanguage, libraries and tools.\n“Notable” includes (but is not limited to):\n\n- API changes in the main repo and all golang.org/x repos.\n- Command-line changes to the `go` command.\n- Any visible behavior changes that need a [GODEBUG setting](https://go.dev/doc/godebug) for compatibility.\n- Any other visible behavior changes in existing functionality.\n- Adoption or use of new protocols, protocol versions, cryptographic algorithms, and the like,\n  even in an implementation.\n  Such changes are externally visible and require discussion and probably a GODEBUG setting.\n\nSince proposals begin (and will often end) with the filing of an issue, even\nsmall changes can go through the proposal process if appropriate.\nDeciding what is appropriate is matter of judgment we will refine through\nexperience.\nIf in doubt, file a proposal.\n\nThere is a short list of changes that are typically not in scope for the proposal process:\n\n- Making API changes in internal packages, since those APIs are not publicly visible.\n- Making API or command-line changes in golang.org/x/build, since that is code to run the Go project, not for users to import and depend on.\n- Adding new system call numbers or direct system call wrappers (`//sys` lines) in golang.org/x/sys.\n- Adding new C-equivalent data structures to support those system calls.\n\nAgain, if in doubt, file a proposal.\n\n### Compatibility\n\nPrograms written for Go version 1.x must continue to compile and work with\nfuture versions of Go 1.\nThe [Go 1 compatibility document](https://go.dev/doc/go1compat) describes\nthe promise we have made to Go users for the future of Go 1.x.\nAny proposed change must not break this promise.\n\n### Language changes\n\nIn 2018 we started a Go 2 process during which we may change the\nlanguage, as described on [the Go\nblog](https://go.dev/blog/go2-here-we-come).\nLanguage changes should follow the proposal process described here.\nAs explained in the blog entry, language change proposals should\n\n- address an important issue for many people,\n- have minimal impact on everybody else, and\n- come with a clear and well-understood solution.\n\nProposals should follow the [Go 2 template](go2-language-changes.md).\nSee the [Go 2 review minutes](https://go.dev/issue/33892)\nand the [release notes](https://go.dev/doc/devel/release) for\nexamples of recent language changes.\n\n### Design Documents\n\nAs noted above, some (but not all) proposals need to be elaborated in a design document.\n\n- The design doc should be checked in to [the proposal repository](https://github.com/golang/proposal/) as `design/NNNN-shortname.md`,\nwhere `NNNN` is the GitHub issue number and `shortname` is a short name\n(a few dash-separated words at most).\nClone this repository with `git clone https://go.googlesource.com/proposal`\nand follow the usual [Gerrit workflow for Go](https://go.dev/doc/contribute#review).\n\n- The design doc should follow [the template](design/TEMPLATE.md).\n\n- The design doc should address any specific concerns raised during the initial discussion.\n\n- It is expected that the design doc may go through multiple checked-in revisions.\nNew design doc authors may be paired with a design doc \"shepherd\" to help work on the doc.\n\n- For ease of review with Gerrit, design documents should be wrapped around the\n80 column mark.\n[Each sentence should start on a new line](https://rhodesmill.org/brandon/2012/one-sentence-per-line/)\nso that comments can be made accurately and the diff kept shorter.\n  - In Emacs, loading `fill.el` from this directory will make `fill-paragraph` format text this way.\n\n- Comments on Gerrit CLs should be restricted to grammar, spelling,\nor procedural errors related to the preparation of the proposal itself.\nAll other comments should be addressed to the related GitHub issue.\n\n\n### Quick Start for Experienced Committers\n\nExperienced committers who are certain that a design doc will be\nrequired for a particular proposal\ncan skip steps 1 and 2 and include the design doc with the initial issue.\n\nIn the worst case, skipping these steps only leads to an unnecessary design doc.\n\n### Proposal Review\n\nA group of Go team members holds “proposal review meetings”\napproximately weekly to review pending proposals.\n\nThe principal goal of the review meeting is to make sure that proposals\nare receiving attention from the right people,\nby cc'ing relevant developers, raising important questions,\npinging lapsed discussions, and generally trying to guide discussion\ntoward agreement about the outcome.\nThe discussion itself is expected to happen on the issue tracker,\nso that anyone can take part.\n\nThe proposal review meetings also identify issues where\nconsensus has been reached and the process can be\nadvanced to the next step (by marking the proposal accepted\nor declined or by asking for a design doc).\n\nMinutes are posted to [go.dev/s/proposal-minutes](https://go.dev/s/proposal-minutes)\nafter the conclusion of the weekly meeting, so that anyone\ninterested in which proposals are under active consideration\ncan follow that issue.\n\nProposal issues are tracked in the\n[Proposals project](https://github.com/orgs/golang/projects/17) on the Go issue tracker.\nThe current state of the proposal is captured by the columns in that project,\nas described below.\n\nThe proposal review group can, at their discretion, make exceptions for\nproposals that need not go through all the stages, fast-tracking them\nto Likely Accept/Likely Decline or even Accept/Decline, such as for\nproposals that do not merit the full review or that need to be considered\nquickly due to pending releases.\n\n#### Incoming\n\nNew proposals are added to the Incoming column.\n\nThe weekly proposal review meetings aim to look at all the issues\nin the Active, Likely Accept, and Likely Decline columns.\nIf time is left over, then proposals from Incoming are selected\nto be moved to Active.\n\nHolding proposals in Incoming until attention can be devoted to them\n(at which they move to Active, and then onward) ensures that\nprogress is made moving active proposals out to Accepted or Declined,\nso we avoid [receive livelock](https://www.news.cs.nyu.edu/~jinyang/sp09/readings/mogul96usenix.pdf),\nin which accepting new work prevents finishing old work.\n\n#### Active\n\nIssues in the Active column are reviewed at each weekly proposal meeting\nto watch for emerging consensus in the discussions.\nThe proposal review group may also comment, make suggestions,\nask clarifying questions, and try to restate the proposals to make sure\neveryone agrees about what exactly is being discussed.\n\n#### Likely Accept\n\nIf an issue discussion seems to have reached\na consensus to accept the proposal, the proposal review group\nmoves the issue to the Likely Accept column\nand posts a comment noting that change.\nThis marks the final period for comments that might\nchange the recognition of consensus.\n\n#### Likely Decline\n\nIf a proposal discussion seems to have reached\na consensus to decline the proposal, the proposal review group\nmoves the issue to the Likely Decline column.\nAn issue may also be moved to Likely Decline if the\nproposal review group identifies that no consensus\nis likely to be reached and that the default of not accepting\nthe proposal is appropriate.\n\nJust as for Likely Accept, the group posts a comment noting the change,\nand this marks the final period for comments that might\nchange the recognition of consensus.\n\n#### Accepted\n\nA week after a proposal moves to Likely Accept, absent a change in consensus,\nthe proposal review group moves the proposal to the Accepted column.\nIf significant discussion happens during that week,\nthe proposal review group may leave the proposal\nin Likely Accept for another week or even move the proposal back to Active.\n\nOnce a proposal is marked Accepted, the Proposal-Accepted label is applied,\nit is moved out of the Proposal milestone into a work milestone,\nand the issue is repurposed to track the work of implementing the proposal.\n\nThe default work milestone is Backlog, indicating\nthat the work applies to the Go release itself but is not slated for a particular release.\nAnother common next milestone is Unreleased, used for work that is not part\nof any Go release (for example, work in parts of golang.org/x that are not vendored\ninto the standard releases).\n\n#### Declined\n\nA week after a proposal moves to Likely Decline, absent a change in consensus,\nthe proposal review group moves the proposal to the Declined column.\nIf significant discussion happens during that week,\nthe proposal review group may leave the proposal\nin Likely Decline for another week or even move the proposal back to Active.\nOnce a proposal is marked Declined, it is closed.\n\n#### Declined as Duplicate\n\nIf a proposal duplicates a previously decided proposal,\nthe proposal review group may decline the proposal as a duplicate\nwithout progressing through the Active or Likely Decline stages.\n\nGenerally speaking, our approach to reconsidering previously decided proposals\nfollows John Ousterhout's advice in his post\n“[Open Decision-Making](https://web.stanford.edu/~ouster/cgi-bin/decisions.php),”\nin particular the “Reconsideration” section.\n\n#### Declined as Infeasible\n\nIf a proposal directly contradicts the core design of the language or of a package,\nor if a proposal is impossible to implement efficiently or at all,\nthe proposal review group may decline the proposal as infeasible\nwithout progressing through the Active or Likely Decline stages.\n\nIf it seems like there is still general interest from others,\nor that discussion may lead to a feasible proposal,\nthe proposal may also be kept open and the discussion continued.\n\n#### Declined as Retracted\n\nIf a proposal is closed or retracted in a comment by the original author,\nthe proposal review group may decline the proposal as retracted\nwithout progressing through the Active or Likely Decline stages.\n\nIf it seems like there is still general interest from others, the proposal\nmay also be kept open and the discussion continued.\n\n#### Declined as Obsolete\n\nIf a proposal is obsoleted by changes to Go that have been made\nsince the proposal was filed, the proposal review group may decline\nthe proposal as obsolete without progressing through the Active or\nLikely Decline stages.\n\nIf it seems like there is still general interest from others,\nor that discussion may lead to a different, non-obsolete proposal,\nthe proposal may also be kept open and the discussion continued.\n\n#### Hold\n\nIf discussion of a proposal requires design revisions or additional information\nthat will not be available for a couple weeks or more, the proposal review group\nmoves the proposal to the Hold column with a note of what it is waiting on.\nOnce that thing is ready, anyone who can edit the issue tracker can move the\nproposal back to the Active column for consideration at the next proposal review meeting.\n\n### Consensus and Disagreement\n\nThe goal of the proposal process is to reach general consensus about the outcome\nin a timely manner.\n\nIf proposal review cannot identify a general consensus\nin the discussion of the issue on the issue tracker,\nthe usual result is that the proposal is declined.\nIt can happen that proposal review may not identify a\ngeneral consensus and yet it is clear that the proposal\nshould not be outright declined.\nAs one example, there may be a consensus that some solution\nto a problem is important, but no consensus on which of\ntwo competing solutions should be adopted.\n\nIf the proposal review group cannot identify a consensus\nnor a next step for the proposal, the decision about the path forward\npasses to the Go architects (currently [gri@](mailto:gri@golang.org),\n[iant@](mailto:iant@golang.org), and [rsc@](mailto:rsc@golang.org)),\nwho review the discussion and aim to reach a consensus among themselves.\nIf so, they document the decision and its rationale on the issue.\n\nIf consensus among the architects cannot be reached,\nwhich is even more unusual,\nthe arbiter (currently [rsc@](mailto:rsc@golang.org))\nreviews the discussion and decides the next step,\ndocumenting the decision and its rationale on the issue.\n\n## Help\n\nIf you need help with this process, please contact the Go contributors by posting\nto the [golang-dev mailing list](https://groups.google.com/group/golang-dev).\n(Note that the list is moderated, and that first-time posters should expect a\ndelay while their message is held for moderation.)\n\nTo learn about contributing to Go in general, see the\n[contribution guidelines](https://go.dev/doc/contribute).\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgolang%2Fproposal","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fgolang%2Fproposal","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fgolang%2Fproposal/lists"}