omniauth organization setup

[bufferoverflow]

We need to define some policies to manage omniauth account, so I've created the omniauth-org repo to manage such topics:

• start of the omniauth organization: Future maintainership omniauth-saml#67 (comment)
• on boarding of omniauth OmniAuth Community organization omniauth#836
• on boarding of omniauth-instagram New Maintainers omniauth-instagram#28
• how to on boarding of other omniauth strategies?

/cc @md5 @tmilewski @sferik @ropiku @danwiding @supernova32

[tmilewski]

One thing we need to keep in mind when transferring repositories over to the omniauth organization is that we'll also require access to cut new gems.

[md5]

Here's what I think moving a gem into the organization should look like:

1. Create a new team in the organization for the gem maintainers
2. Add all maintainers to the team
3. Request that the maintainers add an Omniauth organization owner as an Outside Collaborator with Admin privileges
4. Owner transfers the repository to @omniauth
5. Owner grants the new team Admin access to the transferred repository

It's possible that there may be cases where we want an "admin" team that is separate from the "write" team for a particular gem or set of gems. It's also possible that step 3 and 5 may be unnecessary since we allow members to create new repositories. I believe that allows them to assign privileges to teams they are part of.

[md5]

@tmilewski I think the discussion of whether anyone needs to grant access to deploy gems is separate. I don't see the purpose of this organization as being centralized management of all things Omniauth, but rather an umbrella that makes it easier to find Omniauth-related gems.

[tmilewski]

@md5 [Happy to move this to another thread, if need be.]

I completely agree that the organization's goal shouldn't be around centralized management.

I only mentioned that due to the fact that I think we've all seen a number of OA gems go unmaintained for some time. Heck, some were sitting on major security issues for years.

I feel that having the ability to update access, enabling (new) maintainers to cut gems, is important. Limiting that to the maintainers listed each respective team sounds good to me so long as it's two or more.

---

This all comes from personal experience wherein one sole person had access to cut OA gems and was 100% MIA. I simply couldn't get a hold of said person despite attempting to contact them via multiple mediums.

[andrewshadura]

Hi,
I just wanted to bring to your attention:

• Maintenance and forks omniauth_openid_connect#101
• RubyGems project name? jjbohn/omniauth-openid-connect#90

I think OpenID Connect is important enough to have it under the maintenance of the organisation and not an individual.