Future maintainership

[ilikepi]

However, as a longer term solution I'd like to figure out what org or user account this gem should belong to. If you'd like to take active ownership speak up.

The current maintainer is @danwiding, but in a comment on #66 he stated a desire to discuss a possible transfer of that responsibility. I figured it makes sense to hold that discussion in its own issue, so here we are.

Here was my initial response, in full:

If no one organization wants to take over maintainership, it might make sense to follow the model adopted for Ryan Bates' CanCan gem. In that case, the community basically created its own organization to hold their fork. They also renamed the gem, presumably since they did not have access to the original on rubygems.org, but perhaps that step would not be necessary in this case.

[suprnova32]

@danwiding I would like to take maintainership of this gem. I don't think renaming it's the best way to go, since all omniauth related gems follow the same naming convention.

@danwiding I also checked on RubyGems, and I don't have access there to release a new version. Do you think I could get access there as well?

EDIT: I have been authorized to say that GitLab is interested in taking over the gem, so if you agree it would be moved to the GitLab org where I would be the main maintainer.

[danwiding]

Hey @supernova32, @brendankemp Just granted you access to RubyGems as well. And thanks for being the first volunteer :)

We should probably give the other folks a chance to respond for the sake of openness but I'll otherwise start the transfer process by end of week.

[suprnova32]

@danwiding that is great. I'll cut a new version of the gem first thing tomorrow morning. Let me know if you need anything from me for the move, if nobody else speaks up :smile:

[bufferoverflow]

I've just created https://github.com/orgs/omniauth/ so omniauth-saml can be moved later on to a new location. @supernova32 @brendankemp are added as owners as well.

[md5]

@bufferoverflow That seems like an overly broad name unless the folks at Intridea have any interest in sharing that namespace and moving intridea/omniauth and the other intridea/omniauth-* gems there.

[bufferoverflow]

@md5 just added you and @dosire as well.

Yes, it is a broad name. However it's not a problem to have just an omniauth-saml repo there. The advantage of such a broad name would be that other authentication strategies can join as well and of course omniauth itself as well if they like.

[dosire]

I like it.

[suprnova32]

@bufferoverflow I seem to only have member access to the omniauth org. Can you correct that?

[md5]

@supernova32 I've made you an owner. I'm still hesitant to stick with the name "omniauth" without consulting the maintainers of the Omniauth gem itself, but it's easy enough to change if there's consensus.

[danwiding]

It looks like there is rough consensus around moving the repo into the omniauth org. To transfer ownership to a different org it looks like the person doing the transfer must have admin status in both orgs. @md5 or @bufferoverflow could you up my access level there (assuming I've understood the plan correctly). Also let me know when is best to do the transfer, though as default answer I'd fire off the transfer as soon as I have sufficient privileges.

[bufferoverflow]

@danwiding just added you as owner of omniauth org and I think transfer can be done now

[bpedro]

I'm happy about this as I don't have time myself to contribute as much as I would like to.

Thanks!

[danwiding]

Done

[md5]

@danwiding :+1:

I've gone ahead and created an omniauth-saml-maintainers team within this organization and given it "Admin" access to the omniauth-saml repository. I haven't yet added any users to it since you all have owner access and I'm not sure whether everyone else thinks this is a good idea.

If this organization grows to encompass other omniauth-* gems, I think it's best if users are added to individual teams that have admin access over the appropriate gems instead of getting owner access for the whole organization. I'd be happy to relinquish my owner access to the organization at some point if that makes sense. Otherwise, I can just delete the team if you all think it's unnecessary.

[md5]

Does anyone object to me opening an issue at intridea/omniauth to broach the topic of our new omniauth organization and whether they would want to partcipate (possibly moving the main gem to omniauth/omniauth)?

I feel like it would be good to get Intridea's input instead of operating "under the radar" and ruffling someone's feathers down the road.

[suprnova32]

I think it's a good idea.

[ilikepi]

:+1:

On Feb 9, 2016, at 20:15, Patricio Cano [email protected] wrote:

I think it's a good idea.

— Reply to this email directly or view it on GitHub.

[bufferoverflow]

@md5 great idea please do so.

[md5]

I've opened an issue here: https://github.com/intridea/omniauth/issues/836

[bufferoverflow]

@md5 @supernova32 we should finalize this, I suggest the following:

• we do not merge anything without approval from at least one other maintainer (@md5 @supernova32 @bufferoverflow)
• we adopt the maintainers, that are allowed to push on rubygems
• we add a MAINTAINERS.md file including our GPG public keys finger prints
• we adopt https://github.com/omniauth/omniauth-saml/blob/master/omniauth-saml.gemspec
• we go through https://bestpractices.coreinfrastructure.org/projects/1611
• we adopt and improve continously

/cc @tmilewski