Initial write-up for member audit

[RRosio]

No description provided.

[manics]

I think this makes sense. JupyterHub kind-of has a policy for following up on inactive members, though I can't remember the last time we followed it: https://jupyterhub-team-compass.readthedocs.io/en/latest/practices/check-ins.html

What might be worth doing in this policy is emphasizing that GitHub privileges are not a reflection of project membership or status within that project. Traditionally it's been seen that way, but from a security perspective you might be one of the most important/influential people in a project, but if your role doesn't require GitHub privileges then you shouldn't have them.

[Carreau]

Sorry i'm going to stay short.
I think a user can/should be able to be marked manually as active (with a reason) on any tooling.

GitHub is uppercase G and H I believe.

[rpwagner]

This is looking good. Let's make the first goal to get this to into this repo and communicate it. Next, I'd like to propose a subsecurity section in the governance documents under Organizational Policy.

Learning from this and the 2FA implementation, we can probably draft a short guide on how to propose, decide, communicate, and implement future security policies.

[dlqqq]

@RRosio Thank you for putting this together! This is a great first start. We can make more revisions later. Just one minor comment worth addressing here. 🤗

[dlqqq]

As a reader, it's unclear how I should reach out to the Security Council to reinstate my access privileges. We should probably suggest a way to contact us here, for example:

Suggested change

	If a member's privileges are adjusted due to inactivity, they can be reinstated upon request. Our goal is to maintain security without hindering future contributions.
	If a member's privileges are adjusted due to inactivity, they can be reinstated on request via email to `security@ipython.org`. Our goal is to maintain security without hindering future contributions.

[manics]

Should this be handled via the subproject instead of the central security email?

[rpwagner]

Yes! This isn't about a security vulnerability so having it go to the mailing list is better--and more likely to be seen.

[dlqqq]

Perhaps! This ambiguity is exactly why I think we should document it here first. 😁

[JosephTLucas]

@RRosio the audit log documentation might help you find elements for the inactive criteria since that's probably how we'll automate.

[RRosio]

In today's security meeting, we proposed handling a more detailed review of membership levels as a follow-up, after first addressing inactive members.