Go Change Proposal Process

[Andrew Gerrand]

Hi golang-dev,

Changes to the Go language, libraries, and tools have traditionally been proposed in an ad hoc manner. Sometimes proposals take the form of a document, sometimes they are just mail messages, sometimes they come as CLs.

Efforts have been made to track proposals, but without a formal process it's difficult to get a clear picture of the changes that have been proposed and their outcomes. The lack of process often leads to duplicate effort and makes it harder for outsiders to get involved in Go's development process.

To address these issues, Brad and I prepared a proposal for a Change Proposal Process for the project. :-)

https://golang.org/s/proposal-process

Please take a look.

Andrew

[Andrew Gerrand]

Please leave comments in this thread.

(I thought about using the process to propose the process, but decided to avoid the bootstrapping issues. :-)

Thanks.

[gugl.z...@gmail.com]

Sounds great, thank you for finally formalising the process.

I have one question. If there is already an issue (with the "thinking" label) that discusses the topic of my proposal, do I still open a new issue for the proposal, or I should mention the proposal in the original issue? Say, if I were to propose an implementation of array assertions, which are being discussed in https://github.com/golang/go/issues/395, should I post a reply there, or open a new issue and add a link to the original issue in the description?

[Dan Kortschak]

This is a good point. I would personally like to see older proposals
with the thinking label be threaded into this process, so that we can
know what the thinking is.

[Alberto Donizetti]

One little comment

> The author proposes the change as a brief description in a new issue on the golang/go issue tracker.

why pollute the main issue tracker when we have a new repo? The proposal-as-md-files-in-a-repo model
is nice but it make sense to host preliminary discussion in the issues section of the proposal repo, and
not in golang/go, IMO.

Rust, mentioned in the document, does exactly that.

[Dave Cheney]

Counter argument: why create two places to check, where before there
was just one ?

I think this proposal is fine as is.

On Thu, Jun 18, 2015 at 7:47 AM, Alberto Donizetti
<alb.do...@gmail.com> wrote:
> One little comment
>
>> The author proposes the change as a brief description in a new issue on
>> the golang/go issue tracker.
>

> why pollute the golang/go issue tracker when we have a whole new repository?
> The proposals-as-md-files-in-a-new-repo
> model is nice, but it would make sense to use the issue tracker of that new
> repo, IMO.
>
> You cited rust. In rust preliminary talk about proposals is done in the
> issues section of the rust-lang/RFC repository, not
> in rust-lang/rust.

>
>
> Il giorno mercoledì 17 giugno 2015 23:08:45 UTC+2, Andrew Gerrand ha
> scritto:
>>

> --
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Brad Fitzpatrick]

On Wed, Jun 17, 2015 at 3:16 PM, Alberto Donizetti <alb.do...@gmail.com> wrote:

One little comment

> The author proposes the change as a brief description in a new issue on the golang/go issue tracker.

why pollute the main issue tracker when we have a new repo? The proposal-as-md-files-in-a-repo model
is nice but it make sense to host preliminary discussion in the issues section of the proposal repo, and
not in golang/go, IMO.

Three reasons:

1) people are going to file wishlist proposal-type bugs in the main repo anyway.

2) once a proposal reaches Accept stage, we need to implement it, so we need a golang/go issue at that point anyway. Might as well have one with the history in it.

3) what Dave Cheney said. Also means we only have one number space, so no confusion about what "Proposal NNN" means. (Which NNN?)

[Michael Hudson-Doyle]

Something that isn't directly relevant to this proposal but that I
wonder about is when to raise proposals. I have a few medium-sized
changes that I'd like to make early in 1.6 but currently I've been
sitting on them as discussing them during the freeze doesn't seem
quite right. Or should I start guinea pigging the process now?

On 18 June 2015 at 09:19, 'Andrew Gerrand' via golang-dev

[Brad Fitzpatrick]

Guinea pig it away.

Worst case some people will ignore some proposals until 1.5 stabilizes and the arbiter will be unable to call the consensus for a couple weeks or months. But best case you start getting feedback.

[Burcu Dogan]

Could you explain what notable means in "notable change or addition to
the language" more explicitly?

Do I need to create proposal documents for the less mature parts of
the project? An example case is the mobile repo where each feature is
relatively more experimental and open to change.

[Andrew Gerrand]

On 18 June 2015 at 08:05, <gugl.z...@gmail.com> wrote:

