在线时间:8:00-16:00
迪恩网络APP
随时随地掌握行业动态
扫描二维码
关注迪恩网络微信公众号
开源软件名称:golang/proposal开源软件地址:https://github.com/golang/proposal开源编程语言:Go 67.0%开源软件介绍:Proposing Changes to GoIntroductionThe Go project's development process is design-driven.
Significant changes to the language, libraries, or tools
(which includes API changes in the main repo and all golang.org/x repos,
as well as command-line changes to the 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 ProcessThe proposal process is the process for reviewing a proposal and reaching a decision about whether to accept or decline the proposal.
After the proposal is accepted or declined (whether after step 2 or step 4), implementation work proceeds in the same way as any other contribution. DetailGoals
Definitions
ScopeThe proposal process should be used for any notable change or addition to the
language, libraries and tools.
“Notable” includes API changes in the main repo and all golang.org/x repos,
as well as command-line changes to the There is a short list of changes that are typically not in scope for the proposal process:
Again, if in doubt, file a proposal. CompatibilityPrograms 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. Language changesIn 2018 we started a Go 2 process during which we may change the language, as described on the Go blog. Language changes should follow the proposal process described here. As explained in the blog entry, language change proposals should
Proposals should follow the Go 2 template. See the Go 2 review minutes and the release notes for examples of recent language changes. Design DocumentsAs noted above, some (but not all) proposals need to be elaborated in a design document.
Quick Start for Experienced CommittersExperienced committers who are certain that a design doc will be required for a particular proposal can skip steps 1 and 2 and include the design doc with the initial issue. In the worst case, skipping these steps only leads to an unnecessary design doc. Proposal ReviewA group of Go team members holds “proposal review meetings” approximately weekly to review pending proposals. The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part. The proposal review meetings also identify issues where consensus has been reached and the process can be advanced to the next step (by marking the proposal accepted or declined or by asking for a design doc). Minutes are posted to golang.org/s/proposal-minutes after the conclusion of the weekly meeting, so that anyone interested in which proposals are under active consideration can follow that issue. Proposal issues are tracked in the Proposals project on the Go issue tracker. The current state of the proposal is captured by the columns in that project, as described below. The proposal review group can, at their discretion, make exceptions for proposals that need not go through all the stages, fast-tracking them to Likely Accept/Likely Decline or even Accept/Decline, such as for proposals that do not merit the full review or that need to be considered quickly due to pending releases. IncomingNew proposals are added to the Incoming column. The weekly proposal review meetings aim to look at all the issues in the Active, Likely Accept, and Likely Decline columns. If time is left over, then proposals from Incoming are selected to be moved to Active. Holding proposals in Incoming until attention can be devoted to them (at which they move to Active, and then onward) ensures that progress is made moving active proposals out to Accepted or Declined, so we avoid receive livelock, in which accepting new work prevents finishing old work. ActiveIssues in the Active column are reviewed at each weekly proposal meeting to watch for emerging consensus in the discussions. The proposal review group may also comment, make suggestions, ask clarifying questions, and try to restate the proposals to make sure everyone agrees about what exactly is being discussed. Likely AcceptIf an issue discussion seems to have reached a consensus to accept the proposal, the proposal review group moves the issue to the Likely Accept column and posts a comment noting that change. This marks the final period for comments that might change the recognition of consensus. Likely DeclineIf a proposal discussion seems to have reached a consensus to decline the proposal, the proposal review group moves the issue to the Likely Decline column. An issue may also be moved to Likely Decline if the proposal review group identifies that no consensus is likely to be reached and that the default of not accepting the proposal is appropriate. Just as for Likely Accept, the group posts a comment noting the change, and this marks the final period for comments that might change the recognition of consensus. AcceptedA week after a proposal moves to Likely Accept, absent a change in consensus, the proposal review group moves the proposal to the Accepted column. If significant discussion happens during that week, the proposal review group may leave the proposal in Likely Accept for another week or even move the proposal back to Active. Once a proposal is marked Accepted, the Proposal-Accepted label is applied, it is moved out of the Proposal milestone into a work milestone, and the issue is repurposed to track the work of implementing the proposal. The default work milestone is Backlog, indicating that the work applies to the Go release itself but is not slated for a particular release. Another common next milestone is Unreleased, used for work that is not part of any Go release (for example, work in parts of golang.org/x that are not vendored into the standard releases). DeclinedA week after a proposal moves to Likely Decline, absent a change in consensus, the proposal review group moves the proposal to the Declined column. If significant discussion happens during that week, the proposal review group may leave the proposal in Likely Decline for another week or even move the proposal back to Active. Once a proposal is marked Declined, it is closed. Declined as DuplicateIf a proposal duplicates a previously decided proposal, the proposal review group may decline the proposal as a duplicate without progressing through the Active or Likely Decline stages. Generally speaking, our approach to reconsidering previously decided proposals follows John Ousterhout's advice in his post “Open Decision-Making,” in particular the “Reconsideration” section. Declined as InfeasibleIf a proposal directly contradicts the core design of the language or of a package, or if a proposal is impossible to implement efficiently or at all, the proposal review group may decline the proposal as infeasible without progressing through the Active or Likely Decline stages. If it seems like there is still general interest from others, or that discussion may lead to a feasible proposal, the proposal may also be kept open and the discussion continued. Declined as RetractedIf a proposal is closed or retracted in a comment by the original author, the proposal review group may decline the proposal as retracted without progressing through the Active or Likely Decline stages. If it seems like there is still general interest from others, the proposal may also be kept open and the discussion continued. HoldIf discussion of a proposal requires design revisions or additional information that will not be available for a couple weeks or more, the proposal review group moves the proposal to the Hold column with a note of what it is waiting on. Once that thing is ready, anyone who can edit the issue tracker can move the proposal back to the Active column for consideration at the next proposal review meeting. Consensus and DisagreementThe goal of the proposal process is to reach general consensus about the outcome in a timely manner. If general consensus cannot be reached, the proposal review group decides the next step by reviewing and discussing the issue and reaching a consensus among themselves. If even consensus among the proposal review group cannot be reached (which would be exceedingly unusual), the arbiter (rsc@) reviews the discussion and decides the next step. HelpIf 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. |
2023-10-27
2022-08-15
2022-08-17
2022-09-23
2022-08-13
请发表评论