DOC: Project Governance #799
Conversation
MartinThoma
force-pushed
the
project-governance
branch
from
01dadbf to
11b6760
Compare
|
@mstamy2 @MasterOdin I would be very interested in your feedback on |
docs/meta/project-governance.md
Outdated
| For this reason, PyPDF2 has the **Benevolent Dictator for Life** (BDFL) | ||
| governance model. The BDFL is a maintainer with all technical permissions - | ||
| most importantly the permission to push new PyPDF2 versions on PyPI. |
There was a problem hiding this comment.
The reasoning for using BDFL doesn't follow from the previous paragraph. This reads to me as that the BDFL is still going to be the only person who can manage the project, make new versions, etc. and so if they do not have the time to move PyPDF2 forward nor appropriately name a successor, the project will stall again as once again. An example of this could be seen in pypdf4 fork where there was a "BDFL" who added a maintainer, and while the maintainer made commits, merged PRs, the BDFL disappeared and the project completely stalled out. The bus factor of 1 somewhat largely remains.
While I think it's fine to have an overall dictator for the project and all that entails in decision making, it would be good to also have a step between BDFL and maintainer that has same permission levels on the project (e.g. can manage the organization, make PyPDF2 releases on PyPI, etc.), but are below the BDFL for any sort of decisions made on the project progression.
There was a problem hiding this comment.
The bus factor of 1 somewhat largely remains.
I don't see a way around this as long as there is not more community members who would be ready to step in. I completely agree that it would be good to have a bus factor larger than 1.
I see three scenarios how PyPDF2 development could get blocked again:
- BDFL looses interest: Can happen and will likely happen. It would be good too have a clear process on what to do in that case. At the moment, I would probably ask you @MasterOdin if you want to become BDFL - but if there is nobody who is trustworthy + wants to spend the time on it, that's an issue.
- BDFL looses access (PyPI and GitHub): I'm actually not sure how they handle this... but it seems rather unlikely to me. PyPI has a recovery process (link)
- BDFL is dead: Hopefully also unlikely 😅 However, Github has a deceased user policy. I'm currently discussion with a couple of friends who would be that. I'm telling them that they should hand-over the project to the most active maintainer if that ever happens. For PyPI, I haven't seen anything like that.
There was a problem hiding this comment.
The reasoning for using BDFL doesn't follow from the previous paragraph.
My thoughts were: If we had many people who really cared about PyPDF2 (enough to become a maintainer), we could make something like a steering council. We have a lot of users, but not a lot of developers. And even less people who would like to become maintainers. That means to me that a more democratic approach cannot work.
There was a problem hiding this comment.
@MasterOdin I was just pointed to https://pypi.org/help/#project-name-claim - that means it is possible to transfer the PyPI ownership if the project owner(s) on PyPI are not reachable for 1 year or longer.
It might be worth it to add a section in the docs how to deal with that / what to do in this case.
There was a problem hiding this comment.
I'd say I'm not complaining about the concept of a BFDL / BD, I'm totally on board with that, especially at the current stage of the project's lifecycle.
My only complaint was with this line specifically:
The BDFL is a maintainer with all technical permissions - most importantly the permission to push new PyPDF2 versions on PyPI.
The previous setup was that mstamy2 was a singular maintainer / "BFDL", and that because he lost the time to take the project forward and was the only one with technical access to the project, it completely stalled. Saying that having a singular BDFL here doesn't exactly solve that problem where again, if you were to disappear without a trace, yes another maintainer could maybe get appropriate access on GH, PyPI, etc. to start publishing, it's still a massive pain, and that all I'm asking is to make sure we have multiple active people in place with those project permissions, while again, having a BD who owns the technical side of things (veto power over any concept / issue, steering of the project, etc.).
I don't think this is something that needs to be solved right away, it's just food for thought.
MartinThoma
force-pushed
the
project-governance
branch
from
59123af to
094ad57
Compare
Robustness (ROB): - Handle missing destinations in reader (#840) - warn-only in readStringFromStream (#837) - Fix corruption in startxref or xref table (#788 and #830) Documentation (DOC): - Project Governance (#799) - History of PyPDF2 - PDF feature/version support (#816) - More details on text parsing issues (#815) Developer Experience (DEV): - Add benchmark command to Makefile - Ignore IronPython parts for code coverage (#826) Maintenance (MAINT): - Split pdf module (#836) - Separated CCITTFax param parsing/decoding (#841) - Update requirements files Testing (TST): - Use external repository for larger/more PDFs for testing (#820) - Swap incorrect test names (#838) - Add test for PdfFileReader and page properties (#835) - Add tests for PyPDF2.generic (#831) - Add tests for utils, form fields, PageRange (#827) - Add test for ASCII85Decode (#825) - Add test for FlateDecode (#823) - Add test for filters.ASCIIHexDecode (#822) Code Style (STY): - Apply pre-commit (black, isort) + use snake_case variables (#832) - Remove debug code (#828) - Documentation, Variable names (#839) Full Changelog: 1.27.9...1.27.10
Document how we work together on PyPDF2