[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"detail-sidebar-cat-1-en-105":3,"doc-seo-242354-105":53,"doc-detail-242354-en":126},{"code":4,"msg":5,"data":6},0,"success",[7,14,19,24,29,34,39,44,49],{"id":8,"doc_module":9,"doc_module_name":10,"category_name":11,"show_sort_weight":12,"slug":13},11,1,"Template","Presentations",90,"presentations",{"id":15,"doc_module":9,"doc_module_name":10,"category_name":16,"show_sort_weight":17,"slug":18},12,"Resumes",80,"resumes",{"id":20,"doc_module":9,"doc_module_name":10,"category_name":21,"show_sort_weight":22,"slug":23},14,"Invoices",70,"invoices",{"id":25,"doc_module":9,"doc_module_name":10,"category_name":26,"show_sort_weight":27,"slug":28},15,"Posters",60,"posters",{"id":30,"doc_module":9,"doc_module_name":10,"category_name":31,"show_sort_weight":32,"slug":33},16,"Social Media",50,"social-media",{"id":35,"doc_module":9,"doc_module_name":10,"category_name":36,"show_sort_weight":37,"slug":38},17,"Forms",40,"forms",{"id":40,"doc_module":9,"doc_module_name":10,"category_name":41,"show_sort_weight":42,"slug":43},18,"Letters",30,"letters",{"id":45,"doc_module":9,"doc_module_name":10,"category_name":46,"show_sort_weight":47,"slug":48},21,"Paper Templates",5,"papers-templates",{"id":50,"doc_module":9,"doc_module_name":10,"category_name":51,"show_sort_weight":4,"slug":52},158,"General","general-158",{"code":4,"msg":54,"data":55},"ok",{"site_id":56,"language":57,"slug":58,"title":59,"keywords":60,"description":61,"schema_data":62,"social_meta":119,"head_meta":121,"extra_data":123,"updated_unix":125},105,"en","go-proposal-process-large-changes","Go Proposal Process - Large Changes","","Explains how the Go proposal process distinguishes trivial proposals from non-trivial ones and why the current GitHub issue discussion works for small changes but fails for large changes with broader impact. Details common reasons for declining proposals early, the role of design docs in intricate cases, and proposes add-on mechanisms: a checklist/rubric to identify large changes, a pre-proposal drafting stage, and experimentation or differentiated discussions during formal acceptance.",{"@graph":63,"@context":118},[64,80,101],{"@type":65,"itemListElement":66},"BreadcrumbList",[67,71,74,77],{"item":68,"name":69,"@type":70,"position":9},"https://docshare.wps.com","Home","ListItem",{"item":72,"name":10,"@type":70,"position":73},"https://docshare.wps.com/template/",2,{"item":75,"name":11,"@type":70,"position":76},"https://docshare.wps.com/template/presentations/",3,{"item":78,"name":59,"@type":70,"position":79},"https://docshare.wps.com/template/go-proposal-process-large-changes/242354/",4,{"url":78,"name":59,"@type":81,"image":82,"author":87,"headline":59,"publisher":90,"fileFormat":93,"inLanguage":57,"description":61,"dateModified":94,"datePublished":95,"encodingFormat":93,"isAccessibleForFree":96,"interactionStatistic":97},"DigitalDocument",{"url":83,"@type":84,"width":85,"height":86},"https://docshare.wps.com/thumbnails/go-proposal-process-large-changes/242354.png","ImageObject",442,249,{"name":88,"@type":89},"Quinn Holloway","Person",{"url":68,"name":91,"@type":92},"DocShare","Organization","application/pdf","2026-10-14","2026-09-12",true,{"@type":98,"interactionType":99,"userInteractionCount":8},"InteractionCounter",{"@type":100},"ViewAction",{"@type":102,"mainEntity":103},"FAQPage",[104,110,114],{"name":105,"@type":106,"acceptedAnswer":107},"What are the two kinds of Go proposals in the current process?","Question",{"text":108,"@type":109},"The proposal process recognizes trivial proposals (no design doc) and non-trivial proposals (with a design doc). Early discussion happens via a GitHub issue, and many proposals exit after that stage.","Answer",{"name":111,"@type":106,"acceptedAnswer":112},"Why does the proposal issue discussion break down for large changes?",{"text":113,"@type":109},"The brief tracker discussion works for small changes, but large changes tend to trigger larger, broader discussions because more people are affected by the outcome.",{"name":115,"@type":106,"acceptedAnswer":116},"What additional steps does the author suggest for large changes?",{"text":117,"@type":109},"Suggestions include identifying large changes using a checklist/rubric, adding a pre-proposal stage where designs are drafted and explored, and possibly using an experimentation period before a formal proposal for acceptance.","https://schema.org",{"og:url":78,"og:type":120,"og:title":59,"og:site_name":91,"og:description":61},"article",{"robots":122,"canonical":78},"index,follow",{"doc_id":124,"site_id":56},242354,1791729852,{"code":4,"msg":5,"data":127},{"doc_id":124,"user_id":128,"nickname":88,"user_avatar":129,"doc_module":9,"category_id":8,"category_name":11,"doc_title":59,"doc_description":61,"doc_content":130,"file_id":131,"file_url":132,"file_type":133,"file_size":134,"view_count":8,"is_deleted":4,"is_public":9,"is_downloadable":9,"audit_status":9,"page_count":73,"language":135,"language_code":57,"site_id":56,"html_lang":57,"table_of_contents":136,"faqs":137,"seo_title":138,"seo_description":61,"update_tm":139,"read_time":9},2336474466712,"https://ap-avatar.wpscdn.com/davatar_a8503ba1806abce46bf441b54a3ca4cd","Go Proposal Process: Large Changes  \nGo Proposals, Part 3  \nRuss Cox  \nAugust 15, 2019  \n[research.swtch.com/proposals-large](research.swtch.com/proposals-large)  \n[I’ve been thinking a lot recently about the Go proposal process, which is the way we propose, discuss, and decide changes to Go itself. Like nearly everything about Go, the proposal process is an experiment, so it makes sense to reflect on what we’ve learned and try to improve it. This post is the third in a series of posts about what works well and, more importantly, what we might want to change.]  \nThe proposal process we have today recognizes two kinds of proposal: trivial (no design doc) and non-trivial (design doc) . An initial proposal issue can be just a few lines describing the idea, which is then discussed on the GitHub issue. Most proposals exit the process after this discussion. Typical reasons for declining a proposal at this stage include some combination of:  \n– The proposal is a duplicate of a previous proposal.  \n– The proposal is not specific enough to evaluate. For example, issue  \n20142 suggests to do something—but not something specific—about accidental nil dereferences.  \n– The proposal is not backwards compatible. For example, issue 33454 proposed first to change the type signature of log . (*Logger) .SetOutput and then was revised to change only the semantics instead. Both would be backwards-incompatible changes.  \n– The proposal can already be implemented as a package outside the standard library. For example, the problem solved by issue 33454—logging to multiple writers—is easily solved with‘io.MultiWriter.  \n– The proposal does not address a common enough problem to merit a change or addition to the language or standard library. For example, issue 26262 suggested a new %*T print verb that would have little applicability and is easily implemented as a one-line function if needed.  \n– The proposal violates a core design principle or goal of the package. For example, issue 33449 suggested adding indirect template calls to text/template, but that would invalidate the safety analysis in html/template.  \nThe typical reason for accepting a proposal at this stage is that the details are simple and straightforward enough that they can be stated crisply and clearly without a design doc, and there is general agreement about moving forward. The specifics can range from significant to trivial, from issue 19069 (extend release support timeline) to issue 18086 (add json.Valid) to issue 20023 (document that os .NewFile returns an error when passed a negative file descriptor) .  \nOther proposals are intricate enough or have subtle enough implications to merit writing a design document, which we save in the proposal design repo. For example, here are the design documents for testing subtests alias declarations (abandoned), type aliases, and mid-stack inlining.  \nThe brief issue tracker discussion contemplated in the proposal process works well for small changes, even those with subtle implications requiring a design document. But it breaks down for what we might think of as large changes. Larger changes don’t necessarily have longer design docs, but they tend to have  \n􀁹  \nG􀀨 P􀀫􀀨􀀩􀀨􀀬􀀚􀀥 P􀀫􀀨􀀜􀀞􀀬􀀬: L􀀚􀀫􀀠􀀞 C􀀡􀀚􀀧􀀠􀀞􀀬  \nlarger issue tracker discussions, because more people are affected by the result. Recent examples include the discussion of the Go 1.13 error value changes (404 comments as of August 1) and of course the try builtin (798 comments) .  \nLarge Checklist  \nOne idea raised was to leave the process for small changes unaffected but add more process for large changes. That in turn requires identifying large changes. One suggestion was to create a rubric based on a checklist of how much of the Go ecosystem a change affects. For example:  \n– Is the change user-visible at all?  \n– Does it require any changes to any documentation?  \n– Are its effects confined to a single package?  \n– Does it require changes to the language spec?  \n– Does it require users to change existing sc","cbCaiq8Lo6GT8AvI","https://ap.wps.com/l/cbCaiq8Lo6GT8AvI","pdf",122412,"English","# Go Proposals, Part 3\n## Proposal process today\n## Large checklist\n## Large process\n## Next","[{\"question\":\"What are the two kinds of Go proposals in the current process?\",\"answer\":\"The proposal process recognizes trivial proposals (no design doc) and non-trivial proposals (with a design doc). Early discussion happens via a GitHub issue, and many proposals exit after that stage.\"},{\"question\":\"Why does the proposal issue discussion break down for large changes?\",\"answer\":\"The brief tracker discussion works for small changes, but large changes tend to trigger larger, broader discussions because more people are affected by the outcome.\"},{\"question\":\"What additional steps does the author suggest for large changes?\",\"answer\":\"Suggestions include identifying large changes using a checklist/rubric, adding a pre-proposal stage where designs are drafted and explored, and possibly using an experimentation period before a formal proposal for acceptance.\"}]","Go Proposal Process - Large Changes | PDF",1789189529]