I have one question. If there is already an issue (with the "thinking" label) that discusses the topic of my proposal, do I still open a new issue for the proposal, or I should mention the proposal in the original issue? Say, if I were to propose an implementation of array assertions, which are being discussed in https://github.com/golang/go/issues/395, should I post a reply there, or open a new issue and add a link to the original issue in the description?

If you want to propose the implementation of a specific feature request, I'd say it's reasonable off the proposal process by bumping the existing issue, briefly outlining what you intend to propose.

[Andrew Gerrand]

On 18 June 2015 at 08:58, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

This is a good point. I would personally like to see older proposals
with the thinking label be threaded into this process, so that we can
know what the thinking is.

I don't see a big payoff for going through all of them and writing them up; it would be a big distraction, at least.

If people want to champion specific existing issues then they're welcome to bump them for further investigation (as always). 

[Andrew Gerrand]

On 18 June 2015 at 11:38, Burcu Dogan <j...@google.com> wrote:

Could you explain what notable means in "notable change or addition to
the language" more explicitly?

Do I need to create proposal documents for the less mature parts of
the project? An example case is the mobile repo where each feature is
relatively more experimental and open to change.

In general, it's a good practice to create issues for features you want to work on, even for experimental work. From there—if the feature warrants some design and discussion—it's easy for other contributors to request that the feature be proposed formally using this process.

If in doubt, offer to write a proposal. If it's not necessary, the maintainer of the relevant component can just label the issue as 'Approved' and you can proceed straight to the implementation.

As stated in the doc, this new proposal process is an experiment. As we see how it works in practice we'll better understand when it should and should not be used.

[Dan Kortschak]

I would really like to have a more considered answer to the tables
proposal that Brendan Tracey put forward. It's currently in thinking.

[Andrew Gerrand]

On 18 June 2015 at 12:32, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:

I would really like to have a more considered answer to the tables
proposal that Brendan Tracey put forward. It's currently in thinking.

Nigel wrote what I believe is a considered response. I have updated the issue:

  https://github.com/golang/go/issues/6282#issuecomment-113018688

[Dan Kortschak]

On Thu, 2015-06-18 at 12:44 +1000, Andrew Gerrand wrote:
> Nigel wrote what I believe is a considered response. I have updated
> the
> issue:
> https://github.com/golang/go/issues/6282#issuecomment-113018688
>

OK. I read that differently at the time, I'm still not sure if
incorrectly.

[Michael Hudson-Doyle]

OK! https://github.com/golang/go/issues/11270 it is.

[Alberto Donizetti]

Makes sense.

[oju...@gmail.com]

May I share a little concern of mine about this process? My concern is about changes to the language.

I am very confident in your abilities to negotiate new features. You are very talented people.

Just considering the language, we have seen dozens of informal proposals on golang-nuts accumulating since day 1. Every gopher knows what are the most requested features and why they hadn't been implemented until now. In other words, the core team already knows what is worth consideration.

 

Let's say you guys receive something like 50 proposals for new language features, all pretty good. So will every one of them get implemented? Of course not. For the vast majority of those proposals the answer is already made: a big "thank you, but we can't add this feature". It's a practical matter.

 

So, we are beginning a process that inevitably will frustrate the most of those collaborators, dedicated users, people willing to sit down and prepare carefully a proposal that will be discarded at the end of the day. Sounds that good enough?

 

I suggest you guys take an alternative approach at least for language change proposals.

 

Pick a little feature set the core team agrees is worth consideration and ask community for opinions and feedback for that set only, along the lines "ok, guys, we are open to discussion about incorporating features X, Y and Z. Please submit proposals for these features."

 

I think this way the outcomes will be healthier.

[Axel Wagner]

oju...@gmail.com writes:
> So, we are beginning a process that inevitably will frustrate the most of
> those collaborators, dedicated users, people willing to sit down and
> prepare carefully a proposal that will be discarded at the end of the day.
> Sounds that good enough?

The proposal basically replaces "send a msg to golang-nuts" with "create
an issue". I don't see a big difference, the preparation needed is
pretty much the same. The difference is, that the issue can be tracked
and can be closed as a duplicate, with a direct link to the duplicate
issue, which contains a more detailed conversation, so it will
ultimately a) help the maintainers, because it's easier to reply without
adding a whole new rationalization and b) doesn't really make it more
difficult for people to propose things, they just have to create an
informal ticket.

[Andrew Gerrand]

