First Contribution by Himangi Malik

[Himangi-Malik]

Name: Himangi Malik Project assigned: PySAL Link to official webisite: http://pysal.org/ Link to Github https://github.com/pysal/pysal Link to Governance model:https://github.com/pysal/governance

PySAL, the Python spatial analysis library, is an open source cross-platform library for geospatial data science with an emphasis on geospatial vector data written in Python. It supports the development of high level applications for spatial analysis, such as

• detection of spatial clusters, hot-spots, and outliers
• construction of graphs from spatial data
• spatial regression and statistical modeling on geographically embedded networks
• spatial econometrics
• exploratory spatio-temporal data analysis

  GOVERNANCE MODEL

  The governance of PySal is led by a group of core developers who oversee the technical direction of the project. The core developers are responsible for making decisions about the library's design, features, and functionality. They are also responsible for reviewing and merging pull requests submitted by contributors. The community welcomes contributions from anyone, regardless of their level of expertise. The governance process is guided by a code of conduct that promotes respectful and constructive communication and behavior. Decisions regarding the future direction of PySal are made through a combination of discussion, consensus-building, and voting. The community uses various communication channels, including mailing lists, GitHub issues, and social media, to discuss and collaborate on issues related to the library's development

The foundations of Project governance are:

• Openness & Transparency
• Active Contribution
• Institutional Neutrality

Traditionally, Project leadership was provided by a Benevolent Dictator for Life (BDFL: Sergio Rey) 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 GitHub repositories. In general all Project decisions are made through consensus among the Core Developers with input from the Community.. In summary, the governance model of PySal is community-led and transparent, with core developers responsible for the technical direction of the project and the community working together to maintain and improve the library.

DECISION MAKING PROCESS

The decision-making process of PySal is community-driven and follows a transparent and inclusive approach. The community welcomes input and contributions from anyone interested in the development and improvement of the library. The process for making decisions in PySal typically involves the following steps:

1. Discussion: A topic or issue is raised on one of the communication channels, such as the PySal mailing list or GitHub issue tracker. The community members are encouraged to provide their opinions, insights, and suggestions on the issue.
   2. Consensus-building: The community strives to build consensus on the topic or issue under discussion. This involves active listening, acknowledging differing viewpoints, and finding common ground among the participants.
   3. Voting: In some cases, a decision may be put to a vote to determine the preferred course of action. Typically, the community uses a simple majority voting system to decide.
   4. Implementation: Once a decision is made, the core developers and community members work together to implement the agreed-upon solution. Throughout the decision-making process, the community follows a code of conduct that promotes respectful and constructive communication and behavior. The PySal community also seeks to be transparent in its decision-making by documenting the process and outcomes in public forums, such as mailing lists, GitHub issues, and documentation.

During decision making by the Steering Council, they will then utilize a voting system similar to that of the Apache Foundation. This is a structured version of consensus, where +1 votes indicate agreement, -1 votes are vetoes (and must be supported by the justification mentioned above), and one can even vote fractionally (e.g., -0.5, +0.5) to convey a viewpoint without filing a full veto. These numerical votes are frequently used informally to gauge public opinion on a subject, therefore they shouldn't typically be interpreted as official votes. A formal vote only takes place when it is officially proclaimed, and if it does, it should be kept available for at least one week to allow all interested Council Members to respond.

PROJECT ROLES

1. BDFL (Benevolent Dictator For Life)
2. Package Maintainers
3. Steering Council Members
4. Release Managers

How hard was it to understand the governance model? Given my extensive experience of data analysis, it was fairly easy for me to understand the governance model. Very clear-cut and precise information was available on the Github pages.

[Himangi-Malik]

@arliss-NF Eagerly waiting for your input in this!

[arliss-NF]

Hi @Himangi-Malik - thanks for completing your first task. I am trying to use the links you provided; however, they do not seem to work. Could you please take a moment to check them and ping me again? Thanks so much.