Rename 2i2c-imagebuilding-hub-access org to 2i2c-demo-hub-access

[sgibson91]

Context

Some of our hubs utilise GitHub orgs/teams to manage authentication/authorisation. In the GitHub ecosystem, to add someone to a team, you also have to add them to the parent organisation. This is not something we always want to do, especially in cases where we want to give access for demo purposes. It is because of this reason that the 2i2c-imagebuilding-hub-access org was created, in order to give demo access to a hub showing our newly developing image building capabilities without granting access to the main 2i2c org.

While working on transferring the researchdelight hub to be called showcase (https://github.com/2i2c-org/infrastructure/issues/3279), I discovered that we have "research-delight-team" and "research-delight-gpu-team" within our 2i2c org and concluded that this hub and the partnerships team may want a similar flexibility: to add people to these teams to demo the showcase hub, without granting access to our main 2i2c org.

However, the "imagebuilding" part of the org name then becomes overloaded.

Proposal

We rename the "2i2c-imagebuilding-hub-access" org to "2i2c-demo-hub-access" and document that this is where we create teams and add external collaborators when we wish to grant them hub access for demo purposes. This could include the showcase hub, or others.

Updates and actions

• [x] Agree this a reasonable path forward
• [x] Make the change to the GitHub org
• [x] Add a minimalist Readme repo to the GitHub org explaining its purpose
  • https://github.com/2i2c-demo-hub-access/.github
• [ ] Add docs to our team compass explaining this

[sgibson91]

Ping @yuvipanda as the person who set up this org

[yuvipanda]

I am totally ok with this if we document that giving access to one kinda demo hub gives people access to all. I think that is perfectly alright, just needs to be documented.

do you have enough rights to do this rename, @sgibson91? If not i will make sure to grant you requitise rights

[sgibson91]

Yes I have the power!

if we document that giving access to one kinda demo hub gives people access to all

Indeed. We could also set a default of using teams-based auth for these hubs, since then it won't be access to one is access to all. But can fallback to org access with good reason and understanding that that is what you're explicitly allowing.

[yuvipanda]

Great! I am ok with wide org or team based access as you see fit and document :)

thanks for thinking this through and simplifying it!

[yuvipanda]

Great! I am ok with wide org or team based access as you see fit and document :)

thanks for thinking this through and simplifying it!

[jmunroe]

Having external organization to control access to our 2i2c managed hubs is wise. The users on researchdelight showcase are not "demo" accounts though. The intent of showcase is to build a Community of Hub Champions.

Could we shorten the name of this other organization to just 2i2c-hub-access to make it clear that this org's purpose is control access to hubs directly managed by 2i2c?

[sgibson91]

@jmunroe we talked a little bit about this in sync today. I hear your concerns that particularly users of the showcase hub are not ephemeral demo users, and you hear my concerns that generalising to just "hub access" may accidentally create the impression that everyone needs to belong to that org for access. Naming things is hard, and I'm very happy to have another call with you to talk through other options :)

[jmunroe]

Ok, let's keep the org named as 2i2c-demo-hub-access and use it for actually "demo" access. For the other use cases of showcase.2i2c.org, I can create separate GitHub organizations that are more tightly scoped to their intended purpose.