Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
bradfitz opened this issue Apr 13, 2018 · 10 comments
Closed

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

bradfitz opened this issue Apr 13, 2018 · 10 comments
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge Proposal
Milestone

Comments

@bradfitz
Copy link
Contributor

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

@gopherbot gopherbot added this to the Proposal milestone Apr 13, 2018
@gopherbot gopherbot added Proposal Documentation Issues describing a change to documentation. labels Apr 13, 2018
@mvdan
Copy link
Member

mvdan commented Apr 13, 2018

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

@namusyaka
Copy link
Member

@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
Copy link
Contributor Author

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
Copy link
Member

CC @spf13

@rsc
Copy link
Contributor

rsc commented Apr 16, 2018

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
Copy link
Contributor Author

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
Copy link
Contributor

spf13 commented Apr 17, 2018 via email

@namusyaka
Copy link
Member

Awesome!

@spf13
Copy link
Contributor

spf13 commented Apr 18, 2018

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
Copy link
Contributor

spf13 commented Apr 23, 2018

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.

@spf13 spf13 closed this as completed Apr 23, 2018
@spf13 spf13 removed the Proposal label Apr 23, 2018
@golang golang locked and limited conversation to collaborators Apr 23, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Documentation Issues describing a change to documentation. FrozenDueToAge Proposal
Projects
None yet
Development

No branches or pull requests

8 participants