Making team members public ?

[Carreau]

Hey there !

I didn't realise the jupyter-server was in it's own org now ! Congrats !

Two things: 1) I realised when visiting https://github.com/jupyter-server, that only two person have their status as part of the team public, I know it's visible on the team compas, but maybe you want to make it public there as well.

2) And this is more for my own information, any reason for another org, and not using github teams ? I'm sure you discussed it and I was wondering if you have notes. As part of the security work, I realised it's much more painful to work across orgs than across teams.

Thanks !

[welcome[bot]]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! :hugs:
If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively. You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! :wave:
Welcome to the Jupyter community! :tada:

[Zsailer]

Thanks, @Carreau!

I realised when visiting https://github.com/jupyter-server, that only two person have their status as part of the team public, I know it's visible on the team compas, but maybe you want to make it public there as well.

Thanks for mentioning this! I think each team member has to configure this themselves, right? I believe the default is set to private when inviting a team member. I'll mention this during the Jupyter Server meeting to ensure that more people set their membership to public.

And this is more for my own information, any reason for another org, and not using github teams ? I'm sure you discussed it and I was wondering if you have notes.

Good question.

I think the Jupyter Server team has outgrown the Github team model. Here is a couple of reasons I see:

• We were starting to collect more repositories that fall under this team's responsibility and governance. Having those in own own separate org make this demarcation more clear and cleaner to manage.
• Creating new (experimental) repos under the Github "Jupyter" namespace is questionable—it isn't clear if this action needs steering council approval. This has been brought up a few times in our team's history. The "Jupyter" Github org seems to be a higher ranked namespace in many people's minds.

While we could use Github Teams and blend ourselves into the Jupyter Github Org, it seemed to present a lot more friction than creating a separate org where we could operate more autonomously (of course, still under the broader Jupyter governance model). In the end, operating in a separate org made things more lightweight for this team's needs.

As part of the security work, I realised it's much more painful to work across orgs than across teams.

I'd love to brainstorm ways we could alleviate this pain in a multi-org model. I think it's the job of the Software Steering Council representative for each subproject (in the new governance model) to relay things like security issues back to their team.

[vidartf]

There hasn't been any further activity here, so closing as finished/stale.