Second Contribution by Chinenye Ibegbunam

PROJECTS: PySAL pysal.org | PyTorch pytorch.org Project 1: PySAL -- https://github.com/pysal/governance Project 2: PyTorch -- https://pytorch.org/docs/master/community/governance.html

OVERVIEW PySAL also known as The Python Spatial Analysis Library is an open-source project designed to support geospatial data science by simplifying native python functions into packages that can be used to analyze data. The solutions they build are also referred to as Packages.

PyTorch is an open-source project that democratizes state-of-the-art tools, libraries and other components to make AI & Deep machine Learning innovations accessible to everyone. The PyTorch framework is one that enables fast and flexible experimentation, and efficient production through a user-friendly front-end design, distributed training, and an ecosystem of tools and libraries for the easy application and integration of machine learning across different industries. PyTorch’s source development language is rooted in Python.

Having covered the basic background of both projects, here's a quick analysis of the both projects, and some key takeaways.

Analysis of PySAL's and PyTorch's Governance Models: Similarities, Differences, and Takeaways.

Some Similarities Include:

Both projects are open-source and are heavily reliant on python as a source language.
Both projects have similar governance and leadership structure and anyone can be a contributor to both projects.
Both PyTorch & PySAL acknowledge BDFL as the overall authority on the project.
Membership in both PyTorch’s Module and Maintainer groups and PySAL’s Council is given to individuals based on merit after they have demonstrated a strong commitment to the project through contributions, reviews and discussions and are aligned with how the component fits in the overall project vision/direction.

Some Key Differences Include:

PySAL Package Maintainers are heavily dependent on the Steering Council when it comes to decision-making, but PyTorch Module Maintainers have some level of autonomy that allows them to make their own decisions/guide their maintainer groups, and only revert to the Core Maintainers when needed.
There are no term limits for module maintainers or core maintainers in PyTorch, but the term limit for PySAL is a one-year frame.
In PyTorch, there's a light criterion of moving module maintainers who haven’t actively participated over a long period of time to ‘emeritus’ status and each module maintainer group may define the inactive period that’s appropriate for that module. If a PySAL Council Member becomes inactive in the project for a period of one year, they will be considered for removal from the Council. Although, before removal, the inactive Member will be contacted to see if they plan on returning to active participation any time soon. If not they will be removed immediately upon a Council vote.

Takeaways: In summary, while it is evident that both projects share several similarities between them, there are also some significant differences in how they operate & how the projects govern themselves on some levels, and in light of that, I wouldn't categorically say that the governance system of one is better than the other because they are both unique in their own light, and have been designed the way they are to cater to the needs of the entire community & drive the progress of the entire project. While I appreciate the flexibility of PyTorch's governance in adopting an open ended approach as regards inactive contributors and the subtle easing into "emeritus" status after inactivity for a long period of time, maybe because they want to maintain "retention", I also appreciate PySAL's time framed model for inactive members because I believe it keeps contributor on their toes, encourages activeness and creates a chance for other contributors to serve as council members. In the same vein, while it is commendable that the decision making power remains within the reins of PySAL's Steering Council & BDFL to probably ensure order and uniformity, PyTorch's flexibility in granting some level of autonomy to Module Maintainers that allows them to make their own decisions/guide their maintainer groups, and only revert to the Core Maintainers when the need arises is also very commendable. So, in all, I'd say whatever the governance model may be or how it is designed, as long as it's fitting and caters to the participants/communities in focus, that should be about all that matters.

numfocus / outreachy-contributions-2023

Second Contribution by Chinenye Ibegbunam #92