> > Beta release timing is entirely determined by GitHub issues. The release
> > team meets every Thursday with a subset of the Go team to discuss
> > release-related issues.
>
> I think it would help if more of these regular Go team meetings were
> conducted openly, rather than privately within Google. For example, my
> impression is the golang-tools group is doing a good job at this:
>
https://github.com/golang/go/wiki/golang-tools
>
> I don't think this is an issue specific to the release team, or something
> that I think is intentionally done. E.g., I think the compiler/runtime team
> tends to default to discussing a lot of things internally even when most of
> it could be discussed openly too. But I think it would help live up to our "Go
> needs everyone's help, and everyone isn't here"
> <
https://blog.golang.org/open-source> motto if we strived to make more
> recurring meetings public by default.
I have mixed feelings about this idea. On one hand, I've attended almost
all golang-tools calls and I think they work great, and will hopefully
set a good example for other Go sub-teams to open up more to
non-Googlers.
On the other hand, I think it's necessary to say that the "tooling
team", meaning primarily cmd/go and gopls, is special in that its nature
requires it to have close ties with many external contributors and
projects. For example, a big portion of each monthly meeting is
discussing gopls issues which affect third party editors and
integrations. Another good example is getting early feedback on cmd/go
changes from tool authors, before the changes get fully released.
I am fully on board with other sub-teams becoming more transparent and
diluting the "googler or external contributor" line like golang-tools
has. I just have a slight worry that the compiler or release teams might
not be quite as well suited to that model, so perhaps they should take
more gradual steps towards it rather than doing a big jump.
The regular and public status updates sound like a great first step :)
Perhaps the compiler or runtime folks could do something similar by
publishing minutes from existing regular meetings on a GitHub thread.