docs(processes): security team offboarding #305
Conversation
| * After 4 weeks those who haven't responded to the issue will be placed in a pending status ('emeritus') | ||
| * After 4 weeks those who haven't responded to the issue will be removed from the WG (see `Revoking Access to Confidential Systems` section for details on access removal check-list) | ||
|
|
||
| At any time until the last time mark any member can chime in and request to retain his membership without requiring consensus reaching by the WG. |
|
|
||
| ## Process | ||
|
|
||
| Every P period of time the WG will run through a process of validating membership relevancy as follows: |
| ## Revoking Access to Confidential Systems | ||
|
|
||
| The following is a check-list for which existing WG members should be removed access from: | ||
| * [ ] Remove user from [Repo README](https://github.com/nodejs/security-wg/blob/master/README.md), [Triage Team](https://github.com/nodejs/security-wg/blob/master/processes/third_party_vuln_process.md), [Security Team List](https://github.com/nodejs/security-wg/blob/master/processes/security_team_members.md), [GitHub CodeOwners](https://github.com/nodejs/security-wg/blob/master/.github/CODEOWNERS), |
There was a problem hiding this comment.
We can have an emeritus section
There was a problem hiding this comment.
Where do you think it's best to add it?
There was a problem hiding this comment.
Either at the end of the README, either in another doc. wdyt?
There was a problem hiding this comment.
to begin with we can probably just document it in this doc that discusses 'offboarding' to not juggle through too many doc files
|
|
||
| * An issue will be posted on the WG Repository that will mention all existing WG members to query whether participation in the WG is still relevant. | ||
| * After 2 weeks a reminder notice will be posted | ||
| * After 4 weeks those who haven't responded to the issue will be placed in a pending status ('emeritus') |
There was a problem hiding this comment.
emeritus is not really a pending status, instead a remaining recognition of the contributions made once they have been removed.
There was a problem hiding this comment.
thanks for clarifying. do you think the following is clearer?
* After 2 weeks a reminder notice will be posted
* After 8 weeks those who haven't responded to the issue will be removed from the WG (see `Revoking Access to Confidential Systems` section for details on access removal check-list) and be recognized as emeritus members.
I thought it makes sense that we will just move members who haven't responded to an emeritus recognition list instead of moving them after 4 weeks, then deleting them from that list when they chime in in the last 8 weeks period.
There was a problem hiding this comment.
What I had in mind was, move to emeritus after 4 weeks and just leave them there forever (which is what we do elsewhere) and remove all access at the same time. If in the next 4 weeks they ask to be added back then we restore them.
There was a problem hiding this comment.
it means that effectively the grace time is really 8 weeks, so if we have to restore someone's access after removing everything isn't it just extra work? It will probably be a rare case anyway so I'll update the texts as you suggested with clarifying the 4 weeks middle period:
* After 2 weeks a reminder notice will be posted as an issue in this repository
* After 4 weeks move all of those who have not responded to emeritus
* Allow an additional 4 weeks grace period where people can request to be added back without requiring consensus reaching by the WG. Once the period is over, those who haven't responded to the issue will be removed from the WG (see `Revoking Access to Confidential Systems` section for details on access removal check-list) and kept as emeritus members.
^ @mhdawson how's that?
|
@vdeturckheim @mhdawson I removed the |
Formalizing the user removal process as depicted in #302.