Go: proposal: decide & document policy for giving out golang.org emails

[bradfitz]

We should decide on & document the policy for who gets golang.org email addresses.

The community is curious.

Empirically, the policy seems to be "anybody who's ever been paid by Google either now or in the past". But it's not obvious that's the correct policy. (if that's even accurate)

/cc @andybons @namusyaka

[mvdan]

I always assumed it required the person to have been a member of the Go team at some point.

[namusyaka]

@bradfitz Thank you for picking up my suggestion.

Yes, I agree very much with the establishment of a clear policy (or like GerritAccess).
It is set that not only can you get a big motivation for Go team members, but also I think that development is going to proceed smoothly.

[bradfitz]

I always assumed it required the person to have been a member of the Go team at some point.

Maybe? I thought there were some exceptions. (Contractors?) But maybe that was the policy. But I think some Googlers not on the Go team have also got them before? Maybe?

I think it's somewhat random. (Many people on the Go team prefer to use their google.com addresses, too.)

[ianlancetaylor]

CC @spf13

[rsc]

For the initial open source release, we ported the internal-to-Google history of the repository forward, and we offered all contributors at the time the option of our stamping their commits with a golang.org address to avoid putting their google.com addresses into the initial repo. This set of people who took us up on that offer included people not on the Go team per se, but they were all of course Google employees. The Go team members all used golang.org addresses too, mainly to try to create some distance between Go and Google, to avoid making it seem like Go was only for Google (for the same reason, the golang.org home page did not mention Google anywhere).

Since then, we've given new hires on the Go team at Google the option to use golang.org addresses. Some take that option, some don't.

That should end the community curiosity. What are the arguments for changing the rule?

[bradfitz]

What are the arguments for changing the rule?

The main argument is "to avoid making it seem like Go was only for Google", to use your words, and to make the community feel more inclusive.

There are certainly downsides of giving them out more widely (cost? writing a policy? maintenance?), but it might be worth it if for community goodwill. Not sure.

[spf13]

In agreement with Brad, I think the golang email address should be given
out by effort, not employment.

A golang email is the ultimate sign of inclusion into the project. By
giving someone one we are telling them they are part of the project in a
very real and visible way.

I'll draft a proposal for golang accounts. Ultimately I think this is the
highest achievement and should be part of a larger strategy of mentoring
and enabling contributors. I'll write the proposal for just this specific
thing but acknowledging that it should fit as part of a larger framework.
On Mon, Apr 16, 2018 at 4:20 PM Brad Fitzpatrick [e-mail]
wrote:

What are the arguments for changing the rule?

The main argument is "to avoid making it seem like Go was only for
Google", to use your words, and to make the community feel more inclusive.

There are certainly downsides of giving them out more widely (cost?
writing a policy? maintenance?), but it might be worth it if for community
goodwill. Not sure.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/go/issues/24850#issuecomment-381735371, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKlZGkFlDpd-AHI3Zzvsqcjyu_xWQw9ks5tpP0bgaJpZM4TUPJk
.

[namusyaka]

Awesome!

[spf13]

I've given it quite a bit of thought and I think there's a very clear policy to be put into place here.

Having a golang.org account is the ultimate conveyance that you are part of the project and act as a representative of the project independent of employer.

Similarly, the ability to +2 a change carries a similar conveyance and connotes that you are a critical part of the project and similarly represent the project.

The policy to receive a golang.org account should be paired with the ability to +2 a change. If you have been given the approver rights, then you should be given the option of having a golang.org account. This account will remain yours regardless of employment status or changes. The project leadership can remove your golang.org account for violations of the code of conduct or similar abuse.

This is a bit of a deflection of the goal here as it requires another policy to be defined, however I believe that policy is, at least in practice, better defined. The short term consequence, if this proposed policy is approved, is that a handful of people who have the approver bit today will be invited to have a golang.org account.

[spf13]

We discussed this in the proposal review meeting today. After the discussion with @golang/proposal-review I'm convinced that my proposal isn't correct.

The argument was made that there should be a separate requirement for the +2 ability and the golang.org account because they have different criteria. @rsc mentioned that there's a good argument to make that we should give out +2 more liberally than we do today and doing so would be good for the project. It's clear that giving out golang.org accounts more liberally (or as liberally as the +2 ability) would not necessarily be good for the project. Linking these two would needlessly result in having fewer +2 able people which would be detrimental to project community inclusion.

We decided that the best thing to do today is simply to codify the historic policy as it has been used in practice.

The policy for golang.org accounts is as follows.
Golang.org email accounts are available to people who join the Go language team at Google. Once the golang email account is used, will remain in place even if the employee leaves the Go team or Google as we believe it is good for email accounts to persist and we hope the individuals continue to be a part of the project. The Go team leadership can remove the account if it is being abused.