On 21 June 2015 at 23:11, <oju...@gmail.com> wrote:

May I share a little concern of mine about this process? My concern is about changes to the language.

 

Thanks for your concern. It is also something I have thought about myself, but I think the proposed process will avoid the issues you describe.

Let's say you guys receive something like 50 proposals for new language features, all pretty good. So will every one of them get implemented? Of course not. For the vast majority of those proposals the answer is already made: a big "thank you, but we can't add this feature". It's a practical matter.

 

So, we are beginning a process that inevitably will frustrate the most of those collaborators, dedicated users, people willing to sit down and prepare carefully a proposal that will be discarded at the end of the day. Sounds that good enough?

The first step in the process is "file an issue." That allows us to give feedback before the proposal work is even done.

  

Pick a little feature set the core team agrees is worth consideration and ask community for opinions and feedback for that set only, along the lines "ok, guys, we are open to discussion about incorporating features X, Y and Z. Please submit proposals for these features."

We're not interested in actively encouraging any language-level proposals. That's why the document explicitly says:

"Further, note that Go is a mature language and as such significant language changes are unlikely to be accepted." 

Andrew

[oju...@gmail.com]

On Sunday, June 21, 2015 at 7:39:43 PM UTC-3, Andrew Gerrand wrote:

We're not interested in actively encouraging any language-level proposals. That's why the document explicitly says:

 

"Further, note that Go is a mature language and as such significant language changes are unlikely to be accepted." 

I am glad to learn that, Andrew. Call me conservative, but I like the language the way it is.

[Sébastien Douche]

On Sun, 21 Jun 2015, at 15:11, oju...@gmail.com wrote:
> Let's say you guys receive something like 50 proposals for new language
> features, all pretty good. So will every one of them get implemented? Of
> course not. For the vast majority of those proposals the answer is
> already
> made: a big "thank you, but we can't add this feature". It's a practical
> matter.

An easy thing for reduce this effect is to ask a functional POC :). I
like the way the CPython community works:

- python-ideas@ for debate on ideas
- python-dev@ for debate on PEP (formalized document with an testable
code)



--
Sébastien Douche <s...@nmeos.net>
Twitter: @sdouche
http://douche.name

[Axel Wagner]

Sébastien Douche <s...@nmeos.net> writes:
> On Sun, 21 Jun 2015, at 15:11, oju...@gmail.com wrote:
> An easy thing for reduce this effect is to ask a functional POC :).

I think this is precisely what OP didn't want: To have some relevant
burdon of formulating or implementing a proposal, just to get shut down
for it. The proposal as it is proposed is a good idea, I think. In
particular, Implementation comes only *after* a significant part of the
proposal has been gone through.

[scot...@pakin.org]

On Wednesday, June 17, 2015 at 3:08:45 PM UTC-6, Andrew Gerrand wrote:

Changes to the Go language, libraries, and tools have traditionally been proposed in an ad hoc manner. Sometimes proposals take the form of a document, sometimes they are just mail messages, sometimes they come as CLs.

I have a bunch of questions:

