Set up the Crowdin-GitHub integration together, and record it

[zeke]

Since we haven't yet set up our Crowdin-GitHub integration, I was thinking we could walk through it together in our next working group meeting.

As a prerequisite, we'd need to make the @nodejs-crowdin GitHub user the new owner of https://crowdin.com/project/nodejs, instead of @obensource. That will allow multiple members of our working group to log in an administer the account. @Andrulko are you able to make this change for us?

PS When is our next meeting?

[obensource]

@zeke my boss just assured me that I can spend a bit of time each week supporting our great work here–and joining in our meetings! Wahoo! 🙌

Let's schedule our next meeting asap and get this going. 🎉

[Andrulko]

Hey @zeke and @obensource!

Just made the first step, main account is renamed to nodejs-crowdin:
https://crowdin.com/profile/nodejs-crowdin

@obensource, it's still linked with your email address and you may change the avatar/email address in the profile settings:
https://crowdin.com/settings#account

Afterward, create new obensource account here and assign yourself as a manager.

Create @nodejs-crowdin user on GitHub, then log in under nodejs-crowdin main account and setup GitHub integration from @nodejs-crowdin GitHub user name. It sounds complicated as I see, but it should be very easy 😉 I'm always ready to join the meeting with you to assist with setup!

[amorist]

so nice, joined nodejs-crowdin !

[ryo-a]

the icon of nodejs-crowdin is still obensource's one.
it is desirable that someone (has permission) change the icon.

[Andrulko]

It is a great avatar I must say! But if necessary, @obensource can update profile picture here:
https://crowdin.com/settings#account

[zeke]

Hey @Andrulko I just logged in to Crowdin using GitHub OAuth with the GitHub user @nodejs-crowdin for which our group now has shared credentials. It prompted me to "sign up", so I used this info:

Sorry for the confusion, but can you update the nodejs crowdin project to use this new user as the owner?

[zeke]

Hopefully we can get this sorted soon so we can get a running start during our meeting next Tuesday.

[Andrulko]

Hey @zeke,

The nodejs-crowdin username was earlier taken by @obensource, thus you were prompted to specify another username.

I will contact you privately and help to link GitHub OAuth with existing account

[zeke]

We worked it out. All good now!

[FranzDeCopenhague]

This is great! https://crowdin.com/project/nodejs

I have found another project at crowdin https://crowdin.com/project/nodejs_ru
Is it related to our i18n group?

[zeke]

Is it related to our i18n group?

Not that I know of.

cc @artcygn who appears to be the owner. 👋

[zeke]

Earlier today, I attempted to connect the @nodejs-crowdin GitHub user to Crowdin, but had to request access.

@bnb or @rvagg do you know who might have received this request?

[rvagg]

Yeah, so this is where we break down, if they need org access with that "request" button then it goes to org owners (TSC++) and we have a general rule of not giving access to third-party services. We've been using the nodejs-github-bot to work around this for various things.

@nodejs-crowdin has requested approval for a third-party application to access Node.js Foundation organization resources via the GitHub API:

"Crowdin" from crowdin

Until it is approved, this application will have no access to private resources and will have read-only access to public resources belonging to your organization.

Perhaps the TSC would be more comfortable giving access to the org now that we've moved most of the sensitive private repos to a new org. Although I think we still have some (like moderation?), and the easy-path for security has just been a blanket no to third-party access. Are you able to get more information on what this requires from the org and what kind of access it'll actually have? Will it be limited to only what we give @nodejs-crowdin access to or if the org owners give this permission does that mean it has permission to reach in more deeply, beyond what @nodejs-crowdin has access to?

[zeke]

Are you able to get more information on what this requires from the org and what kind of access it'll actually have?

☝️I'll defer to @Andrulko from Crowdin for a definitive answer to this.

[Trott]

FYI, I used the "deny access" button on the request just like for everything else that's ever requested access to private info. But there's absolutely no reason someone (including me) can't edit the entry for this integration to grant access once all the info is gathered and the TSC gives a 👍 on it.

[Andrulko]

Hi everyone,

I've got some explanations from developers and will try to describe the process below:

In case the third-party applications are not allowed under GitHub organization settings, of course not approved apps won't have the access to organization. Consequently, it's necessary to approve Crowdin application to be able to setup a GitHub <-> Crowdin integration.

Crowdin app requires read/write permissions to the repos and read/write permissions to webhooks. If the user (i.e. nodejs-crowdin) don't have the access to the specific organization's repository, then authorized application (connected through this user) won't have the access to that repo.

Application permissions can't overstep user's permissions, thus it's a good idea to create a separate GitHub account with access to the l10n repository and forbid everything else.

When you setup GitHub integration from this account via Crowdin, only one repository will be available for selection. 👍

[zeke]

As I understand it, the new @nodejs-crowdin GitHub account only has admin access to a single repo nodejs/i18n, so the vulnerable surface area is quote low. @rvagg is that correct?

grant access once all the info is gathered and the TSC gives a 👍 on it.

I am unfamiliar with the TSC's process. Please let me know if there's something I can do to help move the process forward.

[Trott]

I am unfamiliar with the TSC's process. Please let me know if there's something I can do to help move the process forward.

