Open chinenye3 opened 1 year ago
maryamgbemisola
commented
1 year ago @chinenye3 . Well done. You are supposed to mention the Mentor in Comment not on the Issues.
Submit the issues first ,then mention the mentor in a comment. I hope this helps.
Have a nice day
chinenye3
commented
1 year ago @arliss-NF kindly go through my submission for review. Thank you
chinenye3
commented
1 year ago @maryamgbemisola thank you for the correction
maryamgbemisola
commented
1 year ago You are welcome
Project Assigned: PySAL Project Link: https://github.com/pysal/governance
Project 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.
The project is built by a team of distributed developers also referred to as Contributors.
According to the project’s documentation, there are many ways to contribute to the PySAL project, and a great place to start is by joining their [gitter channel] https://gitter.im/pysal/pysal where much of the day-to-day discussion between developers as well as users takes place. They are a group of data experts willing to offer mentoring opportunities to people new to open-source development and interested in programming for spatial data science.
Discussions about the project happen on GitHub, Gitter, and other channels adopted by the project. The foundation of the Project’s participation is rooted in openness and transparency.
The Project’s Community consists of all Contributors and Users (who adopt and utilize the software/packages developed by the Contributors) in the Project. Contributors work on behalf of the larger Project Community and strive to keep the barrier between Contributors and Users to the barest minimum.
Project Governance Overview
The project’s governance model has its foundations rooted in the following:
Traditionally, the Project’s leadership was provided by a Benevolent Dictator for Life (BDFL) and a subset of Contributors and Package Maintainers, called Core Developers, whose active and consistent contributions have been recognized by their receiving “commit rights” to the Project’s repositories on GitHub. In general, all Project decisions are made through a consensus carried out among the Core Developers with input from the Community. While this approach has proven to serve the team well, as the Project grows there’s seemingly a need for a more formal governance model.
Moving forward The Project’s leadership will consist of a BDFL and Steering Council, consisting of three (3) elected Package Maintainers serving one (1) year terms. This restructuring of the governance model is simply to give a formal structure to what the team is already doing, rather than a change in direction.
The current Project's leadership structure consists of the following:
Benevolent Dictator for Life (BDFL): deemed as the highest authority when it comes to making the final decision for the project
Package Maintainers: responsible for managing and maintaining the project’s solution software also known as Packages.
Steering Council: the council is responsible for ensuring the long-term well-being of the Project, both technically and as a community by working closely with the BDFL and also taking input from the Community to improve the Project’s outcome/success.
The Project's decision-making process:
As a dictator, the BDFL has the authority to make all final decisions for The Project, but as a Benevolent, the BDFL, in practice can choose to defer that authority to the consensus of the community discussion channels and the Steering Council. As it has been in the past, it is expected that the BDFL will only rarely assert their final authority. The BDFL’s final authority is referred to as a “special” or “overriding” vote and when this occurs, although rarely, the BDFL override typically happens in situations where there is a deadlock in the Steering Council or if the Steering Council specifically asks the BDFL to make a decision on a certain matter. To ensure the benevolence of the BDFL, PySAL encourages others to fork the project if they disagree with the overall decision of the BDFL. The BDFL may delegate their authority on a particular decision or set of decisions to any other Council Member at their discretion.
The BDFL can appoint anyone to succeed them but should be done after duly consulting with the Steering Council on the decision. Should the BDFL for any reason be unable to appoint a successor, the Steering Council will make this decision - preferably by consensus, but if needed by a majority vote.
Numeric votes are often used informally as a way of getting a general sense of people’s feelings on some issue, and should not normally be taken as formal votes. A formal vote only occurs if explicitly declared. If this does occur then the vote is held open long enough to give all interested Council Members a chance to respond (typically, at least about a week). In a case where the Steering Council needs to establish a formal decision, they will need to adopt a form of the Apache Foundation voting process, which is a formalized version of consensus, where +1 vote indicates agreement and -1 vote are vetoes (which must be accompanied with a rationale, as stated above). One can also vote fractionally (e.g. -0.5, +0.5) to express an opinion without registering a full veto.
The BDFL can step down at any time, and when acting in good faith, will listen to the serious calls of other stakeholders to do so. Also, the BDFL is more of a “fallback decision-making role” rather than that of a director or CEO.
Difficulty in locating PySAL’s governance model:
Personally, it wasn’t difficult for me to locate the governance model once I was on the “About Us” page of the PySAL website, but for someone who doesn’t take the time to pay attention to details, there’s the likelihood that they might miss the information, but generally, I think the difficulty level is relative.