• Could the document please clarify what's meant by "change"?  Does "change" include semantics-preserving modifications such as performance enhancements?  Does it include bug fixes?
• Is the process intended solely for developers who intend to change the language/libraries/tools themselves, or is it also intended to be used for wish-list items to be picked up by other developers?  (I'm guessing the latter based on the "Implementation" section of the template.)
• Will there be a mechanism to handle proposals that aren't precisely duplicates but that should reasonably be merged into an existing proposal?
• Will there be a mechanism to group related but separate proposals?  Maybe a tagging mechanism would be sufficient for this.  For example, binning all the generics proposals together would make it easy for people proposing generics solutions to see if their idea has already been proposed and what the arguments against it were.
  

Also, it would be nice for the wiki or whatever to point to some example high-quality proposals, including both a large, complex proposal (e.g., multidimensional slices) and a trivial proposal (e.g., something along the lines of "Add Bar(float64) to package foo to complement the existing Bar(int) and Bar(string) functions").

— Scott

[Nigel Tao]

On Thu, Jul 2, 2015 at 5:44 AM, <scot...@pakin.org> wrote:
> Could the document please clarify what's meant by "change"? Does "change"
> include semantics-preserving modifications such as performance enhancements?
> Does it include bug fixes?

I don't have the definitive answer here. This is new to us too.
Perhaps a rough guide is:

If you were previously going to send mail to golang-dev (e.g. post a
design doc), or if you want a formal evaluation of an idea, file a
proposal. If you were previously going to file an issue, just file an
ordinary issue and if it turns out that the topic needs more careful
evaluation, it is easy to upgrade it to "proposal". If you're new to
it all and have no idea what you would have done previously, perhaps
err on the side of filing a proposal. If you are a regular contributor
and confident that a change will be non-controversial, then there's
probably no need for a proposal.

Others may have different opinions, though. The doc does say that "no
change should be considered too small to follow the [proposal]
process." Perhaps adg can clairfy the nuance.


Separately, Jason Buberel recently filed
https://golang.org/issue/11502 "proposal: A security response policy
for Go". I don't scan the issues list as often as I scan e.g. the
golang-dev mailing list, and I might not have noticed it. Should we
encourage proposers to also send a courtesy e-mail to golang-dev, or
would that be considered noise, like making code reviews to not
auto-CC golang-dev?

> Also, it would be nice for the wiki or whatever to point to some example
> high-quality proposals, including both a large, complex proposal (e.g.,
> multidimensional slices) and a trivial proposal (e.g., something along the
> lines of "Add Bar(float64) to package foo to complement the existing
> Bar(int) and Bar(string) functions").

From my personal experience, things I previously mailed golang-dev
about that I would now Propose:
- a new golang.org/x/image/draw package
(https://groups.google.com/forum/#!topic/golang-dev/B7-OrWdheic and
https://groups.google.com/forum/#!topic/golang-dev/fgn_xM0aeq4)
- what is now the golang.org/x/text/{encoding,transform} packages
(https://groups.google.com/forum/#!topic/golang-dev/UfT00vJBW8Y)
and with smaller scope:
- Rectangle implementing Image
(https://groups.google.com/forum/#!topic/golang-dev/mkKyOKW7Erk)
- CMYK (https://groups.google.com/forum/#!topic/golang-dev/augloDDyejI)

[scot...@pakin.org]

Helpful; thanks.

— Scott

[Russ Cox]

First, let me say that I strongly support this idea. We absolutely have to help people prepare complete proposals, and we absolutely have to make sure they get a proper hearing. I believe the goal is to document what the main team already does and help more people do it successfully. The main deviation from current practice is moving the docs from Google Docs to a subrepo.

The word "proposal" is overloaded in the doc to mean both the initial suggestion and the supporting doc. If we call the supporting doc a "design doc" instead, then I think things become clearer: there are proposals that need design docs but also proposals that don't. One of the main improvements of this process is helping to teach people how to write a good design doc.

Overall, the goal is to quickly reach a considered decision about a proposal: (1) accept or (2) decline. The initial discussion about a proposal can lead to an intermediate decision: (3) ask for a design doc. Then the design doc becomes more input to between (1) and (2). Those are the fundamental states and probably all that needs to be in the doc.

Again the key points are that we're making the process clear to new contributors, including advice about what a design doc needs to contain, and committing to timely evaluations of proposals, and we're also building a recorded history of proposals to inform future ones. There's much more text in the proposal proposal about states than about these key points, which makes it easy to focus on a relatively unimportant part and miss the big picture. I also think the proposal decisions should be in comments, not labels, because the comments are more clearly attributed and easier to find in the history. There should be a Proposal label, though, to help find all proposals and maybe even to help build an index of proposals, past and present. If we make it lightweight enough, we might get in the habit of regularly tagging closed issues as Proposals just so they appear in the index and others can find them. For example, the conversation Nigel and I had on golang.org/issue/11344 is probably worth putting into the proposal history. It would be great if that could be done by just adding the Proposal label (and no other work, including no subject change).

The outline below is my attempt at a skeleton for a streamlined version of the proposal proposal. I'm not saying it should be in outline form, just that this is a structure I think would be more balanced and maybe easier to approach. Maybe instead of updating the proposal proposal, this outline could be a starting point for the eventual doc we'll point contributors to.

Big caveat: the outline below is how I understand the proposal proposal. I could be wrong, or we could find that we need to do something different. I'm not trying to write the last word.

Russ

Goals:

- Make sure that proposals get a proper, fair, timely, recorded evaluation with a clear answer.

- Make past proposals easy to find, to avoid duplicated effort.

- If a design doc is needed, make sure people know or can learn how to write a good one.

- Change as little as possible about what successful change proposers are already doing.

Definitions:

- A proposal is a suggestion filed as a GitHub issue, identified by having the Proposal label.

- A design doc is the expanded form of a proposal, written when the proposal needs more careful explanation and consideration.

Process:

- Like any GitHub issue, a Proposal issue is followed by an initial discussion about the suggestion. For Proposal issues:

- The goal of the initial discussion is to reach agreement on the next step:

(1) accept, (2) decline, or (3) ask for a design doc. 

- The discussion is expected to be resolved in a timely manner.

- If the author wants to write a design doc, that's usually an automatic (3).

- In Go development historically, a lack of agreement means (3).

- If there is disagreement about whether there is agreement, adg@ is the arbiter.

- 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:

- The design doc should be checked in to golang.org/x/proposal/design/NNNN-shortname.md,

where NNNN is the GitHub issue number and shortname is a short name (a few words at most).

- The design doc should follow golang.org/x/proposal/design/template.md.

- The design doc should take care to address any specific issues asked for during the initial discussion.

- It is expected that the design doc may go through multiple checked-in revisions.

- New design doc authors may be paired with a design doc "shepherd" to help work on the doc.

- If the author is a committer, each revision can be self-+2'ed.

- Comments by others can be made on the Gerrit CLs or on the GitHub issue, whatever makes sense.

- Once comments and revisions on the design doc wind down, there is a final discussion about the suggestion.

- The goal of the final discussion is to reach agreement on the next step:

(1) accept or (2) decline.

- The discussion is expected to be resolved in a timely manner.

- In Go development historically, a lack of agreement means decline.

- If there is disagreement about whether there is agreement, adg@ is the arbiter.

- There will be a weekly automatic mail to golang-dev listing pending proposals (and maybe other business).

- It's fine to start a separate golang-dev thread for broad issues.

Quick start for committers:

- In the situation where you'd write and circulate a design doc as a Google doc before, now you:

- Create a GitHub issue labeled Proposal, to get a number NNNN.

- Check in the design doc at golang.org/x/proposal/design/NNNN-shortname.md, self +2'ed.

- Mail golang-dev as usual.

- The main thing that's changing is where the proposal is published.

- Worst case, by bypassing the initial discussion you've possibly written an unnecessary design doc. Not a big deal.

[Nigel Tao]

On Fri, Jul 3, 2015 at 12:49 PM, Russ Cox <r...@golang.org> wrote:
> - If a Proposal issue leads to a design doc:
> - The design doc should be checked in to
> golang.org/x/proposal/design/NNNN-shortname.md,
> where NNNN is the GitHub issue number and shortname is a short name (a few
> words at most).
> - The design doc should follow golang.org/x/proposal/design/template.md.

SGTM. Is there a timeline for when the x/proposal sub-repo and its
design/template.md will be created?

[Andrew Gerrand]

Thanks for your thoughtful reply, Russ.

That is very helpful.

Separating the proposal from the design doc conceptually has made this a lot clearer to me, at least.

I'd like the others who have raised concerns in this thread to take a look at Russ' message and let me know me whether it resolves those concerns.

If people are generally in favor of this approach, I'd like to bypass rewriting my proposal document and work out the details as we actually implement the policy (through code review).

[Rob Pike]

SGTM

[oju...@gmail.com]

On Friday, July 3, 2015 at 2:54:52 AM UTC-3, Andrew Gerrand wrote:

I'd like the others who have raised concerns in this thread to take a look at Russ' message and let me know me whether it resolves those concerns.

 

Things got better now. That should be enough to support debate and exploration of new ideas without being too cumbersome. Thanks.

[anl...@gmail.com]

On Monday, June 22, 2015 at 12:39:43 AM UTC+2, Andrew Gerrand wrote:

"Further, note that Go is a mature language and as such significant language changes are unlikely to be accepted." 

its fair to declare the language project dead (maintenance-only). this means the community won't be wasting time, and can shift their efforts
to open source forks.


 

Andrew

[Brendan Tracey]

Working notes for the 1.5 release coming out in a month: https://tip.golang.org/doc/go1.5

What part of that makes you think the project is dead?

 

Andrew

[Richard Fliam]

The "Proposal" tag seems a better solution than the prefixing. I also like splitting out the design docs as major and minor changes all come in under the same process. 

>  - The goal of the initial discussion is to reach agreement on the next step:

> (1) accept, (2) decline, or (3) ask for a design doc. 

The original document contained another terminal state I think is worthwhile, "Duplicate". A suggestion may duplicate another inflight conversation and thus its final state is really none of the 3 above. Debate over "duplicate" status of course is also possible. 

Perhaps adding tags for "Accepted", "Declined", or "Duplicate" when a terminal state is reached is worthwhile? This allows contributors to automatically filter through the history in a more searchable manner (which will surely grow difficult to manage).

~Richard

[akwi...@inbox.com]

go is definitely not a mature language. The syntax for maps is a glaring example. Inconsistent much? yes!

[akwi...@inbox.com]

this response is laughable. The entire change proposal process is a farce.

[akwi...@inbox.com]

This response is laughable. The entire change proposal process is a farce.



On Wednesday, June 17, 2015 at 10:44:42 PM UTC-4, Andrew Gerrand wrote:

[Lucio De Re]

On 7/21/15, akwi...@inbox.com <akwi...@inbox.com> wrote:
> this response is laughable. The entire change proposal process is a farce.
>

And your comment amazingly informative?!

Lucio.

[Ian Lance Taylor]

On Tue, Jul 21, 2015 at 4:56 AM, <akwi...@inbox.com> wrote:
> this response is laughable. The entire change proposal process is a farce.

I think you have your causation backward. You are taking a response
written before the change proposal process was proposed and using it
to criticize the change proposal process. That doesn't make sense.

Ian

> On Wednesday, June 17, 2015 at 10:44:42 PM UTC-4, Andrew Gerrand wrote:
>>
>>
>> On 18 June 2015 at 12:32, Dan Kortschak <dan.ko...@adelaide.edu.au> wrote:
>>>
>>> I would really like to have a more considered answer to the tables
>>> proposal that Brendan Tracey put forward. It's currently in thinking.
>>
>>
>> Nigel wrote what I believe is a considered response. I have updated the
>> issue:
>> https://github.com/golang/go/issues/6282#issuecomment-113018688
>

[Andrew Gerrand]

There's also been some off-list discussion with Brendan and Dan about the multi-dimensional arrays proposal, and how it relates to the new proposal process. The (mis)handling of that proposal is one of the motivations for the new process.

[Nigel Tao]

On Tue, Jul 21, 2015 at 10:00 PM, <akwi...@inbox.com> wrote:
> go is definitely not a mature language. The syntax for maps is a glaring
> example. Inconsistent much? yes!

As I've previously said elsewhere, there are reasons why the map
syntax is what it is. As you haven't given an alternative syntax,
either here (off-topic) or in the previous thread
(https://groups.google.com/forum/#!topic/golang-nuts/4hagAj_JO7g), I
don't find your comment particularly insightful or constructive, even
if we could break Go 1 compatibility.

Drifting off-topic... If you don't like the Go community's approach to
software development, where we don't automatically say yes to every
feature request just because it could be useful, then that's fine, and
we'll agree to disagree. But continually sniping one-liner opinions
that we're stupid isn't constructive or likely to change our behavior,
so I struggle to see what benefit you or anyone else is getting out of
it.

[Tom Heng]

the proposal issue lied in golang/go repo issues has some cons.

1) messed golang/go issue list

2) different things(proposal issue and bug issue) should distinguished 

3) support issue title like golang/go issue

eg.

regexp: port RE2's CoalesceWalker to Go's regexp package

rather than

proposal: regexp: port RE2's CoalesceWalker to Go's regexp package

so put proposal start issue in golang/proposal repo may be helpful and the right way.

在 2015年6月18日星期四 UTC+8上午5:08:45，Andrew Gerrand写道：

Hi golang-dev,

Changes to the Go language, libraries, and tools have traditionally been proposed in an ad hoc manner. Sometimes proposals take the form of a document, sometimes they are just mail messages, sometimes they come as CLs.

Efforts have been made to track proposals, but without a formal process it's difficult to get a clear picture of the changes that have been proposed and their outcomes. The lack of process often leads to duplicate effort and makes it harder for outsiders to get involved in Go's development process.

To address these issues, Brad and I prepared a proposal for a Change Proposal Process for the project. :-)

https://golang.org/s/proposal-process

Please take a look.

Andrew

[Andrew Gerrand]

Hi all,

I've created a proposal repo and put the proposal process in its README.md file:

https://golang.org/s/proposal-process

After Go 1.5 is out I'll triage the proposals that have been submitted already, and make recommendations about whether design docs should be written (or seek expert advice where necessary).

Please let me know if there is anything unclear here.

Andrew