doc: add a powers.md to document who has access

[gibfahn]

Initial stab at covering who has access to what.

Outstanding questions:

• @bnoordhuis has read access to nodejs/secrets, as he's an org owner I assume this is no longer necessary? EDIT: Yep, historical, removed him.
• is release-* the same group as infra-*? I think it is, but looking at the commit history I'm not sure. EDIT: It's not
• what about website access? Is there any special access that people have that we should document?

Follow-on proposal: we could create sub-teams of @nodejs/build to list the groups of people who have access to things (which saves having lists of names in this document). I think it's just nodejs/infra-admins (which have access to release-* and infra-*) but I'm not sure.

Refs: #798 (comment)

[rvagg]

might be a bit picking and this is just a suggestion, but maybe "powers" isn't the best name here, "access" or similar might be a bit more .. gentle?

also, who do those links to the team members work for? what level of access does someone need to be able to see who is in jenkins-admins for example and do we care for example if non-collaborators can't see that?

[mcollina]

👍 on access.

Also, is there a crash course on the infra or some documents I can read. According to this doc, I have access to the infrastructure secrets and keys. However, there is little guidance in the CTC onboarding process on those.

Moreover, is there a process to revoke access? In other terms, how do we rotate keys?

[piccoloaiutante]

I like access or even infra-access.md.

@rvagg it seems to me that in order to seejenkins-admins you need to be at least a member of the org. I think that having jenkins-admins not seen by non-collaborators isn't a big issue, as if a new comer needs to contact someone in the team can always ask in issues or irc.

@mcollina I got onboarded by @jbergstroem and @joaocgreis. Maybe would be a good idea to arrange one with you.

[gibfahn]

also, who do those links to the team members work for? what level of access does someone need to be able to see who is in jenkins-admins for example and do we care for example if non-collaborators can't see that?

@rvagg They only work for org members. It would be great if they were public, but that's a Github thing, so there's not much we can do. The only question is whether it's better to have them or not. I'd say it's better to have them. I can add a sentence explaining that if it'd be helpful.

EDIT: I added an explanatory sentence and emailed Github to ask if it could be made public, I think that's about all that can be done.

Also, is there a crash course on the infra or some documents I can read.

@mcollina This is my first attempt at having build WG documentation. I figured we needed to work out what we actually have before we talk about how to do stuff.

EDIT: I should clarify that there is a tonne of really good technical documentation in ansible/, which @jbergstroem added. However to understand how to use that you already have to know quite a lot of stuff.

According to this doc, I have access to the infrastructure secrets and keys. However, there is little guidance in the CTC onboarding process on those.

You have access to the secrets repo, but not to the gpg encrypted secrets within. Access is documented in that repo, which I think is the best place for it. If it's inadequate then we should add to that repo's docs. I'll add a sentence saying that.

FWIW I don't think it's particularly intentional that org owners have access, it's just how Github works. You won't actually be able to decrypt any of the files inside it.

[mcollina]

EDIT: I understand now. It needs to be reworded and explained. Having access to the secrets repo means nothing, but given it is under "Machine Access" heading it seems to refer to machine access, not to the secrets repo.

[gibfahn]

For a list of machines, see the [inventory.yml][]. Access is controlled through the [secrets repo][], which [@nodejs/build][] (and [org owners][]) have access to.

You have access to the repo, just not to the individually encrypted secrets within. I've tried to clarify, does it make more sense? If not please suggest some text (I don't want to get too verbose here).

[mcollina]

How about

Access to the secrets repo does not imply access to the machines themselves.

[gibfahn]

I changed powers.md to access.md. I quite liked powers, reminded me of superpowers (which is apt, as with other superpowers, it usually means you have to fix stuff at inconvenient hours etc.) But access is fine too (just bland).

[gibfahn]

@mcollina okay I pretty much added that, PTAL.

[mhdawson]

In terms of employer, I don't think we want to add that as its not necessarily tied to why/who has access. Having is discover-able through the github profile is good though.

[gibfahn]

Generally LGTM. Thought: do we want to add employer or is that perhaps better expressed through a GitHub profile? A few of us have "keys to the kingdom" of sorts.

I agree with @mhdawson that adding the employer gives the wrong impression, people don't have access because of their employer. At the same time I think we should definitely be open about who we work for. Making sure everyone has it clearly documented in their Github profile would be good.

Github allows you to fill in the company field in https://github.com/settings/profile, maybe we should encourage everyone to fill it in.

[gibfahn]

@rvagg I'd like to land this, any objections?

Answers to the questions in my initial comment would be great too!

[jbergstroem]

No objections to landing as-is. Let me try and answer other outstanding questions.

@gibfahn said:
@bnoordhuis has read access to nodejs/secrets, as he's an org owner I assume this is no longer necessary?

I would agree. He was historically very active in part of the creation of io.js and the general structure of all repos. I would guess this is the remnant of that.

@gibfahn said:
what about website access? Is there any special access that people have that we should document?

Guessing you're referring to updating the website. This is handled through the website group in this repo: https://github.com/nodejs/nodejs.org as well as work that is done and landed through the build team for building those assets.

[gibfahn]

Landed in efb11cc ef1f863