Skip to content
Merged
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions core-developers/index.rst
Original file line number Diff line number Diff line change
Expand Up @@ -13,3 +13,4 @@ Core developers
developer-log
motivations
become-core-developer
memorialization
134 changes: 134 additions & 0 deletions core-developers/memorialization.rst
Original file line number Diff line number Diff line change
@@ -0,0 +1,134 @@
.. _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
------
Comment on lines +30 to +31
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.)

Copy link
Contributor

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.


* The user is removed from the `python/ <https://github.com/orgs/python/>`_
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>`_.

Repositories in the organization
--------------------------------

* The user's GitHub handle is removed from ``/.github/CODEOWNERS``.
To see all that need action, perform
`this query <https://github.com/search?q=org%3Apython+path%3A**%2F.github%2FCODEOWNERS+USERNAME&type=code>`_.
* 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 ``[email protected]`` and
secondary email addresses are removed (this step requires the administrator
to contact Discourse.org staff via ``[email protected]``)

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 ``[email protected]`` to ask the email
administrator to:

* remove SMTP access from ``[email protected]``;
* reset the password to POP3/IMAP for ``[email protected]``;
* disable email forwarding, if set up, for ``[email protected]``;
* 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 ``[email protected]``
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 ``[email protected]``;
* 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,
remove their email addresses, prohibit their password resets, and
revoke all API keys.
Loading