py-pdf · stefan6419846 · Feb 9, 2025 · Jan 25, 2025 · Jan 28, 2025
diff --git a/.github/SECURITY.md b/.github/SECURITY.md
@@ -6,8 +6,11 @@ Security fixes are applied to the latest version.
 
 ## Reporting a Vulnerability
 
-If you find a potential security issue, please report it to info@martin-thoma.de
-(the current maintainer).
+If you find a potential security issue, please report it using the
+[private vulnerability reporting](https://docs.github.com/en/code-security/security-advisories/guidance-on-reporting-and-writing-information-about-vulnerabilities/privately-reporting-a-security-vulnerability) feature of GitHub to
+automatically inform all relevant team members. Otherwise, please
+get in touch with stefan6419846 through e-mail (current maintainer,
+address in GitHub profile).
 
 We will try to find a fix in a timely manner and will then issue a security
 advisory together with the update via GitHub

diff --git a/docs/dev/releasing.md b/docs/dev/releasing.md
@@ -11,7 +11,7 @@ A `pypdf` release contains the following artifacts:
 ## Who does it?
 
 `pypdf` should typically only be released by one of the core maintainers / the
-core maintainer. At the moment, this is either Martin Thoma or pubpub-zz and stefan6419846.
+core maintainer. At the moment, this is either stefan6419846 or pubpub-zz and Martin Thoma.
 
 Any owner of the py-pdf organization also has the technical permissions to
 release.
@@ -61,5 +61,5 @@ The release contains the following steps:
 There is no need to wait for anything. If the CI is green (all tests succeeded),
 we can release.
 
-I (Martin Thoma) typically only release once a week, because it costs a little
-bit of time and I don't want to spam users with too many releases.
+At the moment, there is no fixed release cycle - except that we usually release
+on Sunday.
diff --git a/docs/meta/comparisons.md b/docs/meta/comparisons.md
@@ -38,10 +38,10 @@ As pypdf is free software, there were attempts to fork it and continue
 the development. PyPDF3 was first released in 2018 and still receives
 updates. PyPDF4 has only one release from 2018.
 
-I (Martin Thoma, the current maintainer of pypdf and PyPDF2), hope that we can
-bring the community back to one path of development. I deprecated PyPDF2 in
-favor of pypdf already and pypdf has now more features and a cleaner interface
-than PyPDF2. See [history of pypdf](history.md).
+Martin Thoma has worked on bringing the community back to one path of
+development. He deprecated PyPDF2 in favor of pypdf already and pypdf has now
+more features and a cleaner interface than PyPDF2. See [history of
+pypdf](history.md).
 
   [free]: https://en.wikipedia.org/wiki/Free_software
   [PyMuPDF]: https://pypi.org/project/PyMuPDF/

diff --git a/docs/meta/history.md b/docs/meta/history.md
@@ -66,7 +66,7 @@ and general project decisions.
 encryption schemes.
 
 
-## pypdf: Back to the Roots (2023-Today)
+## pypdf: Back to the Roots (2023-2024)
 
 In order to make things simpler for beginners, PyPDF2 was merged back into
 pypdf. Now all lowercase, without a number. We hope that the folks who
@@ -80,6 +80,9 @@ Compared to `PyPDF2 >= 3.0.0`, `pypdf >= 3.1.0` now offers:
 * Performance Improvements and Bugfixes
 * Page Label support
 
+stefan6419846 made his [first PR for pypdf](https://github.com/py-pdf/pypdf/pull/2022)
+in July 2023 and joined the project.
+
 
   [Mathieu Fenniak]: https://mathieu.fenniak.net/
   [pyfpdf]: https://github.com/reingart/pyfpdf

diff --git a/docs/meta/project-governance.md b/docs/meta/project-governance.md
@@ -133,7 +133,9 @@ maintainers do their best to fix that in a timely manner - please
 
 ## People
 
-* Martin Thoma is benevolent dictator since April 2022.
+* [stefan6419846](https://github.com/stefan6419846) is the benevolent dictator since January 2025
+* [Martin Thoma](https://github.com/MartinThoma) was the benevolent dictator from April 2022 to January 2025.
+  He still has most of the permissions as a fallback.
 * Maintainers:
     * Matthew Stamy (mstamy2) was the benevolent dictator for a long time.
       He still is around on GitHub once in a while and has permissions on PyPI and GitHub.

diff --git a/docs/meta/taking-ownership.md b/docs/meta/taking-ownership.md
@@ -1,16 +1,13 @@
 # Taking Ownership of pypdf
 
-pypdf is currently maintained by me, Martin Thoma. I want to avoid that
+pypdf is currently maintained by stefan6419846. We want to avoid that
 pypdf ever goes unmaintained again. This document serves as a guide to avoid
 that if I become unavailable, e.g. due to severe health issues.
 
 This currently is just an abstract scenario. I'm fine and I will likely do this
 for several more years, but I have seen how projects stand still for many years
 because of the maintainer becoming inactive.
 
-I've also followed the [GitHub Deceased User Policy](https://docs.github.com/en/site-policy/other-site-policies/github-deceased-user-policy)
-and added a [pre-designated successor](https://docs.github.com/en/account-and-profile/setting-up-and-managing-your-personal-account-on-github/managing-access-to-your-personal-repositories/maintaining-ownership-continuity-of-your-personal-accounts-repositories).
-
 ## What belongs to pypdf?
 
 The resources needed for maintaining pypdf are:
@@ -21,20 +18,19 @@ The resources needed for maintaining pypdf are:
 
 ## When may somebody take ownership?
 
-**No activity in 180 days**: If I don't answer e-mails (info@martin-thoma.de)
+**No activity in 180 days**: If I don't answer e-mails (see my GitHub profile)
 and don't make any commits / merges for half a year, you can consider pypdf "not
 maintained".
 
 ## Who may take ownership?
 
-Preferably, one of the owners of the Github `py-pdf` organization takes care of
+Preferably, one of the owners of the GitHub `py-pdf` organization takes care of
 that.
 
-From my current perspective (Martin Thoma, 27th of August 2023), the following
-people might be candidates:
+As of 27th of August 2023, the following people might be candidates:
 
 * [Lucas-C](https://github.com/Lucas-C): He maintains fpdf2 and is a py-pdf owner
-* [pubpub-zz](https://github.com/pubpub-zz): He is the most active contributor
+* [pubpub-zz](https://github.com/pubpub-zz): He is one of the most active contributors
   to pypdf
 * [Matthew Peveler](https://github.com/MasterOdin): Less active, but he is very
   careful about breaking changes and an experienced software developer.
@@ -44,5 +40,5 @@ people might be candidates:
 ## How to take ownership?
 
 * PyPI: Follow [PEP 541 – Package Index Name Retention](https://peps.python.org/pep-0541/)
-* Github: Talk with one of the other py-pdf organization owners
+* GitHub: Talk with one of the other py-pdf organization owners
 * ReadTheDocs: Follow the [Abandoned projects policy](https://docs.readthedocs.io/en/latest/abandoned-projects.html)
diff --git a/docs/user/cropping-and-transforming.md b/docs/user/cropping-and-transforming.md
@@ -196,9 +196,8 @@ writer.write("out-pg-transform.pdf")
 `pypdf<=3.4.0` used to merge the other page with `trimbox`.
 `pypdf>3.4.0` changes this behavior to `cropbox`.
 
-In case anybody has good reasons to use/expect `trimbox`, please let me know via
-info@martin-thoma.de or via https://github.com/py-pdf/pypdf/pull/1622
-In the mean time, you can add the following code to get the old behavior:
+In case anybody has good reasons to use/expect `trimbox`, you can add the
+following code to get the old behavior:
 
 ```python
 pypdf._page.MERGE_CROP_BOX = "trimbox"

diff --git a/pyproject.toml b/pyproject.toml
@@ -5,7 +5,7 @@ build-backend = "flit_core.buildapi"
 [project]
 name = "pypdf"
 authors = [{ name = "Mathieu Fenniak", email = "biziqe@mathieu.fenniak.net" }]
-maintainers = [{ name = "Martin Thoma", email = "info@martin-thoma.de" }]
+maintainers = [{ name = "stefan6419846" }, { name = "Martin Thoma", email = "info@martin-thoma.de" }]
 description = "A pure-python PDF library capable of splitting, merging, cropping, and transforming PDF files"
 readme = "README.md"
 dynamic = ["version"]
@@ -145,7 +145,7 @@ ignore = [
     "D406",    # Section name should end with a newline ("Returns")
     "D407",    # Google-style docstrings don't have dashses
     "D415",    # First line should end with a period
-    "D417",    # Missing argument descriptions in the docstring 
+    "D417",    # Missing argument descriptions in the docstring
     "DTZ001",  # The use of `datetime.datetime()` without `tzinfo` is necessary
     "EM101",   # Exception must not use a string literal, assign to variable first
     "EM102",   # Exception must not use an f-string literal, assign to variable first
@@ -154,7 +154,7 @@ ignore = [
     "FA102",   # Missing `from __future__ import annotations`, but uses PEP 604 union
     "FBT001",  # Boolean positional arg in function definition
     "FBT002",  # Boolean default value in function definition
-    "FBT003",  # Boolean positional value in function call  
+    "FBT003",  # Boolean positional value in function call
     "FIX002",  # TODOs should typically not be in the code, but sometimes are ok
     "G004",    # f-string in logging statement
     "N806",    # non-lowercase-variable-in-function
@@ -178,7 +178,7 @@ ignore = [
     "RET501",  # Do not explicitly `return None` in function if it is the only possible return value
     "RET502",  # Do not implicitly `return None` in function able to return non-`None` value
     "RET503",  # Missing explicit `return` at the end of function able to return non-`None` value
-    "RET504",  # Unnecessary assignment to `changelog` before `return` 
+    "RET504",  # Unnecessary assignment to `changelog` before `return`
     "RET505",  # Unnecessary `else` after `return` statement
     "RET506",  # Unnecessary `else` after `raise` statement
     "RET507",  # Unnecessary `else` after `continue` statement