Describe the memorialization procedure #1516
Next
Next commit
Describe memorialization procedure
- Loading branch information
commit 481e1f03b540c1dd6d43e654b6ba32fd0f246303
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -13,3 +13,4 @@ Core developers | |
| developer-log | ||
| motivations | ||
| become-core-developer | ||
| memorialization |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,132 @@ | ||
| .. _memorialize-core-developer: | ||
|
|
||
| =============== | ||
| Memorialization | ||
| =============== | ||
|
|
||
| Rationale | ||
| ========= | ||
|
|
||
| When a core developer passes away, memorializing accounts helps create | ||
| a space for remembering the contributor and protects against attempted | ||
| logins and fraudulent activity. | ||
|
|
||
| The process | ||
| =========== | ||
|
|
||
| The memorialization process is performed by a member of the PSF staff | ||
| with administrative access to current and historical systems where | ||
| core developers have access. | ||
|
|
||
| After the status of the core developer in question is confirmed, | ||
| access to the systems listed below is revoked and some changes are | ||
| made to how the user displays to others. | ||
|
|
||
| To respect the choices that someone made while alive, we aim to preserve | ||
| content of their accounts without changes after they've passed away. | ||
| To support the bereaved, in some instances, we may remove or change | ||
| certain content when the legacy contact or family members request it. | ||
|
|
||
| GitHub | ||
| ------ | ||
|
|
||
| * The user is removed from the `python/ <https://github.com/orgs/python/>`_ | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| organization on GitHub; | ||
| * The user is removed from the `psf/ <https://github.com/orgs/psf/>`_ | ||
| organization on GitHub; | ||
| * The user is removed from the `pypa/ <https://github.com/orgs/pypa/>`_ | ||
| organization on GitHub. | ||
|
|
||
| The PSF staff does not follow up with GitHub with regards to GitHub account | ||
| cancellation as this action is reserved for next-of-kin or designated by | ||
| the deceased GitHub user to act as an account successor. | ||
|
|
||
| The general policy regarding deceased users on GitHub is described | ||
| `here <https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy>`_. | ||
|
|
||
| CPython repository | ||
| ------------------ | ||
|
|
||
| * The user's GitHub handle is removed from ``/.github/CODE_OWNERS``. | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * The user is marked as deceased in the private | ||
| `voters/python-core.toml <https://github.com/python/voters/blob/main/python-core.toml>`_ | ||
| file with the ``left=`` field set to the day of passing, if known. | ||
|
|
||
| discuss.python.org | ||
| ------------------ | ||
|
|
||
| * The user's "custom status" is set to 馃晩 ``in memoriam``; | ||
| * The user's "about me" is amended with ``$firstname passed away on $date. [In memoriam.]($in_memoriam_post_url)``; | ||
| * In the user's security "recently used devices" the staff member chooses "Log out all"; | ||
| * In the user's permissions the staff member chooses "Deactivate account"; | ||
| * The user's trust level is reset to ``1: basic user`` (trust level 0 doesn't allow links in "About Me"); | ||
| * The user's "associated accounts" (like GitHub) that provide an alternative | ||
| login method, are all disconnected; | ||
| * The user's API keys are revoked; | ||
| * The user's admin or moderator right is revoked; | ||
| * The user's primary email address is reset to ``username@in-memoriam.invalid`` and | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| secondary email addresses are removed (this step requires the administrator | ||
| to contact Discourse.org staff via ``team@discourse.org``) | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| The "in memoriam" Discourse topic mentioned above is best created by | ||
| a community member close to the deceased. | ||
|
|
||
| The general best practice for deceased community members on | ||
| Discourse-powered forums is described `here <https://meta.discourse.org/t/best-practices-for-deceased-community-members/146210>`_. | ||
|
|
||
| python.org email account | ||
| ------------------------ | ||
|
|
||
| The PSF staff member emails ``postmaster@python.org`` to ask the email | ||
| administrator to: | ||
|
|
||
| * remove SMTP access from ``USERNAME@python.org``; | ||
| * reset the password to POP3/IMAP for ``USERNAME@python.org``; | ||
| * disable email forwarding, if set up, for ``USERNAME@python.org``; | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| * remove this email from all mailing lists under ``@python.org``; | ||
| * remove any known alternate emails for the same user from all mailing lists | ||
| under ``@python.org``. | ||
|
|
||
| python.org admin | ||
| ---------------- | ||
|
|
||
| * The user's account (``/admin/users/user``) is deactivated (NOT deleted) | ||
| and their staff and superuser status is unchecked; | ||
| * The user's password is reset to a long random string; | ||
| * The user's primary email address is set to ``USERNAME@in-memoriam.invalid`` | ||
| and set as unverified; | ||
| * The user's secondary email addresses are deleted; | ||
| * The user's API keys (both on the account and ``tastypie``) are deleted; | ||
| * The user's "I would like to be a PSF Voting Member" field is cleared. | ||
|
|
||
| devguide.python.org | ||
| ------------------- | ||
|
|
||
| * The user is marked as deceased in `developers.csv <https://github.com/python/devguide/blob/main/core-developers/developers.csv>`_; | ||
| * The user is removed from the `Experts Index <https://github.com/python/devguide/blob/main/core-developers/experts.rst>`_. | ||
|
|
||
| bugs.python.org | ||
| --------------- | ||
|
|
||
| While the issue tracker was migrated to GitHub, the Roundup instance | ||
| is still up for historical purposes. | ||
|
|
||
| * the PSF staff member logs into ``bugs.nyc1.psf.io``; | ||
| * the PSF staff member runs ``roundup-admin`` to set the user's email | ||
| address to ``USERNAME@in-memoriam.invalid``; | ||
| * the user's alternate emails are removed; | ||
| * the user's password is reset to a long random string; | ||
| * the PSF staff member removes any active login sessions from Postgres. | ||
|
|
||
| SSH server access | ||
| ----------------- | ||
|
|
||
| * The user is removed from Salt configuration for the PSF infrastructure | ||
| in `/pillar/base/users <https://github.com/python/psf-salt/tree/main/pillar/base/users>`_. | ||
|
|
||
| PyPI | ||
| ---- | ||
|
|
||
| * The PSF staff member notifies PyPI admins to mark the user as inactive, | ||
ambv marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| remove their email addresses, prohibit their password resets, and | ||
| revoke all API keys. |
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There might also be tokens created by the user for specific services (GH actions, bots, hooks). Maybe a paragraph should be added about checking for (and possibly remove/replace them) those too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree in principle, but I don't know how to actually enforce it. For OAuth app tokens, it's impossible to remove a token only for a single person. We rather clean this via disconnecting the user's GitHub from their Discourse account and logging them out, etc.
For GitHub app tokens and private keys requested by a concrete user, I don't know how to vet this other than clicking through every GH app on every repository. What do we expect to do in this case? Invalidate every token? I expect that the user who created such a private key or token only used it to put it in the GH app's secrets and was not otherwise stored by them locally, but of course that might be wrong.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked the secrets on a repo and there doesn't seem to be any indication of who generated/added the token, and indeed it shouldn't matter too much who does it.
Maybe this is an issue about documenting who manages these services (and is therefore in charge of managing the tokens), so that someone else can take over if needed. (Some of these are already documented in the devguide.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that was my worry too, that tokens don't tell you who generated them without consulting the audit log. Agreed on documenting who manages the services, I think that's sufficient along with tokens auto-expiring and refreshing.