I have a proposal for improving Go proposal procedure.
It stems from two "issues" highlighted in several occasions:
1. core Go team is spending an increasing amount of time discussing a
larger number of proposals.
All of them are commented and discussed by core Go team, and in the end
most of them are declined.
2. participation of Go community at large to the proposal procedure is
limited:
single individuals can create new proposals or comment on them, but
there is no concept of "community support" or "community effort"
In short, there is no *filter* between single individuals and core Go team.
Direct communication is good in a small group, but it does not scale to
large groups.
My proposal is conceptually simple:
delegate some power (rights) and responsibility (duties) to the
community.
How? I propose the following:
1. proposals must collect enough "community support" before being evaluated
by core Go team.
Initially, this can be as simple as waiting for enough thumbs up (and
fewer thumbs down) on the corresponding github issue.
If/when need arises, it may also become a more formal process.
The core Go team will have less work:
they would be *required* to evaluate only those with enough "community
support", not *all* proposals as they do now.
Of course they will still be free to evaluate also other proposals if
they want, but they will not be required to.
The Go community would be empowered by this change:
it will have a more active role, acting as a first filter for
proposals,
and a proposal with strong community support should receive more focus
from core Go team
than a proposal with weak (or no) community support.
This may require a web page that lists active proposals (is it allowed
to scrape github content?),
with mechanisms to filter them by keyword(s) and sort them at least by
date/thumbs up/thumbs down.
2. proposals must follow a template, which contains at least:
a. the list of existing similar proposals and, if they were not
approved, the reasons why the new proposal
is believed to be better
b. a first evaluation of pros and cons
This is expected to improve the quality of new proposals, by doing a
basic background check of prior art
and a first (self) evaluation.
On Friday, July 17, 2020 at 7:54:46 PM UTC+2, Ian Lance Taylor wrote:
>
> On Fri, Jul 17, 2020 at 10:20 AM medienwer...@gmail.com
> <medienwer...@gmail.com <javascript:>> wrote:
> >
> > With your considerations in mind I suggest a well defined triage
> mode/"traffic light" - system for processing language feature proposals.
> >
> > When your/the teams bias is clear, the indication shows the proposer/the
> community feasible and/or practicable "next steps".
> >
> > Also a collection of "reference cases" can guide the growing number of
> gophers, viable ideas and solutions.
> >
> > Following posts explain the needs:
> >
> > https://blog.golang.org/toward-go2
> >
> > https://blog.golang.org/experiment
> >
> > https://blog.golang.org/go2-here-we-come
>
> Thanks for the suggestion. However, I don't understand how to make
> that work in practice. Who is going to take the time to show feasible
> and practical next steps for each proposal? How is that different
> from what we have been doing for the last year?
>
> Ian
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/25f267d8-9d90-4a92-9435-04c5d958dc0do%40googlegroups.com.
