[rajathagasthya]

This obviously increases contributions, which is great. Does this now require more time from people with Run Trybot access to manually kick off a CI run? I wondered why Go always used that instead of automatically kicking off CI for each patchset. To save resources perhaps?

[discardable_dan]

At its heart, I am not certain the increased contributions are always good. There is a lot of theory written about how to build and grow out languages, and most of it seems to indicate that there needs to be a strong, central group of people with veto power. So long as the Go internal team retains this power, it's good, but having a community driving development for itself outside of the core language team often leads to (a) too many cooks in the kitchen and (b) adding features vocal fans want that nobody else cares about.

[rajathagasthya]

Go does have a strong, central group and in my (admittedly little) experience, they're very helpful too. But I'm just curious how the Go team scales with code reviews since this move will certainly bring in an influx of new contributors/PRs.

[bradfitz]

> To save resources perhaps?

For security, mostly. Our isolation is good but not perfect.

We could probably do a smaller set of (secure) builders for all patches, but it hasn't been a priority.

[mcote]

Given that one of the reasons GitHub is so popular is that it's a common toolchain, I wonder if it is indeed obvious that replacing the code-review tool with a different one (not to mention one that is often considered much less intuitive, if not usable) will result in more contributions. I hope the Go team posts some results in a few months.