Looks like someone already added the bot to this repository so I don't think there's anything for the TSC to do, unless you needed it added org-wide or something like that.

[zeke]

Here's what I see now:

someone already added the bot to this repository so I don't think there's anything for the TSC to do

I'm not sure I understand where that leaves us. What are our options at this point for giving Crowdin organization access?

[Trott]

@zeke Are you not able to use the "Authorize crowdin" button in the screenshot you provide. IIUC, that will give the plugin access to the @nodejs-crowdin account which, as far as I know, has admin access in this repository but nothing else in the nodejs org. So that might be all you need? (Also, you might consider reducing the account's privileges to Write rather than Admin if it only needs read/write.)

I'm not sure I understand where that leaves us. What are our options at this point for giving Crowdin organization access?

@zeke If the plugin needs org access rather than merely access to this repository, you need TSC approval. (If all you need is access to this repository only, then I think you're already all set.)

You can add the tsc-agenda label to this issue and it will automatically be added to the agenda for the next TSC meeting. If you want to get it on this week's TSC agenda, request that it be added in the issue for this week's meeting which is nodejs/TSC#544.

Three things to try to make things go smoothly:

• Identify an informed advocate who can answer questions and ask that they be invited to the meeting as a guest. In this case, it might be @zeke or maybe someone else.

• Provide a short (one paragraph if possible, but sometimes things just can't be kept that short) summary to address likely questions that will come up. The TSC is likely to ask questions about exactly what the user will have access to and why there needs to be org-wide read/write access granted if the plugin just needs to read/write to a single repo. That sort of thing.

• Identify an appropriate person on the TSC who might be able and willing to understand everything ahead of time and therefore advocate at the meeting. For GitHub permissions stuff, I think @rvagg, @targos, and @gibfahn tend to have a baseline understanding and care enough to dig in and understand what's going on, at least when they have time to do so. There are no doubt others in the group. And then there are people like me, who understand just enough about GitHub plugin permissions to be able to ask annoying questions and delay things because of our own ignorance. We're the people you're trying to put at ease.

Hope this helps and sorry if it seems like a whole bunch of unnecessary work. These policies/rules were formulated when there was more information that was sensitive in the repositories within the nodejs org than there is at the current time. It's possible they should be updated. If so, pull requests with proposals are welcome. (Or open an issue in the TSC or admin repos.)

[Trott]

(Oh, I think I see: the org settings override the account privs and the plugin can't write to this repository? If that's right, then unfortunately that will probably require escalation to the TSC as described in the longer part of my answer. Sorry.)

[zeke]

Thanks for breaking it down, @Trott 👍

I labeled this issue and made a plea for the next TSC meeting: nodejs/TSC#544 (comment)

[mcollina]

@zeke can you please update this issue with a lengthy "why" explanation. Why do we need crowdin, and what can we use this for, and also why it's needed for the tsc to approve this.

[zeke]

Crowdin is a platform for automated and continuous localization, i.e. translation into different languages. The Crowdin service is free for open source projects, and provides a GitHub integration that allows content to flow automatically to and from a GitHub repo. Content changes in the repo are pulled into Crowdin automatically, and new pull requests are opened on the repo as translations are made.

Crowdin has been evaluated and approved by the Node.js i18n Working Group

Crowdin was also chosen by GitHub's Electron team after a rigorous evaluation of numerous localization providers. It was evaluated and approved not just by our team, but by GitHub's Community and Safety, Security, and Legal teams as well. See https://github.com/electron/i18n/blob/master/crowdin.md

TSC approval is needed because org-level approval of Crowdin is required to be able to integrate with the nodejs/i18n repo. See nodejs/TSC#544 (comment) for details on why this should be considered a low-risk approval.

[rvagg]

So, I'm +1 on this on the proviso that this doesn't give the service more access than the nodejs-crowdin user does that we created for this. Even reading this thread I still don't have full confidence that this is the case. That's all I care about and I'm very confident that this is all the TSC cares about too.

[mcollina]

Which repo will this be used on? Only nodejs/i18n or something else as well?

[zeke]

Only nodejs/i18n

Correct

this doesn't give the service more access than the nodejs-crowdin user does that we created for this

Also correct, as long as no one gives @nodejs-crowdin admin or write access to any more repos.

[targos]

I suppose that if someone else from the org creates a crowdin account, that would automatically give them access to all repositories that user has access to? Could we somehow use the GitHub API to monitor it?

[Andrulko]

Yes, it might be true indeed. If another person from the org will setup Crowdin account and setup GitHub integration afterward, all repositories he/she has the access to will be available for Crowdin integration. If another repo was linked with Crowdin, automatic pull requests will be sent to this repo from our end and there will be crowdin.yml configuration file created in the connected branches.

Not sure about API to track such cases unfortunately, also I have doubts that trusted people in your community will connect other repositories with third-party services like Crowdin 😉

[fhinkel]

Unless I missed a comment, nobody is -1 on adding the Crowdin plugin?

[zeke]

It would be swell if we could unblock this before the Node.js Collaborator summit later this week.

[fhinkel]

Who's blocking it?

[zeke]

Who's blocking it?

There's no individual blocking it. The TSC is just being (understandably) cautious about giving third-party access to the @nodejs GitHub org.

[zeke]

This happened! Recording forthcoming.