This repository will be used to capture Outreachy applicants' contributions during the Applications phase - May-July 2023 Cohort
License: BSD 3-Clause "New" or "Revised" License
This repo contains organizational materials for NumFOCUS, like:
This repository is maintained publicly, as part of NumFOCUS' efforts to operate as transparently as possible.
Name: Diana OFODU (she/her)
Project: The Carpentries (https://carpentries.org/)
Link to The Carpentries governance model: https://carpentries.org/governance/
The governance model of The Carpentries consists of rules set by the executive council. The council is responsible for determining the organization's mission, maintaining and updating bylaws, selecting and evaluating the executive director, strategic planning, financial management, identifying revenue streams, program approval, public image enhancement, and self-assessment. The executive director serves as the Chief Executive Officer and their actions are overseen by the executive council.
The executive council is made up of nine members; four of whom are elected by the community members (community-elected members) and five are elected by the executive council (council-elected members). Though they strive for transparency in their activities, some things are still kept to themselves.
Project roles
There are three major project roles:
In addition to the formal roles, there are different committees which make up of the executive council members in charge of various operations, for example:
Decision-making process
Voting is done yearly and the Executive Director is exempted from it. There are four sets of people who are eligible to vote. These individuals are considered active in the community. They include those who completed an Instructor or Trainer certification within the past year, those who completed it within the last two years and have taught at least one Carpentries workshop, those who are certified instructors or trainers and have taught at least two Carpentries workshops in the past two years and those who have participated in a committee as a mentor or maintainer in the past year.
To approve an appointment or removal of any party, a majority of votes by the executive council is required.
How easy or difficult was it to find and understand the governance model?
It was not difficult for me to find the governance model as there was a button that clearly stated what I was looking for. The amazing thing was that I was going down a rabbit hole of information just like I usually do when I start binge-watching videos on YouTube. I understood it pretty well although it was my first experience with governance models and was not sure if I was getting the correct information.
Name: Imaobong Njokko
The primary goals of this proposal are to be more community-driven and less reliant on a certain "core" group of people, while also formalizing Django's processes.
In general, the governance model put forward in Django DEP 0010 seeks to encourage openness and responsibility in the project's decision-making processes. It provides a clear framework for project contributors to understand their roles and responsibilities.
All discussions and voting processes are held in forums and venues that are generally open to interested members of the public. i.e. django-developers mailing list, the Django Forum, or in any other venues the Technical Board choses.
Any member of the community in good standing may propose new features for Django at any time.
For minor changes, proposers shall use the code.djangoproject.com bug tracker and/or any of the approved public forums. And, for major changes, proposers shall use the DEP process, with discussion taking place on any of the approved public forums.
Proposals are made in the form of YES or NO. The possible outcomes of a vote are:
The Technical Board has a voting period of one week. Each vote must be one of the following: "+1", "0", or "-1", and should be accompanied by the reasoning for that decision.
If a voting period ends and not all members of the Technical Board have voted, the vote is considered incomplete. It is also considered incomplete if the current score of the proposal is less than 3 which means that an additional vote can change its outcome. An additional voting period of one week is given, and repeated until the vote is completed. Members of the board can change their votes at any time prior to closing of the final voting period.
Once a decision has been reached, it is documented and communicated to the community.
While the governance model was easy to understand, it was difficult to find directly from their website; I had to do a google search that eventually led me to the model on their GitHub repository. I would suggest that they add a “contribution” tab at the top of their website that clearly details processes for contribution and easily directs to the governance model, or a link to the model in their Github repository.
I am Kehinde Adebisi
I was assigned CVXPY
Here is the link to the governance model - https://github.com/cvxpy/org/blob/main/governance.md
CVXPY is an open-source Python-embedded modeling language for convex optimization problems. It has a community of researchers, data scientists, software engineers, and students from all over the world.
CVXPY adopts a combination of the Founder-Leader and Self-Appointing governance models while embracing transparency and contribution.
The roles include:
Benevolent Dictator for Life - Creator
Project Maintainers – Technical Support Lead and Authorities
Emeritus Project Maintainers – Previous Project Maintainers (Now less active)
Steering Committee – Administrative and Legal Duties
The Decision-Making Process was categorized into Financial and Non-Financial Decisions.
Financial Decisions require majority approval from the Steering Committee while Non-Financial Decisions are made through the consensus of the Project Maintainer (Emeritus Project Maintainers are excluded).
Non-Financial Decisions are further broken down as follows:
Code-related – Discussed via GitHub issues, pull requests, or a developer call
Changes to Public APIs – Approval from at least half of the Project Maintainers
Non-Code Related – GitHub issues or a developer call
In the event of a lack of consensus on a non-financial decision, the Steering committee, if delegated or the Benevolent Dictator for Life(BDFL) makes the final decision.
When a conflict of interest occurs, members involved in the conflict are allowed to participate in discussions regarding the issue but not in voting or decision-making.
Finding the governance model was relatively easy, it took a quick scan of the repositories, a visit to the website, and a keyword search on the site. The model is also quite precise and comprehensible.
My name is Chidiogor Akupue
Project Name: BQplot
[link to the project governance model]-(https://github.com/bqplot/governance/blob/master/governance.md)
BQplot Governance Model
BQplot Project is an open-source software project for exploratory and interactive data visualization. The governance model of the BQplot project consists of the steering council and its members who take on leadership responsibilities for the project to ensure through working strategies, the long-term well-being of the project technically, and the community. Council membership terms last two years and initial terms are staggered, so there is a new selection of steering council Members every year. Council Members can serve multiple consecutive terms. Council Members are expected to participate in 3/4 of the regular meetings (at least monthly) to engage in discussions and offline votes on the Steering Council mailing list.
The steering council makes decisions about the project's overall scope, vision, and direction. They create strategic collaborations with other organizations and individuals to develop funding sources and manage expenses. They also make decisions when regular community discussion does not produce consensus on an issue in a reasonable time frame, mediate significant conflict between community participants regarding the direction of the project, resolve code of conduct issues see here, grant or revoke privileges (e.g., releasing, committing, triaging) to Project Contributors, mentor Project Contributors, and make decisions on major architectural or backward-incompatible changes, as well as major releases of The Project.
Project Roles
• Project Contributors - individuals who have helped the project with code contributions, documentation, designs, community management, etc.
Here is a list of the current Contributors to the main BQplot repository: https://github.com/bqplot/bqplot/graphs/contributors
• Steering Council - consists of Project Contributors who have produced contributions that are substantial in quality and quantity, and sustained over at least one year.
• Institutional Partners - include recognized legal entities that employ at least one Steering Council Member participating in Council work as part of their official duties at the Institutional Partner. Institutions are the project's primary funding mechanism, and it is important to formally acknowledge institutional participation in the project.
• Users of the Project
Decision-making process
The decision of nominated potential steering council members to become members is based on a successful vote by existing council members. If a Council member becomes inactive in the project for a long period, they will be given a grace period of one year and If they do not return to active participation within that period, they will be removed by a vote of the Council without a further grace period.
Changes to the governance documents which are submitted via a GitHub pull request to the project’s governance GitHub repository at https://github.com/bqplot/governance must also be ratified by 2/3 of 80% of the steering council members to be valid.
How easy or difficult was it to find and understand the governance model?
The BQplot website https://bqplot.github.io/bqplot/contributing/, shows the link to the official version of the BQplot governance document contained in the Project Governance Repository at https://github.com/bqplot/governance so finding it was relatively easy, understanding it, on the other hand, took a little bit of an effort.
Name: Oluwaseun Odunayo Aribisogan
Project Assigned: FluxML
Link to the project assigned: https://github.com/FluxML
GOVERNANCE MODEL:
Everything about the governance model of FluxML is straightforward and brief. Most of the roles are focused on the committee called Steering Council. Each role and duty that bound them were stated clearly.
cc @arliss-NF
PROJECT ROLES:
There are two major roles, namely:
DECISON MAKING PROCESS:
The decision-making process is majorly from the steering council with a simple majority, and making such exceptional changes in the Governance document, but when there are exceptional cases/disagreements among the council then the community reached out to the advisory committee which annually meets on the project activities.
HOW EASY/DIFFICULT:
At first, it was not easy to locate probably because this is my first time contributing to open source and the governance model was new to me, but going through it, I understood perfectly the importance of this model in an organization. It has improved my research and analytical skills. And I know I can still do better if opportune.
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
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:
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.
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:
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.
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.
Name: Chimnwendum
Project: QuTip (https://qutip.org/)
Link to the QuTip governance model: https://github.com/qutip/governance/blob/main/governance.md#2-admin-team
The Governance Model: The governance model is straightforward. Each role has a list of responsibilities it is expected to carry, and every part is interdependent on one another.
For instance, while the Admin Team is responsible for leading the technical code development, they need the Board Members to provide finance and logistics for the project. In addition, the Non-Profit will need to provide advice for the Admin Team and Board Members.
Any Project Roles: Yes, there are three distinct roles
Decision-Making Process: QuTip exercise a Voting Procedure for whatever decision-making process. For instance, changes to their governance model need to be approved by 3/4 of the Administrative Team through a voting process. For every voting process, the majority wins.
How easy or difficult was it to find and understand the governance model: It was easy as I located their governance model quickly. Understanding it was tricky, but I will not say it was hard.
Here is the LINK to the project's governance model.
The Dolphicom project is an Open source project whose main aim is to develop open-source software for scientific analysis of bioacoustics in Python and the Dolphicom package.
The project governance is anchored on transparency, active contribution, and institutional neutrality.
This governance model has heavily adapted from Jupyter's and Numpy governance documents.
A benevolent dictator (BDFL ) provides the primary leadership of the project. A BDFL has the authority to make final project decisions, however, to preserve the benevolence of this position, the BDFL is rarely expected to assert his authority and instead delegates that authority to the consensus of conflicting parties. A BDFL offers guidance and support in situations when the steering council is at loggerheads and the council requests the BDFL to make a decision on a particular matter. A BDFL has the authority to appoint his successor in consultation with the steering council.
The Steering Council is another arm of leadership in the Project and is composed of project contributors with sustained and significant contributions over at least a one-year period. Individuals with significant contributions to the project are considered for calling to the council. Metrics for considerations as potential are not only limited to code but also Infrastructure work, mailing lists, chat participation, and community building. There are other two leadership roles within the Steering council, the Council chair and the Release manager. The project roles for the council and the two leadership positions are detailed below.
All council members shall disclose to the rest of the council any conflict of interest they have on various issues. Members with conflicting interests are allowed to participate in community discussions but are not allowed to participate in the voting process touching on the conflict of interest.
In instances where a formal decision is required, the governing model allows for voting through the Apache voting process. This voting process is unique, a +1 vote indicates an agreement, -1 votes are vetos and should be accompanied by a rationale informing of this decision, and also allows for a fractional voting system. The fractional voting system is important in getting the general feel of the community towards a certain matter.
Institutional partners are acknowledged in the governance model as part of the community due to the important role of funding they offer to the project. Institutions become eligible to become Institutional partners by employing individuals who actively contribute to The Project as part of their official duties. Only using the Project software in an institutional context does not qualify an entity to become an Institutional Partner. The steering council is responsible for approving an entity for institutional partnership once the thresholds are met. Institutional partnerships will last if an entity ceases having individuals actively contributing to the project for over a one-year time period.
The governance model was easily accessible in the project documentation. The project's documentation is organized and clearly written and this made understanding the governance model much easier. Project's documentation is quite detailed and had past governance models, this enabled me to further understand the project and how the project's governance policies have evolved over time
My name is Rashid Leonard.
I was assigned the CVXPY project.
Here is the link to the project's governance model.
CVXPY is an open source Python-embedded modeling language for convex optimization problems. It lets you express your problem in a natural way that follows the math, rather than in the restrictive standard form required by solvers. Convex Optimization is a subfield of Mathematical Optimization that studies the problem of minimizing convex functions to linear and nonlinear constraints. Convex optimization problems can take many forms including linear programming, quadratic programming, second-order clone programming and semi definite programming. CVXPY is a versatile optimization tool that can be used to solve these problems in a wide range of disciplines including Engineering, Finance, Operations Research, Statistics, Economics, and Data Science among others.
Governance Structure
The governance document for the CVXPY project outlines the entities and their respective obligations, the decision making process (including how to deal with conflict of interest situations), GitHub permissions and channels through which the community can contribute or participate in the CVXPY project. The governance document can be found publicly in the GitHub repository of the project.
A small team, currently about five people, is in charge and is also the final arbiter or authority of the technical decisions and development of the project. The governance document also contains the Code of Conduct and Mission statements of the project. The CVXPY project is both made for the community and by the community. As an open-source project, CVXPY highly values community contributions to maintain and improve the CVXPY repository.
Project Roles
Here are some roles under the CVXPY project:
Decision Making Process
Financial Decisions are made with a majority approval by the Steering Committee whereas the non-financial decisions are made by the project maintainers and sometimes the BDFL is invited to make a non-financial decision on rare occasions.
Non-financial decisions include code-related decisions, changes to public API, and, long-term strategic planning for the project.
The governance model document of the CVXPY project also describes steps to address Conflict of Interest situations when it arises.
Finding and Understanding the Governance Model
It was not difficult to find the governance document. I clicked on about three repositories until I located the governance.md file.
If access to the governance model easily by all kinds of users is really a big deal, I suggest it be kept in a separate repository with the repository name being “governance-model”.
Name: Sajid Khallow
Project Assigned: GNU Radio
Project Link: GNU Governance Model
GNU Radio is a free and open-source software toolkit used for developing software-defined radio (SDR) systems. It provides signal processing blocks to design, build and test SDR systems that can receive and transmit a wide range of radio signals, including digital and analog modulations.
The software is written in Python and C++, and it is distributed under the GNU General Public License (GPL) version 3. GNU Radio is maintained by a community who contribute to the project through code, documentation, and support. It is widely used by researchers, hobbyists, and industry professionals for developing SDR systems for a variety of applications, including wireless communications, spectrum analysis, and radio astronomy, among others.
GNU Radio is a community-driven open-source project, which means that its governance model is based on collaboration and consensus-building among its contributors. The project is managed by the GNU Radio Steering Committee (GRSC), which is composed of active contributors to the project. The GRSC is responsible for overseeing the development of the software, ensuring that it adheres to the project's mission and vision, and promoting the growth of the community.
The GRSC makes decisions through a consensus-based process, in which all members have an equal say. Discussions take place on mailing lists, forums, and in occasional face-to-face meetings.
The decision-making process in GNU Radio is based on a consensus-building approach. This means that decisions are made through discussion and agreement among the project's contributors, with the goal of reaching a solution that is acceptable to everyone involved.
The decision-making process typically begins with a proposal or idea being presented by a contributor. This proposal is then discussed by the community through various communication channels, including mailing lists, forums, and chat rooms.
The voting system of GNU Radio consists of three types of votes:
The voting process is initiated by a proposal for voting, which is sent to the membership mailing list and has to include exact and complete information about what is being voted upon.
After the voting proposal is sent, there is a discussion period of two weeks in which active members can discuss and form opinions about the options available for voting.
The voting period lasts for two weeks and is started after the discussion period has ended. During this period, active members cast their votes, and only votes cast within the voting period are considered for the results of the voting.
The voting results are published to the active membership by sending them to the membership mailing list. The results include the number of people permitted to vote, the total number of votes, and the number of votes for each available voting option. The results also include a statement if the voting was valid according to section 5.
For new member votes, there are three options: "Yes," "No," and "Abstain." The new member is accepted if there are more "Yes" than "No" votes and the vote isn't invalid according to section 5.
For elections of groups of people, there is a candidacy period before the voting proposal is sent. The candidacy period lasts two weeks, and all members who declare their candidacy become candidates for the election.
For voting about decisions, the options are voted on according to section 3.4, which describes the voting system for multiple options.
It was fairly simple to find the governance model of GNU Radio. Just took a few steps in the GitHub Repository to find it.
It was simple and straightforward to understand the GNU Radio's governance model. All the details are listed in the repository.
Name: Avishkar Gunjal
Project: PyTorch
Project Governance Model Links:
PyTorch is a popular open-source machine learning library used for developing and training deep neural networks. It was developed by Facebook's AI research team and is written in Python. PyTorch provides a dynamic computational graph that allows users to easily define, track, and optimize complex neural network models. It also supports automatic differentiation, which makes it easy to compute gradients and perform backpropagation. PyTorch is known for its ease of use, flexibility, and speed, and is widely used in both research and production environments.
PyTorch has a hierarchical technical governance structure with a small set of module maintainers overseeing the project's direction. All maintainers are expected to follow PyTorch's design philosophy, and anyone can become a maintainer based on their contributions and willingness to invest. The community is encouraged to contribute, file issues, make proposals, and review pull requests. Technical governance is separated from business governance, and membership is for individuals, not companies. This ensures that there is no way for any person or company to "buy their way into" the technical guidance of the project.
PyTorch adopts a hierarchical technical governance structure that is divided into module maintainers, core maintainers, and a lead core maintainer (also known as BDFL). This structure ensures that the project is well-maintained and that contributions are managed efficiently.
PyTorch's governance model is well-defined and organized. The hierarchy of maintainers, with clear responsibilities and decision-making authority, helps ensure that changes to the framework are carefully considered and implemented. The process for making uncontroversial changes is straightforward, while the process for more substantial changes is more involved and requires discussion and approval from relevant experts. They also provide a link to the charter which defines the Foundation's governance while the technical governance of the opensource project is maintained in their docs
Name - Phebe Radiant Momoh
Assigned Project- HoloViz
HoloViz GitHub
Link to the governance model -
HoloViz Organization Governance Model
HoloViz Project Governance Model
HoloViz is an open-source Python library that provides tools for creating interactive and web-based visualizations of scientific and engineering data. It is designed to be flexible, allowing users to choose from a variety of different visualization libraries and tools to create custom visualizations that suit their needs.
HoloViz is a collaboration between the maintainers of several Python packages (tools), including HoloViews, GeoViews, hvPlot, Datashader, Param, Colorcet, and Panel.
The authors of these tools are working together closely to help make them into a coherent solution to a wide range of Python visualization problems.
HoloViz is widely used in scientific research, data analysis, and other fields where data visualization is important. HoloViz has both Organization and Project levels.
THE GOVERNANCE MODEL:
The HoloViz governance has two levels - the HoloViz Organization and the HoloViz Projects (including the HoloViz website). This division allows the organization stays aligned as a community while supporting and benefiting from diverse initiatives.
HOLOVIZ ORGANIZATION:
It is an open-source and collaborative effort with a mission to develop visualization solutions for Python.
HOLOVIZ PROJECT:
HoloViz project is a subset of the HoloViz Organization. HoloViz offers an all-inclusive solution for visualization by incorporating a suite of effective Python tools that work together to tackle the entire range of visualization problems ranging from investigative data analysis to the deployment of complicated dashboards.
The core HoloViz projects are:
PROJECT ROLES
THE GOVERNING BODY AT HOLOVIZ PROJECT LEVEL:
THE GOVERNING BODY AT HOLOVIZ ORGANIZATION LEVEL:
Steering Committee: This committee is responsible for higher-level aspects of the organization, such as setting the overall scope, vision, policy, and direction.
Steering Committee Members
Code of Conduct Committee (CoCC): This committee is responsible for enforcing and updating the code of conduct.
THE DECISION-MAKING PROCESS AT THE PROJECT LEVEL.
THE DECISION-MAKING PROCESS AT THE ORGANIZATION LEVEL.
FINDING THE HOLOVIZ GOVERNANCE MODEL:
The governance model of HoloViz was easy to find and understand. I used the “Search the Docs” feature on the website to locate the governance model. This led me to the “About Us' page where I found the governance model.
HoloViz made its governance model straightforward, clear and concise.
As a first-time contributor to Open Source, this was a task I found interesting. I am open to learning and making more meaningful contributions to this community and to Open Source in general.
Link for further reading - HoloViz GitHub
NAME: BLESSING KAZ
PROJECT: (https://docs.djangoproject.com/en/4.1/#the-django-open-source-project/)
LINK TO THE GOVENMENT MODEL: governance model for the Django project, the organization of the Django project, code of conduct and the github for the code of conduct.
The governance model of the Django open-source project is designed to ensure that the development of the project is conducted with a clear structure for decision-making in an open, transparent, and collaborative manner involving the community. At the heart of the model is Django software foundation that serves as a legal and financial umbrella of the DJANGO project while the Django Technical Board is responsible for overseeing the technical direction of the project
THE PROJECT ROLES
The government model has project roles that consist of different levels of authority and responsibilities. They are as follows;
THE DESCISON-MAKING PROCESS
The project's decision-making process is designed to be a collaborative, transparent and are made by rough consensus among the core developers, with the project's technical lead having the final say if necessary. The decision-making process is designed to be flexible and adaptable to different situations and may be modified over time as the project evolves. And the decision-making is outlined in the governance model the governance model and Organization of the Django project
It was easy to understand and locate the government model. It was described in the documentation section. There they roles of different entities in the project decision-making were clearly explained and organized even the code of conducts were properly stated
Name: Linda Njau.
Project Assigned: ESLint
Link to Governance model
GOVERNANCE MODEL OF ESLint.
The governance model of ESLint is based on a community-driven approach where anyone can contribute to the project in various ways, such as submitting code, participating in discussions, making suggestions, or providing moral support.
Based on the information available on ESLint's governance model, some of the core principles that can be deduced are:
Transparency: The governance model is designed to be transparent, which means that all decisions made by the ESLint team are documented and available for public scrutiny.
Community participation: The governance model encourages participation from the ESLint community. This means that contributors are welcome to voice their opinions and make suggestions for the future direction of the project.
Collaborative decision-making: Decisions are made collaboratively through a consensus-based approach. This means that all contributors have an equal say in decisions, and the team works to find a solution that is acceptable to everyone.
Maintainer accountability: Maintainers are held accountable for their decisions and actions. This means that if a maintainer makes a decision that is not in the best interest of the project, they can be held accountable by the community.
Technical excellence: The governance model prioritizes technical excellence. This means that decisions are made based on what is best for the project technically, rather than based on personal opinions or agendas.
Overall, ESLint's governance model prioritizes transparency, community participation, collaborative decision-making, maintainer accountability, and technical excellence.
PROJECT ROLES
1.Maintainers: They are responsible for the overall direction and development of the project, reviewing and merging pull requests, and managing releases.
2.Collaborators: They have write access to the project's codebase and assist maintainers with reviewing and merging pull requests.
3.Contributors: They are community members who contribute code, documentation, or other resources to the project.
4.Users: They are individuals or organizations who use ESLint in their projects and provide feedback to the project team.
DECISION-MAKING PROCESS
ESLint governance model uses a consensus-seeking decision-making process, which is similar to formal consensus but with the additional option of a fallback voting procedure if consensus appears unattainable during the deliberations. The fallback voting option is only exercised after all reasonable attempts to address concerns have been exhausted. When consensus is deemed unattainable, the presenter or the facilitator can choose the closing option of a fallback vote.
EASE OF FINDING THE GOVERNANCE MODEL.
Finding the ESLint governance model is relatively easy. The website has a header section with a link to Docs. Clicking on this link takes you to the project documentation. Under Contributing to ESLint in the side panel, there is a link to Governance. Although it takes a few minutes to locate, the documentation is clear, concise, and easy for anyone to understand.
The BQplot Project is an open source software project with an objective of developing open-source software for exploratory and interactive data visualization.
The governance model of this project is based on the Steering council consisting of project contributors who participate daily in discussions, code review and other project activities as peers with all other contributors and the community to ensure the long-term wellbeing of the project technically and as a community. The Steering Council conducts regular meetings at least monthly to engage in discussions and offline votes on the Steering Council mailing list.
The Steering Council makes decisions about the overall administration, collaboration with other organizations, financial sources and major structural and systemic changes to the project.
They may also resolve code of conduct conflicts, grant or revoke privileges and mentor project contributors.
Openness & transparency, active contribution, institutional neutrality are key foundations of project governance.
A Project Contributor who has produced contributions that are substantial in quality and quantity, and has sustained over a year is eligible to be a council member. Also, council memberships lasts two years.
Project Contributors --They are developers and individuals who help with code contributions, documentation, designs, community management, etc.
Institutional Partners -- Institutions partners don't succeed any projects however, they are the project's primary funding mechanism. It is important to formally acknowledge institutional participation in the project.
Users of the Project
Nominating potential Steering council members is based on a successful vote by existing council members. If in any case, a Council member becomes inactive in the project for a long interval, they will be given a grace period of one year but if they do not return to active participation within that period, they will be removed by a vote of the Council without a further grace period.
The Council reserves the right to eject current Members, if they are deemed to be actively harmful to the project’s well-being and attempts at communication and conflict resolution have failed.
Changes to the governance documents are submitted via a GitHub pull request to The Project's governance documents GitHub repository.
This process has two phases; The discussion phase where the individual opens a pull-request (PR) in a draft state. They may call a vote when they believe enough feedback and iteration has occurred. Next is the Voting phase. A 4-week period where the PR is in the active state, the Steering Council votes on whether the changes are ratified. 2/3 of 80% votes must be in favor for the proposal to be a success.
I was able to locate the governance document in the bqplot repository. To understand furthermore, took some time and keen comprehension. If understanding difficulty had a scale of 1 - 5, I would give it a solid 3.8.
Overall, I am glad I was able to contribute to this project.
Name: Pamela Ropafadzo Pfunye
Assigned project: InterpretML (https://interpret.ml/)
InterpretML is a Python library intended for Machine Learning interpretation. This library makes use of methods that aid in the comprehension of how prediction models operate, such as feature impacts and feature significance. InterpretML contains a number of Partial Dependency Plots and Global Surrogate Models, all of which are interpretability approaches that help in understanding how a model should behave over many ranges. The library is beneficial for the development of transparent and explainable models, which is vital in many fields where comprehending and explaining about how model prediction works is essential.
Link(s) to the project governance model:
https://github.com/interpretml/interpret/blob/develop/GOVERNANCE.md
https://github.com/interpretml/governance/blob/master/org-governance.md
https://github.com/interpretml/governance
The governance model:
As InterpretML is an open-source project, it is further governed by a community led model. All their projects are hosted using GitHub, and anyone from the community is able to provide their contributions. The core of their development team includes maintainers who are responsible for the reviewing and the merging of all triaging issues, pull requests and ensuring the projects overall health. The governance model is designed to be transparent and open with a focus on inclusivity and collaboration. They ulitilize and follow a Contributor Covenant code of conduct that helps with maintaining an inclusive and welcoming community for all its contributors. All contributors are required to agree to this code of conduct, and any violations made are taken seriously and dealt with accordingly. The InterpretML governance model can be interpreted in a few different ways, depending on the perspective of the individual or organization involved in the project. From the perspective of an individual, the governance model can be interpreted as follows:
The governance model provides an organized framework for people who people who intend to add to the project, outlining the various roles and obligations involved as well as how decisions are made within the project. The governance model starts by defining the various positions within the project, such as maintainers, contributors, and evaluators. It describes the duties of maintainers, who are in charge of supervising the project's growth and assuring that contributions adhere to the project's objectives, goals and priorities. They are also in charge of maintaining the project's code repository as well as evaluating and integrating contributions. Contributors are people who contribute code, documentary evidence, or even other inputs to the project, according to the governance model. Individuals who provide comments and advice on submissions before they are merged into the codebase are known as reviewers. The governance model also describes the project's decision-making procedures. It explains how major choices are made through various procedures such as voting in which maintainers and contributors can vote on a proposition. This enables people to engage in the decision-making process while offering insight into how choices are made within the project. The governance model also explains the project's criteria and rules for participation. It stresses the significance of comprehensive testing and adhering to the project's coding guidelines. Additionally, the model promotes respectful communication and collaboration between contributors and maintainers.
Moreover, from the perspective of an organization, the governance model of InterpretML can be interpreted as follows:
The InterpretML governance model establishes a clear framework for interacting with the project and adding to its growth. The model defines the various duties and obligations of people within the project, such as maintainers, contributors, and reviewers, making it simpler for organizations to determine who they should communicate with and how they can add to the project.
The governance model also describes the project's decision-making procedures, which can be useful for organizations looking to understand how they can impact the project's path. The voting method for major choices guarantees that all contributors have a voice in project development, resulting in an equitable and democratic decision-making process. This can be encouraging for groups that want to ensure that their interests and objectives are considered in the project.
From an organizational standpoint, the guidelines and norms for adding to the initiative are also critical. Clear writing, comprehensive testing, and adherence to coding standards are all critical factors in assuring the project's codebase's quality and dependability. The governance model helps to ensure that contributions correspond with the project's objectives and standards by giving rules for participants to follow.
Project roles:
The governance model documentation provides numerous major positions that community members might take on, each with its own complement of objectives and obligations. The project roles include:
Decision-making process:
The InterpretML governance model specifies a decision-making process centered on developing consensus that includes discussions surrounding proposals and changes with Maintainers, the Steering Committee, and the community. This procedure guarantees that decisions are reached transparently and collaboratively, with participation from a wide spectrum of community members. This entails recognizing a choice that must be made, soliciting feedback from community members, debating the issue and alternative solutions, and finally making a conclusion. Maintainers often make decisions on small issues, whereas the Steering Committee makes decisions on larger issues that require more participation.
In some cases, the core development team may opt to decide through a vote procedure. This is usually done when conversation alone fails to produce an agreement. In these circumstances, the main development team and any additional stakeholders participating in the decision-making procedure vote. A simple majority vote is used to make the decision, and each stakeholder has an equal vote. The following are the important steps found in the decision-making process in InterpretML:
Proposal: Everyone can suggest for a modification or new feature in InterpretML through opening an issue on the project's issue log. A thorough description of the planned change, its advantages, and any possible disadvantages should be included in the proposal. The decision making process can be broken down into the following steps:
The main development team makes decisions about the project's direction and significant modifications to the software in collaboration with the community. Feature proposals and problem complaints can be made via the project's issue tracker, and discussions about possible adjustments can be found within the discussion forum.
How easy or difficult it was to find and understand the governance model?
The governance model for InterpretML can be viewed on the project's GitHub website, which is simple to locate and, moreover, open and visible to community members. The InterpretML initiative appears to emphasize on openness and clear communication, which aids in navigating the governance model and knowing their duties and obligations. With some work and engagement, the InterpretML governance model is readily accessible and understandable. The InterpretML governance model is easily accessible and comprehensible with some effort and engagement. Overall on a scale of 1-10 I would say the governance model scores an 9 in being easily accessible and an 8 in being understandable.
Name: Ewete Esther
Project Assigned: Signac
Link to Signac Governance Model: https://signac.io/governance/
Signac Governance Model:
The Signac governance model describes how participation takes place, what roles community members may be able to fill and the responsibilities and privileges these roles entail. There is no expectation of long-term commitment to the project, no specific skill requirements, and no selection process, however all contributors must abide by the project’s [Code of Conduct] (https://www.signac.io/conduct/) and each repository’s respective contributing guidelines. All committers are expected to be aware of the project's overall strategic development, for example, by participating in Slack or [Gitter channels] (https://gitter.im/signac/Lobby) and/or attending semi-regular development meetings. Potential committers must also have the technical proficiency required to assess code submissions, as well as a thorough comprehension of an agreement with the project's goals and strategy. It is expected that all project maintainers will participate in discussions and vote on whether to accept or reject committer and project maintainer nominations.
Project Roles:
The Signac governance model has a diverse group of roles that are essential for the success of the project. Each role has a specific set of responsibilities that contribute to the overall success of the project. They Include:
The Decision-Making Process:
The Signac project aims to create a strong and sustainable governance structure that reflects its members' needs and values. The decision-making process are:
1.The existing project maintainers must vote by two-thirds to approve new project maintainers.
If necessary, a project maintainer may also be dismissed from their position by the other project leads with a two-thirds vote.
By a majority vote, the project maintainers will decide whether to accept or reject the nomination.
The committer role may be revoked by the project maintainers by majority vote if necessary, such as after a prolonged period of inactivity.
How easy or difficult it was to find and understand the governance model:
I found the governance model relatively easy to understand and work with.
Name: Riya Sharma
Project: ESLint (https://eslint.org/)
Link to the ESLint Governance Model: (https://eslint.org/docs/latest/contribute/governance)
Link to the ESLint GitHub: (https://github.com/eslint/eslint)
ESLint is an open-source project which finds and fixes bugs in a JavaScript code. As an open-source project, ESLint relies on community contributions. Anyone can contribute at any moment by sending code, taking part in conversations, or making any other kind of contribution they deem appropriate.
The governance model has the following features:
The ESLint project welcomes contributions from the community, and encourages community members and users to become involved in the project by contributing code, documentation, or other resources. Community members can also provide feedback and suggestions directly through GitHub issues and pull requests, or by participating in the project's discussion forum over servers like discord. The governance model of the ESLint project is designed to be inclusive, transparent, consensus oriented and community-driven, with the goal of better user experience to its users and conducive development environment to its contributors.
The project roles and responsibilities of ESLint can be summarized as:
ESLint community follows the consensus seeking decision making which is a type of formal decision making accompanied with a fallback voting procedure. In this type of decision making all the community members and stakeholders can freely express their advices and all the concerns and opinions are taken into consideration. Then the TSC members formulates a broad consensus. This is done to ensure timely decision making. If the consensus is unattainable then fallback voting process is characterized by high number of votes with the idea that this approximates decision by consensus. This is controversial as minority issues get neglected. Designation of positions is an important part of decision making. The recruitment of committers, reviewers and website team members are nominated by previous members of that particular team. Then the final authority resides with TSC they vote for a potential candidate. The TSC can also remove anybody through TSC motion.
Altogether, the governance model is relatively easy to find and understand, especially for me who is familiar with open-source project governance models. I have actively participated in open-source activities at college so, I am quite familiar with the technicalities and documentation process. This might be a cumbersome process for people new beginners, who have just started their journey in open source.
Name: Veronica EMIOLA
Project: PyTorch
Link to PyTorch's governance model: https://pytorch.org/docs/master/community/governance.html
PyTorch Governance Model
PyTorch is an open-source machine learning library that is widely used for building deep neural networks. It provides tools and utilities for building and training models in Python, as well as a flexible and dynamic framework for implementing custom network architectures. PyTorch has a large and active community of contributors, who engage in discussion and collaboration through various channels such as GitHub, forums, and social media. Contributing to PyTorch is easy and straightforward, with opportunities to contribute code, documentation, and other resources through pull requests, issue reporting, and other means. The project also has a well-documented governance model, with clear roles and decision-making processes in place to ensure that the project remains community-driven.
PyTorch Project Roles
Community: The community contribute, file issues, make proposals, review pull requests and contribute to the project.
Module Maintainers: Module maintainers are responsible for the development and maintenance of specific modules within PyTorch.
Core Maintainers: Core maintainers provide technical leadership and oversee the development of the project as a whole.
Lead Core Maintainers: Lead core maintainers are responsible for coordinating the activities of the core maintainers and ensuring that the project is moving forward in a timely and effective manner.
Decision Making Process
The decision-making process in PyTorch is designed to be open and transparent, with community input being solicited for important decisions. When necessary, decisions are made through a voting process, with a simple majority of votes being required for approval. All voting is conducted publicly, and decisions are documented and shared with the wider community. This process helps to ensure that decisions are made in a fair and democratic manner, with the interests of the wider community being taken into account.
Understanding PyTorch Governance Model
PyTorch's governance model is well-documented and easily accessible on their website and GitHub page. The roles and decision-making processes are clearly outlined, and the model is designed to encourage collaboration and participation from the wider community. Overall, it is relatively easy to find and understand PyTorch's governance model, which helps to foster a more transparent and inclusive development process.
The HoloViz project follows a hierarchical governance structure. The ranks are listed below from the lowest to the highest
Contributors Are those who contribute the HoloViz project. Their tasks include creating issues, participating in discussions, and creating pull requests.
Maintainers Are those who coordinate activities around the development, maintenance, and update of the project. They are decision makers in all the aspects of the project. Maintainers are Contributors who are active participants with GitHub permissions. The project may add Maintainers by agreement primarily or by vote. Inactive Maintainers may also be voted out.
The Lead Maintainer manages the technical aspects of the project in addition to the responsibilities of a Maintainer.
The Lean Maintainer must be highly involved in all aspects of the project. Maintainers may add or remove a Lead Maintainer by consensus or by vote if consensus cannot be reached.
The Project Director is responsible for setting the scope and overall direction of the project in addition to the responsibilities of a Maintainers. The project director can also reject the result of vote by Maintainers in some cases. The Project Director can be elected/removed by Maintainers by a 4/5 vote.
The governance model was not hard to find it was summarized on the site and the link to the actual document was also provided on the site. Also the governance model is quite easy to understand.
Name: Olamide Oladipo
Project: Yellowbrick
Link to the project GitHub repository https://github.com/DistrictDataLabs/yellowbrick/tree/main
Link to Yellowbrick Governance model https://www.scikit-yb.org/en/latest/governance/index.html
Yellowbrick is an open-source project that is maintained by a core team of contributors. The governance model is designed to be inclusive and transparent, with the goal of ensuring that the project is driven by community needs and contributions.
The governance model is based on the following principles:
The Yellowbrick project is maintained by a core team of contributors, who are responsible for reviewing and merging pull requests, maintaining the project's codebase and documentation, and making decisions about the direction of the project. The core team is also responsible for ensuring that the governance model is followed and that the project remains true to its principles.
The Yellowbrick project welcomes contributions from all members of the community, and encourages community members to become involved in the project by contributing code, documentation, or other resources. Community members can also provide feedback and suggestions through GitHub issues and pull requests, or by participating in the project's discussion forum.
Overall, the governance model of the Yellowbrick project is designed to be inclusive, transparent, and community-driven, with the goal of ensuring that the project remains responsive to the needs of its users and contributors.
In the Yellowbrick project, there are several project roles:
This is a summary on the project roles there are more specific details on each project role in the Yellowbrick governance model documentation.
The process is designed to be inclusive and transparent, with the goal of ensuring that all stakeholders have a voice in project decisions.
The decision-making process are as follows:
Overall, the governance model is relatively easy to find and understand, especially for someone who is familiar with open-source project governance models. However, individuals who are new to open-source development or who are unfamiliar with governance models may find the section to be somewhat technical or difficult to understand aspects like the different project roles and to know what role they are to play in contributing to the project. Also, the decision making process might be thorny for people who are new to open-source governance models as they might not know how and when votes are being conducted on proposals. In these cases, it may be helpful to seek additional resources or guidance from the Yellowbrick community through their main GitHub Repository https://github.com/DistrictDataLabs/yellowbrick/tree/main.
o Name: Aayushi Chauhan
o Project Assigned: OpenRefine (https://openrefine.org/)
o Link to the project governance model: https://github.com/matrix-msu/Enslaved-OpenRefine/blob/e5ff1107b703ab6df3e1a970d871d79e08f8017c/GOVERNANCE.md
o Governance Model:
OpenRefine is a powerful open source that focus on working on messy data, this involves cleaning the data, transforming it from one form to another, matching the data with external databases via reconciliation services, and fixing inconsistencies by merging the similar values in data. It also takes proper care of the privacy of the data; the processes take place in our own device and not on some cloud.
Project Roles:
a. Users: These are the members who use the project, these users give the project a purpose.
b. Contributors: These are the members who contribute to the project, either one time or multiple times.
c. Committers: These are the members who have a deep understanding on the project strategy and have worked closely with users and contributors.
Decision Making Process:
OpenRefine uses the Apache Decision making to decide the future of the project. This involves:
a. Lazy Consensus: This means that one does not need an explicit approval from users to proceed, silence is also treated as a consent. This is done to avoid unnecessary discussions but one needs to be prepared if someone objects.
b. Consensus Building: This is done to get the feedback of the users before introducing any new feature. There are notations like:
• +1: This means that I agree with the project and will help to make it happen.
• +0: This means that I agree with the project but will not make it happen.
• -0: This means that I do not agree with the project but I am offering no alternative.
• -1: This means that I do not agree with the project but I am offering an alternative.
c. Voting: In this, not just consensus plays a part but a proper voting takes place to get the numbers.
Decision making is done in a transparent, open manner. No decisions about the project’s bug fixes or features is done without community involvement and participation. Discussions must begin at the earliest possible point, the community’s participation is vital during the entire decision-making process.
The Governance Model of OpenRefine was easy to comprehend and while reading about it I got familiar with some decision making processes and how an open source software works, how open source contribution happens and much more. Overall, it was a wonderful and interesting task, any views are welcome.
Name: Samuel Busayo
Project: Signac
Link to governance model: https://signac.io/governance/
Signac follows a community-based governance model. This allows any willing participant to contribute to the project and participate in the decision-making process. The community make decisions by voting, and the decision will stand if two-thirds of the community approves.
Signac employs a rotating management approach to select project managers. The project manager is selected from within a pool of project maintainers and committers. Maintainers and committers are preferred for the managerial role because they are people who have shown exceptional commitment to the project.
The community measures success by evaluating the different perspectives of the project users.
The following are roles a contributor can take up in Signac:
Although, most of the decision making process in Signac is made by the community, project maintainers and other administrators are more involved in making these decisions:
I was able to quickly locate the link to the governance model on the website's navigation bar. I found Signac's governance model to be clear and concise, so I had no issues collating my points for this task.
Name: Rufus Godgift
Project: OpenRefine
Link to project Governance model: https://github.com/OpenRefine/OpenRefine/blob/master/GOVERNANCE.md
OpenRefine is a free open-source powerful project developed to manage and clean data for users. This project allows contributors to modify, distribute and make name changes on the project.
Governance Model
The governance model of OpenRefine is structured to ensure that the project is managed transparently, with active participation from the community.
Project Roles
The project roles in OpenRefine are divided into:
Users: these are community members who have a need for the project. They give the project it's purpose through their usage.
Contributors: these are users that get close involvement with the project by supporting new users, writing and maintaining documentation, submitting patches to fix bug. Etc.
Committees: committers that make regular contribution on OpenRefine are made committers by nomination by current committers.
Release Manager: they are responsible to coordinate with community to select appropriate issue to work on and also prepare and coordinate publishing new releases.
Steering Committee: they oversee the general direction of the project and initiate connections and collaborations with other organizations and projects.
Advisory committee: they are made up of atleast three members responsible for running the day to day administration of the project with support from Code for Science and Society (CS&S).
Project Director: works closely with the advisory and steering Committees and it's community of users. He/she helps to improve the governance and community diversity.
Decision-Making Process
The decision-making process in OpenRefine is based on a User consensus model. Decision making is done in a transparent, open fashion by using OpenRefine discussion list and issue list. No decision is taken without community involvement. The steering Committee reviews and approves technical proposals based on the consensus of the community. The steering members vote on proposals, and a proposal is approved if it receives a majority of votes.
Ease of Understanding
The governance model of OpenRefine is easily accessible on their GitHub channel.The channel provides a clear description of the project's governance structure, project roles, and decision-making process. Additionally, the channel provides information on how to become a contributor as well as useful list in the project. Overall, the governance model is well-defined and easy to understand.
Conclusion
The governance model of OpenRefine ensures community engagement, transparency, and accountability in the project's decision-making process. The Steering Committee manages the project's technical aspects. The decision-making process is based on a consensus model, and the governance model is easily accessible and understandable. Overall, the governance model of OpenRefine is well-structured and fosters a collaborative community.
Name: Bhaswati Roy
Project: Yellobrick
Project Governance Model Link: https://www.scikit-yb.org/en/latest/governance/index.html
Yellowbrick is an open-source Python library for visual analysis and diagnostics with machine learning. It has grown from a handful of users to thousands of users, dozens of contributors, and several organizational affiliations. Establishing a system of governance will facilitate decision-making processes and define how members interact, and this helps in the easy maintenance of the project. The Yellowbrick Governance Document serves as guidance for Yellowbrick members, as well as bylaws for Yellowbrick contributors. "The scikit-yb developers" are a group of volunteer contributors who maintain the project.
By using Yellowbrick, contributors gain the necessary understanding and context to meaningfully contribute. When they give something back to the Yellowbrick community, whether it is large or small, whether it is code or a skill they possess, they become contributors. Contributors can give back to the community by contributing to building or translating documentation, submitting issues related to feature requests or bugs, writing a blog post, or answer a query on StackOverflow, or even organizing Yellowbrick user meetups or other events. Some of the major project roles under the Yellowbrick community include -
Core Contributors: Yellobrick's core contributors commit to a four-month-long semester of maintenance and development, setting specific and reasonable goals for their quality contributions all over the semester.
Maintainers: The Yellobrick core team includes maintainers who review, merge, and make decisions about the project's direction. They ensure that the project's documentation and codebase are maintained. They also ensure that the project log is kept up to date.
Advisors: A Yellowbrick advisor is a person who offers assistance and expertise in a specific area such as machine learning, web development, open source, etc.
Coordinators: Coordinators are experts in project management aspects of version releases, as well as directing traffic to the group that is actively engaged.
Mentor Coordinator: The Mentor Coordinator role has the objective of helping Yellobrick to find and establish a pipeline of new contributors by taking on all of the responsibilities of a core contributor.
One of the advisors must propose a vote, which is then submitted to the chair who decides if the vote can proceed. It is necessary to have a quorum of all advisors present or accounted for in some way in order to hold a vote. A minimum of five minutes must be allowed for discussion before the vote. The vote can be conducted in two ways: either by secret ballot or by counting the individual votes of advisors. The proposal passes if a majority of advisors vote "yea", and is rejected if a majority votes "nay". Founders are the only ones who can ratify a proposal, and they have the final say in all decision-making. A veto by the founding members cannot be overturned.
For someone familiar with open-source project governance models, the governance model is relatively easy to understand. The section, however, may be a bit technical for individuals who are unfamiliar with open-source development or governance models. It may be difficult for them to understand aspects such as the different project roles and the role they are expected to play in contributing to the project. This is because they are unfamiliar with them.
The decision-making process might be difficult and cumbersome for people who are absolutely new to open-source governance models as they might not know how and when votes are being conducted on proposals. In these situations, it may be helpful to seek additional resources or guidance from the Yellowbrick community through their main GitHub repository.
Name: Sai Mimansa Gupta
Project: QuTiP
The project's governance model: https://github.com/qutip/governance/blob/main/governance.md
QuTiP is an open-source software for simulating the dynamics of open quantum systems. It is freely available for use and modification on all major platforms such as Linux, Mac OSX, and Windows. It is free of any licensing fees and is ideal for exploring quantum mechanics and dynamics in the classroom for educational as well as state-of-the-art research purposes.
All software developed under the QuTiP Github organization is hosted at www.github.com/qutip. All QuTiP project members and contributors should abide by the Code of Conduct.
The development of QuTiP is a community-based effort with developers contributing and adding new features to the growing list of its functions. People who wish to contribute to the project can do so by installing QuTiP from here, further they can fix bugs or add enhancements to the project with Pull Requests. To discuss any bugs or ideas related to the project, they can communicate with other community members through The Google Forum, QuTiP News and the Issue Tracker.
The decision-making involves three ways:
Every year an annual report is drafted by an Admin Team member which is further sent for review to the QuTiP board. The annual reports for the last two years can be found here.
I am entirely new to Open-Source so the term governance model was new to me. But, as I researched about it the term now is not foreign to me anymore. For this project, I found the governance model conveniently from the official website itself under the 'Devs' link. As I started reading the governance document everything was precisely written in points so it was comprehensible on the first go, hence I would say it was quite easy to understand it.
GNU Radio is a flexible software toolset for implementing software radio with inexpensive hardware or simulation. It supports study on wireless communications and actual radio systems in academic, industrial, governmental, and recreational settings.
The governance model of the GNU Radio organization is defined by its articles of association (AOA), which set out the rules and procedures for the organization's operation. Online voting is a crucial component of decision-making within the organization, with specific types of decisions being allowed for online voting under the AOA, such as new members, rules, and financial transactions. The GNU Radio Organization also permits online voting for decisions not explicitly covered by the AOA. Different types of online voting are available, each with unique procedures and methods for calculating results. Members of the organization are granted varying voting rights based on their level of involvement, such as associate or corporate members. The GNU Radio Organization is dedicated to maintaining these principles and regularly updating its governance procedures to meet the changing needs of its members
The project positions in the government model have varying degrees of authority and responsibility which can be described as follows:
The General Assembly is composed of the active members of the Association, each of whom has one vote. General Assembly makes decisions for the Association, elects the board, and reviews the annual report. It also has the exclusive right to decide on financial transactions and matters submitted by the board or members. Only certain items, such as board elections and changes to the Articles of Association, can be decided in a real-time assembly. A two-thirds majority is required for removing a member from the board.
The Board is comprised of 3 active members who serve a 2-year term and can be re-elected. A president and two proxies are elected from the Board. The Board's duties are outlined in their by-laws, and they make decisions for the Association, implementing decisions from the General Assembly. Each Board member can represent the Association, and a provisional board member is appointed via internet vote if a member resigns. The General Assembly decides on the definite succession and must be informed of any regulatory, court or financial amendments to the Articles of Association.
The GNU Radio Organization is committed to upholding these values and continuously refining its governance procedures to meet the evolving needs of its members.
Based on my research experience, I was able to find and understand their governance model without much difficulty. However, I had to conduct additional research to locate their official Github repository as it was not available on their webpage. The repository provided all the necessary information in a clear and descriptive manner.
Name: Queeneth Ogbonna
Project: QuTip: https://qutip.org/index.html
Link to the QuTip Governance Model: https://github.com/qutip/governance/blob/main/governance.md
Link to the QuTip GitHub: https://github.com/qutip
QuTiP, an open-source software package written in Python, provides users with a variety of tools to learn and simulate quantum systems. It is a versatile toolbox that allows users to explore the intricacies of quantum mechanics, study noise and dissipation effects on quantum systems, and perform advanced research in quantum science.
The top-notch numerical packages Scipy, Numpy, and Cython are all necessary for the QuTiP library to function. Additionally, Matplotlib offers graphical output.
The Community
QuTiP has fostered a dynamic ecosystem and community of individuals who contribute to and use the software. The community has created a wide range of tools that facilitate the study of different aspects of quantum physics and information processing. QuTiP has over 80 code contributors and has been downloaded over 300,000 times by thousands of users, making it an invaluable resource for researchers and enthusiasts.
GOVERNANCE MODEL:
QuTip Code Of Conduct
QuTiP values inclusivity and respect for all individuals who contribute to the project. They strive to provide a harassment-free experience regardless of gender, gender identity, and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, or nationality. Those who violate this policy will be permanently removed from the project.
Project Roles
Core Contributors and Contributors:
They are project maintainers who have the right and responsibility to manage and oversee the project. They may remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions as necessary.
Admin Team:
The Admin Team keeps the QuTiP project lively, maintaining the software, and expanding and improving its features.
They are responsible for technical code development and managing QuTiP-related activities which include maintaining the project through software updates and bug fixes, developing new features, participating in forums, providing support, and mentoring others.
Board Members:
The Board Members are in charge of providing scientific advice, monitoring the project's progress, and ensuring that the Admin Team and the project have adequate financial and logistical support. The Board Members are volunteers who pledge to fulfill the responsibilities assigned to them.
Non-Profit Support:
QuTiP is an affiliated project of NumFOCUS, and their primary responsibility is to promote QuTiP knowledge in the quantum software and sci-dev communities amongst other responsibilities.
Decision-Making Process
The voting Process and decision making is made in groups:
Voting Process For Admin:
Core developers and significant contributors are chosen and elected by the already existing admin team to make up the admin team. Candidates who are not nominated may also submit their own applications with statements outlining their prior involvement with QuTiP and their dedication to the organization's future.
Decision-making For Admin:
Each member of the Admin Team has a vote when making decisions. Prior to making changes, they also make an effort to solicit feedback from the larger community and promptly communicate significant software updates.
Voting Process For Board Members:
The admin team initially selected the members of the Board based on their potential to support the project's growth and their willingness to join. New members may be proposed by current board members or elected by the admin team and existing board members.
As part of their application, potential board members can also include statements about their prior involvement with QuTiP and their dedication to the organization's future. Seats on the Board are held indefinitely, and there must be a minimum of three members and a maximum of seven. A board member who does not participate in the project or does not show up for meetings may be removed by a majority vote.
Decision-Making For Board Members:
Every board member has one vote, and decisions are made by a majority of votes cast.
How Easy Or Difficult Was It To Find And Understand The Governance Model?
At first, I found it a bit challenging to locate the governance model of the QuTip project, as it wasn't immediately obvious where to find it. However, after doing some research on the meaning of governance models, quantum Python, and the project's affiliation with NumFOCUS, I was able to grasp the concept and figure out how to complete the task. Despite the initial difficulty, the process of familiarizing myself with these topics turned out to be a valuable learning experience. Overall, I was able to successfully complete the task and gained a better understanding of open-source project governance in the process.
Name: Precious Nzeakor
Project: Electron
https://www.electronjs.org/governance
OVERVIEW
Electron is described as framework for building desktop applications using JavaScript, HTML, and CSS. By embedding Chromium and Node.js into its binary.
Electron allows you to maintain one JavaScript codebase and create cross-platform apps that work on Windows, macOS, and Linux — no native development experience required.
Electron Governance
The Electron governance system is comprised:
Working Groups: Working Groups oversee different aspects of the Electron ecosystem.
Administrative working group: The Administrative Working Group (AWG) oversees the entire governance and project. They functions to resolve conflicts between them.
Working Groups and Roles
General Responsibilities
All Working Groups have these core responsibilities:
• They shall decide for themselves, and publicly post, their rules, e.g. how decisions are made, when meetings are held, and who may attend.
• They shall select a chair to represent the group.
• They shall keep meeting notes, including agenda items, discussion points, and outcomes for everyone to review.
• They shall be collaborative and work in good faith with other Working Groups.
The Decision-making Process
One of the advisors must propose a vote, which is then submitted to the chair who decides if the vote can proceed. It is necessary to have a quorum of all advisors present or accounted for in some way in order to hold a vote. A minimum of five minutes must be allowed for discussion before the vote. The vote can be conducted in two ways: either by secret ballot or by counting the individual votes of advisors. The proposal passes if a majority of advisors vote "yea", and is rejected if a majority votes "nay". Founders are the only ones who can ratify a proposal, and they have the final say in all decision-making. A veto by the founding members cannot be overturned.
How easy or difficult it was to find and
understand the governance model:
It was quite challenging for me, to figure it out. I had to read almost everything in the website. But it worth the while, I have better understanding in project now.
This link https://github.com/electron/governance/blob/main/README.md I got from the website really helped me in clear understanding.
Name: Deborah Oyegue
Project: Electron
Project Governance Model
Electron is a framework that allows you to build desktop applications using CSS, HTML, and JavaScript. This cross-platform application builder will enable you to maintain a single JavaScript codebase with little to no development experience.
Electron operates on the Electoral Governance Model, which means that elections determine governance. In an electoral model of governance, community members have the power to vote and decide on various aspects of the project's governance, such as electing individuals for different roles or approving updates to policies and procedures. The community agrees upon and documents the electoral procedures that will be used, and these procedures are consistently applied in decision-making processes.
This model is helpful for large open-source projects because it provides a clear framework for sponsors and potential contributors. Electron shows this by providing detailed documentation of its decision-making processes, procedures, project roles, and contribution guidelines.
As a characteristic of the Electoral governance model, Electron has the project roles explicitly stated on its website. The project roles include:
In Electron, the different working groups are in charge of various operations of the project, such as managing API designs to ensure they meet the standard design principles, managing the community to ensure safety and adherence to the code of conduct, managing projects in the ecosystem, developing and implementing strategies to grow the community, managing software releases, and ensuring project security. While the administrative working group manages all the working groups in the Electron ecosystem.
The administrative group has the responsibility of overseeing other working groups to manage conflicts and ensure interoperability within the Electron ecosystem. If you want to join any of the working groups, you need to contact an existing member who will submit a case on your behalf to be voted on by at least 2/3 of the working group members (your acceptance depends heavily on collaboration with and contributions to the community). However, becoming a member of the administrative working group requires a higher level of expertise. Members must have prior experience managing substantial parts of the project and supporting contributors.
The governance model used in the open-source project implementation was straightforward and easy to understand. This can be attributed to the clear documentation of the governance model on the project website, which includes links to different working groups (project roles) and contribution guidelines.
ESLint is a tool for finding patterns in ECMAScript and JavaScript code and reporting them in order to improve consistency and prevent bugs. You can add more plugins at runtime because every rule is a plugin.
The ESLint allows everyone to be a contributor to the project. Contributions are measured as suggestions, changes to the code base, feedback on the software, etc. Everyone is allowed to make a contribution, but the final decision-making process is done through a consensus model by the Technical Steering Committee.
The ESLint project uses an electoral governance model where they hold elections to fill various project roles, or hold similar elections to make changes to the project's policies and procedures. By using this model, the community agree on and document electoral procedures, which they then enact as a regular matter of decision-making(this can be found in the projects documentation). For the ESLint everyone is allowed to make a suggestion or contribute to the project but the Technical Steering community has the highest voting right and final say on community policies, nominations, removal, etc.
A consensus-seeking process is used to reach a decision.
Personally, it was easy for me to find the governance model due to my experience with open-source projects. I checked the documentation of the project and found their governance model. Understanding it was also easy, and I found an exciting thing about their projects electoral process, although decision-making was done through votes, only members of the Technical Steering Committee (TSC) had the right to make the final decision.
Which brings me to ask "Can a project use more than one governance model?'
Finally, for open-source projects, a project governance model has advantages. First, it reduces the risk of project abandonment or non-maintenance; second, it promotes diversity in contributions by listing roles and responsibilities and create a safe environment for innovation.
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.
The Carpentries is a global non-profit organization that teaches researchers foundational coding and data science skills worldwide. Its mission is to empower researchers to work more efficiently and effectively by providing training in best practices for data-driven research. The Carpentries achieves this through a network of volunteer instructors who teach workshops on topics such as data cleaning, analysis, and visualization. The organization has a robust community-driven governance model that ensures transparency and inclusivity in decision-making. The Carpentries' decentralized structure allows for local and regional communities to organize and conduct workshops independently while being supported by centralized resources and staff. The Carpentries' emphasis on community involvement and engagement has created a vibrant and active community of instructors, learners, and supporters who are committed to advancing data-driven research.
The Carpentries' decision-making process is designed to be transparent and inclusive, with a focus on community involvement and engagement. Here are the steps of the decision-making process for The Carpentries governance model:
It was not difficult to learn about this governance model since the website was easy to navigate and each section provides proper information.
Name: Jermin Amartey
Assigned Project: PySal Governance Model
Link To Project Governance Model : https://github.com/pysal/governance
Python Spatial Analysis Library, PySal is an open source cross-platform project. The project's objective is to create an open source software for geospatial data science in Python, in particular the PySAL library including the pysal Meta-Package and its component Sub-Modules.
THE GOVERNANCE MODEL:
The foundations of the governance are based on
PROJECT ROLES:
THE DECISION MAKING PROCESS
Typically, project decision are made through a consensus among the Core Developers with input from the community. The BDFL has the authority to make all the final decisions of the project. In situations where there is a deadlock in decision making between the steering council, the council asks the BDL to make a decision which is often termed as the "special" vote or the "overriding" vote.
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.
FINDING THE GOVERNANCE MODEL
Their governance model wasn't difficult to find and understand. I was directed to their official Github repo from their webpage. All the governance and decision making process was clearly stated and described there.
1.1. Maintainers
1.2. Contributors
2.1. Consensus-Based Decision Making: Decisions are made by consensus among the Maintainers. Although it is preferable for all Maintainers to explicitly agree, it is not necessary for consensus. Rather, the Maintainers will evaluate consensus based on several factors, including the dominant view of the Contributors and the nature of the support and objections, in good faith. The Maintainers will document evidence of consensus in accordance with the established criteria.
2.2. Appeal Process: If a decision is disputed, it may be appealed by raising an issue. The Maintainers will review the appeal in good faith and respond in writing within a reasonable time. If the appeal is rejected by the Maintainers, it may be further reviewed by the TSC, who will also provide a written response within a reasonable period.
The Governance Model of InterpretML was easy to find as it was available in the repository of the InterpretML. Talking about the understanding of the InterpretML's Governance Model, it was easy to comprehend and understand as it is really well written, compact and understandable. While reading about the Governance Model I also came across the work ethics of the project which are very good reasonable. This was all. I hope this analysis helps in understanding better about the Governance Model of InterpretML. Any views or suggestion for improvement are welcome.
CVXPY is a Python-embedded modeling language for convex optimization problems, such as least-squares and linear programming. The goal of CVXPY is to improve accessibility and expand the scope of third-party convex optimization solvers.
CVXPY governance model can be accessed here.
More information on CVXPY can be found here.
CVXPY allows every community member to contribute to the project. Contributions made by members of the community are highly valued. However, CVXPY operates a founder-leader governance model, where the final decision-maker for the project is the Benevolent Dictator For Life (BDFL).
Also, the Steering Committee and the Project Maintainers serve as CVXPY's self-appointed council or board. The Project Maintainers have the last direct impact on the outcome of the CVXPY project, and the Steering Committee is in charge of all other non-technical decisions.
The different entities that exist within the CVXPY project are as follows:
Benevolent Dictator For Life: The benevolent dictator for life (BDFL) is the project founder, Steven Diamond. This title is given to a few open-source software development leaders, typically project founders, who retain the final say in disputes or arguments within the community.
Project Maintainers: The technical development leads for the CVXPY project are the project maintainers. They are in charge of overseeing the CVXPY project in the final analysis.
Emeritus Project Maintainers: These are individuals of the community who once served as project maintainers but have since reduced their level of activity.
Steering committee: The Steering Committee consists of five people. The committee is in charge of running CVXPY's legal and administrative affairs.
To make sure that any money are used in a way that advances CVXPY's objective, all financial decisions are decided by the Steering Committee.
The Project Maintainers reach consensus on all non-financial actions.
Although decisions in CVXPY are made by consensus, the BDFL ultimately has the last say.
The Project Maintainers and the Steering Committee reserve the highest voting rights.
Every member of the community who has actively participated in the project is eligible for nomination and appointment by the committee.
Contributors with commit access are trusted to use the CVXPY repository in a way that is compliant with the decision-making process. All contributions are made through pull requests that are approved by the Project Maintainers.
Finding the governance model was very easy, as it was just in the GitHub repository of the project. It was very interesting for me, as it was easy to navigate through and understand.
I got to discover that CVXPY operates 2 governance models - the founder-leader governance model and a self-appointing council or board (an electoral kind-of governance model).
Name : Maryam Gbemisola
Project Name : CVXPY
Project Link : https://github.com/cvxpy
CVXPY is an open source Python-embedded modeling language for Convex optimization problems, allowing users to express their problem in a natural way.
• The Mission
• Code of Conduct
• Entities
• Decision Making Process
• Conflict of Interest
• GitHub Permission
• Community Involvement
CVXPY Project aims to make Convex Optimization accessible to lay people while retaining its efficiency and extensiveness.
The CVXPY Community is committed to Inclusivity and Diversity and respect among members.
This section outlines the different entities that exist within the CVXPY project, their appointment and basic roles
a. Benevolent Dictator for Life
Steven Diamond is the Creator of CVXPY and therefore is the [Benevolent Dictator for Life BDFL.
b. Project Maintainers
The CVXPY project's technical development Leaders have the final say on the project's direction and must be active members of the community who have contributed to the repository for a long time. The current Project Maintainers are:
• Steven Diamond (@SteveDiamond)
• Akshay Agrawal (@akshaya)
• Riley Murray (@rileyjmurray)
• Philipp Schiele (@phschiele)
• Bartolomeo Stellato (@bstellato).
c. Emeritus Project Maintainers
These are community members who were Project Maintainers, but have stepped back to a less active role, having informed the other Project Maintainers and the Steering Committee.
d. Steering Committee
This Community Members serve as administrative and legal representatives for CVXPY, approve expenses, negotiate contracts, and maintain a quorum of five members.
The current member of the Steering Committees include.
• Stephen Boyd (Stanford)
• Steven Diamond (BlackRock AI)
• Akshay Agrawal (Stanford)
• Bartolomeo Stellato (Princeton)
• Riley Murray (Berkeley)
a. Financial Decisions
Members of the community can make recommendations to the Steering Committee to ensure that monies are used to further CVXPY's objectives.
b. Non-financial Decisions
Non-financial decisions are decided by consensus of the Project Maintainers, with the Steering Committee receiving additional decision-making power if necessary. Code-related and non code related decisions should be discussed in GitHub issues and pull requests or on a developer call
CVXPY members shold disclose and discuss any conflicts of interest, such as financial interests or access to private information, and refrain from making decisions when such conflicts exist.
The CVXPY GitHub repository is controlled by GitHub permissions, which allow anyone with commit access to utilize it in accordance with the Decision Making Process.
CVXPY is an open-source project that communicates with its community via four primary channels: Community Forums, Discord Server, Google Group, and GitHub Discussions. Contributors may be invited as Project Maintainers to the Discord server and may create extra channels for specific long-term initiatives.
Additional Information
This is a a Review of CVXPY Governance Model
To know more about CVXPY click here
Kindly click on the blue ink words to learn more about Complex Words and Member's Profile.
I was able to easily locate the Governance Model in the main Repository and it is nicely laid out.
Name: Adenike Ateloye
Project Assigned: Signac
Link to Signac Governance Model: https://signac.io/governance/
Signac Governance model
The signac project is an open-source community initiative with the aim of creating data management and processing software. Everyone who becomes interested in the project is welcome to join the group and participate in decision-making and project design.
Signac governance outlines the process by which contributions are made, the role that community members may play, as well as the responsibilities and advantages these roles include.
The management, supervision, and decision-making processes for projects are governed by a set of rules, protocols, and policies known as project governance. As part of the management process, project governance establishes the benchmark by which projects are judged to have been successful.
Project roles
A variety of roles play a part in the project's success under the Signac governance paradigm. They consist of:
Users
Contributors
Committers
Project maintainers
Administrators
Project Managers
o Triage Manager
o Community Manager
Decision-Making process
Project maintainers have a significant role in decision-making at Signac, however administrators and committers may also participate in some cases. They consist of;
The acceptance or rejection of committer and project maintainer nominations, as well as debates and decision-making processes on the project's strategic direction, are expected of all project maintainers.
Little improvements (to documentation, code, or CI settings) can be made by maintainers who are also committers without a pull request.
Any member of the community who has demonstrated outstanding dedication to the signac project and command of its overarching goals may be extended an invitation to take on the role of project maintainer. The present project maintainers must vote by two-thirds to approve new project maintainers.
The (self) nomination process is used to find new committers. By a majority vote, the project maintainers will decide whether to approve or reject the nomination.
If necessary, such as after an extended period of inactivity, the project maintainers may revoke the committer role by majority vote.
How simple or complicated it was to locate and comprehend the governance model:
On the website's navigation bar, I readily found the link to the governance model. I thought the governance structure of Signac was straightforward and precise, thus I had no trouble compiling my points for this work.
I struggled, though, to add the proper label to the issue in the repository, which was eventually fixed.
Name : Khadijah Amusat
Project Assigned : Bento Ml
Governance Model
BentoML's governance system is meritocratic and consensus-based.
Everyone with an interest in the project is welcome to join the community, contribute to it, and participate in decision making. And below are document that aims to define how that involvement takes place.
1 Contributors
2 Core Team
3 Benevolent dictator (project lead)
Decisions concerning the project's future are determined in consultation with all members of the community, from the newest user to the most experienced PMC member. The BentoML contributors mailing list is where all non-sensitive project management conversation takes happen.
To avoid being mired down by protracted debate and vote, the project employs a policy of lazy consensus. This enables for majority choices to be reached without the need for a formal vote.
Decision making typically involves the following steps:
Every community member can propose a proposal for the community to consider. They should send an email to the BentoML contributors' list or write a Github issue outlining the new concept to start a conversation about it. This will cause the concept to be reviewed and, if necessary, discussed. This review and debate is intended to acquire approval for the contribution. Because most members in the project community have a common vision, there is frequently little need for dialogue to obtain agreement.
In general, a proposal or patch is considered to have community support as long as no one expressly opposes it. This is known as lazy consensus, and it means that individuals who have not expressed their view explicitly have implicitly consented to the proposal's adoption.
Lazy consensus is a crucial notion in the project. This technique enables a big number of individuals to create an efficient agreement since someone who has no objections to a proposal does not need to spend time articulating their stance, and others do not need to spend time reading such messages.
Allowing at least 72 hours before presuming that there are no objections to the idea is required for lazy consensus to be successful. This stipulation guarantees that everyone has sufficient time to read, absorb, and reply to the proposal. This time span was intended to be as inclusive to all participants as possible, regardless of their location or time obligations.
Lazy consensus is not appropriate for all decisions. Problems affecting the project's strategic direction or legal status must be explicitly approved by the Core Team, which will use the Apache Foundation voting process.
Every member of the community is urged to participate in all discussions and votes. Yet, only Core Team members have binding votes in decision making.
That was fairly simple because the guidelines mentioned that the governance may be available on the website or on the project's Github.
Because of my web3 experience, I understand what a governance model is and how it works, and I am a member of three separate DAOS (Decentralized Autonomous Organizations), which are community-led entities with no central authority. The DAO's activities are quite similar to the governance model.
Names: Bonte Emma Bana
Project I was assigned to: Pysal
Project Link: http://pysal.org/
Link to the governance model: https://github.com/pysal/governance
A little bit about PySAL
PySAL is a Python library designed for spatial analysis, with a focus on geographic information systems and spatial econometrics. PySAL provides a wide range of spatial analysis tools and methods for analyzing and modeling spatial data, including spatial autocorrelation, spatial clustering, spatial regression, and spatial visualization. The library is built on top of NumPy, SciPy, and Matplotlib, making it easy to integrate into existing Python workflows. PySAL has an active community of contributors and users, and it is continually updated and improved with new features and capabilities. PySAL is open-source and freely available under the BSD license, allowing for both academic and commercial use. Overall, PySAL is a powerful tool for spatial analysis and modeling in Python, and it is widely used in both academia and industry for a range of applications, including regional planning, environmental analysis, and economic geography.
PySAL governance model:
The PySAL project has a well-defined governance model outlined in their GitHub repository, specifically in the "governance" folder. The model is based on a steering committee consisting of members who have made significant contributions to the project. The steering committee is responsible for making decisions related to project development, releases, and management. The project also has maintainers who are responsible for maintaining specific parts of the project codebase. The decision-making process for the PySAL project is based on consensus among the steering committee members. However, in cases where a decision cannot be made through consensus, voting procedures may be used. The voting process requires a majority vote from the steering committee members. The project also has a code of conduct that outlines the behavior and expectations of all members of the PySAL community. Overall, the PySAL project has a clear and effective governance model in place that ensures community involvement and transparency in decision-making processes.
The PySAL project has several key roles that are essential for its governance and management. The roles include the following:
Maintainers
Contributors
Technical Steering Committee (TSC)
Code of Conduct Committee
PySAL ‘s decision-making process
The PySAL project follows a decision-making process that includes a combination of voting procedures and approval processes. The Technical Steering Committee (TSC) is the main decision-making body for the project, responsible for overseeing the technical direction, strategic planning, and goals of the project. For proposals related to major changes or new features, community members can submit a Request for Comment (RFC) on the project's GitHub repository. The RFC will be reviewed and discussed by the community, and if deemed necessary, revisions will be made to the proposal. Once the RFC has been discussed and revised, it will be put up for a final vote by the TSC. For code changes, contributors submit pull requests which are reviewed by Maintainers. If a pull request meets the project's standards and has been approved by a Maintainer, it is merged into the codebase. The project also has a Code of Conduct Committee responsible for handling any issues related to the project's code of conduct. If a member of the community has concerns or complaints, they can report them to the committee, who will investigate and take appropriate action as necessary.
Finding and Understanding the governance model
The governance model is easily accessible as it is hosted on the project’s github repository; and it is well structured and organized making it easy to navigate and understand the different roles, decision-making processes, and policies that guides the project.
Name: Khairat Ayinde
Project Assigned: Yellowbrick
Link to Yellowbrick Governance Model: https://www.scikit-yb.org/en/latest/governance/index.html
The Yellowbrick project is an open source Python library for machine learning and visual analysis and diagnostics. The library combines scikit-learn and matplotlib to produce visualizations for machine learning workflow. The Yellowbrick project is also referred to as 'scikit-yellobrick' or 'scikit-yb'. With thousands of users, collaborators, and affiliated organizations, the Yellowbrick project continues to expand significantly, necessitating a need for constant maintenance. The purpose of this project's governance is to provide a structure that clearly defines how Yellowbrick members will administer, organize, and maintain the project.
All Yellowbrick project contributors are users. Active contributors are defined in a very specific and time-limited manner as such, contributors must be individuals who represent themselves and not companies.
The different project roles are listed and briefly explained in the list below:
The advisors conduct at least three meetings a year to make decisions. The chair must confirm the availability of all advisors before scheduling these meetings and make sure to include as many advisors as possible, putting into consideration both remote and in-person advisors.
Before voting, members are allowed a minimum of five minutes to speak in favor of or against the proposal. After receiving a vote proposal from one of the advisors, the chair decides whether a vote may be held or seconded by another advisor to hold a vote on the issue.
Votes may take place in two ways; by secret ballot or counting of individual votes.If the majority of advisors vote 'yea', the proposal is passed; if they vote "nay," it is rejected.
The proposal can only be approved if it is agreed by the founders who have the final say in all decision making. Minutes should be prepared by the secretary and made public to the rest of the Yellowbrick community.
The governance model was easy to locate on their documentation page. Understanding the model however, took me a while as I am new to it. I was able to put up this contribution together through research, the documentation and the guidelines clearly stated out.
Name: Jamillah Bello
Project Assigned: GNU Radio
Project Governance Link
GNU Radio is a free and open-source software development toolkit that provides signal processing blocks to implement software-defined radios and signal processing systems. It is used in research, academia, industry, and hobbyist applications to explore and experiment with a wide range of wireless communication systems. GNU Radio is developed by a community of engineers, researchers, and enthusiasts who collaborate to create a flexible and powerful software platform that can be customized to suit various needs. It is licensed under the GNU General Public License (GPL) and runs on various platforms such as Linux, Windows, and macOS.
GNU Radio has a community-driven governance model with the goal of ensuring that all contributors have an equal say in the development and management of the project. The project is led by a Steering Committee that is composed of active contributors to the project who are elected by the community. The committee members work together to set project priorities, allocate resources, and make decisions about major changes to the software.
Decision-making in the project is typically done through a consensus-based process, where all stakeholders are encouraged to participate and contribute to discussions about the project's direction. When necessary, the Steering Committee may also use a voting procedure to make decisions, where each committee member has an equal vote.
The project has a Code of Conduct that outlines the expected behavior of all contributors and a set of bylaws that govern the operations of the project. These documents help to ensure that the project is run in a fair and transparent manner and that all contributors are treated with respect and valued for their contributions.
There are several project roles within the GNU Radio community, including:
The articles of association of GNU Radio Organization state that certain decisions can be made through online voting, including voting on new members, certain rules of procedures, and some financial transactions. The organization also allows online voting for decisions not covered in the articles of association. Different types of votes exist with varying procedures and methods for calculating results. The rules aim to ensure a fair and practical way for the organization to make decisions through online voting.
The GNU Radio Organization allows online voting for certain decisions and assigns voting administrators responsible for sending and receiving ballots and calculating and publishing results. Online voting is initiated by a voting proposal and followed by a discussion period before the voting period begins. The voting period lasts for two weeks, and only votes cast during this period are considered for results. The results are published to the membership mailing list, including the number of persons permitted to vote, the total number of votes, and the number of votes for each option. The voting proposal can be retracted by the member who initiated it within the discussion period.
There are three types of votes allowed in GNU Radio Organization, namely:
For new member votes, a discussion period of one week is followed by a voting period of one week, with options of "Yes", "No", or "Abstain". For electing groups of people, there is a candidacy period of two weeks followed by a two-week discussion period and options are voted on according to section 3.4. For voting about decisions, a discussion period is started by a voting proposal and at least two members must declare their support for the vote before the voting period begins. The responsible party sends the voting proposal and options are voted on according to section 3.4.
The voting system has two sections, 3.4.1 for multiple options and 3.4.2 for two options. If there are more than two options, a meeting procedure must be suggested to ensure all votes count and that voting for an item cannot count against it. If there are exactly two options, each active member can vote with "Yes", "No", or "Abstain". The decision is accepted if there are more "Yes" than "No" votes and the vote isn't invalid according to section 5.
Members of the GNU Radio Organization who are active at the time of the voting period have the right to vote, and online votes are anonymous. The result of a voting only becomes effective if more than 20% of active members vote and if the number of total votes is greater than or equal to 50% of active members. Voting results, except for rejected votes about new members, are published on the GNU Radio website, and the board may modify voting procedures upon request with good reason.
Overall, it was relatively easy to find and understand the governance model of GNU Radio, as the project's website provides clear and concise information about its structure and decision-making processes. The community-driven approach to governance has helped to create an inclusive and collaborative environment that encourages participation and innovation in the development of software-defined radio systems.
Name: Ameerah Kabir (she/her)
Project: OpenJS Foundation (https://openjsf.org/)
Link to The Open JS Foundation governance model: https://openjsf.org/about/governance/
The governance model of the OpenJS Foundation is overseen by the Board of Directors. The Board is responsible for setting high-level technical policy through its mission and vision statements, bylaws, and outlining the Foundation's initiatives, technical vision, and direction. The Board also appoints the Executive Director (ED) to run the organization's day-to-day operations, who is tasked with implementing the strategic initiatives set out by the Board, hiring staff and contractors within the current budget, and partnering with other organizations to achieve the Foundation's goals. The ED reports to the Chairperson of the Board, with additional oversight and input from the full Board.
Each project within the OpenJS Foundation has its own governance structure, tailored to the needs of its respective community. The Foundation provides high-level requirements to ensure each project operates sustainably and equitably. Project maintainers have the flexibility to manage day-to-day operations as they see fit.
There are three major project roles within the OpenJS Foundation:
Maintainer,
Contributor,
End User.
There are various committees which make up the executive council members in charge of various operations, such as the Officers Committee, Governance Committee, Finance Committee, and Program Committee.
The OpenJS Foundation's decision-making process involves voting by eligible community members who are considered active in the community. To be eligible to vote, individuals must have completed an Instructor or Trainer certification within the past two years and have taught at least one OpenJS Foundation workshop, or have participated in a committee as a mentor or maintainer in the past year. The Executive Director is exempted from voting. A majority of votes by the Board of Directors is required to approve an appointment or removal of any party. The OpenJS Foundation strives for transparency in its activities and decision-making processes.
How easy or difficult was it to find and understand the governance model?
For my first time it was pretty easy, a section in the about had all the information about the governance model, I got a little confused by it was from my own end 😂, overall locating the governance model was easy.
Name: Esther Jolomi Adeyinka
Project Name: FluxML
Link FluxML Governance Model: https://fluxml.ai/governance/#advisory_committee__2
My Contribution: FluxML Governance.docx
how easy or difficult it was to find and understand the FluxML governance model:
I have never contributed to an open source before now. However, the term "governance model" is not new so finding and understanding it was not so difficult for me. Nevertheless, this project gave me a lot of insight into the roles and significance of the governance model in any business. I'm glad I signed up because it helped me improve my research and analytics skills and broadened my knowledge of the subject.
cc @arliss-NF
Name: Qudirah Alimi
Project Assigned: HoloViz
Community Page: https://holoviz.org/community.html
Contribution Page: https://holoviz.org/contributing.html
Main Page: https://holoviz.org/
GitHub Page: https://github.com/holoviz/holoviz/issues
The HoloViz project (formally known as PyViz) is managed using a shared governance model, which means that the project is open to contributions from anyone, regardless of background or experience. The governance model for HoloViz is based on transparency, inclusivity, and shared responsibility, with all members of the community having an equal say in the direction of the project. Contributions are evaluated based on their technical merit and alignment with the project's goals. Decisions are made through consensus, with all members of the community having an equal say in the direction of the project. HoloViz’s tools include Panel, HvPlot, HoloViews, GeoViews, DataShader, and more.
The contributing page outlines the steps involved in contributing to HoloViz, including how to set up a development environment, how to submit a contribution, and how to get involved in the community. The governance model for HoloViz is based on transparency, inclusivity, and shared responsibility, with all members of the community having an equal say in the direction of the project. Contribution ranges from as low as making a simple edit in documentation, writing about the project in blog posts, or starting a discussion to forking the repository and writing codes. The benefits go as far as even landing a job. A contributor is encouraged to open new issues and link PRs for contributions unless it is something as easy as a little documentation.
The HoloViz organization consists of two teams. The team that is in charge of contents and those in charge of attending to issues opened on the HoloViz project. They are referred to as HoloViz dev and Triaging team respectively. The data storage buckets are managed by Jean-Luc Steven(@jlstevens) and Philipp Rudiger (@philippjfr) and are both accessible on their GitHub pages using those handles. Phillip is also in charge of the HoloViz Discourse forum. Communication can be done via issues and PRs on GitHub, through PyViz Gitters, or through a meeting held openly and welcome to every contributor. A link to the google calendar can be easily found on the community page.
Finding and understanding the Governance Model was easy for me. It just took reading and digging a little deep. It was easy to find and understand the governance model.
Name : Kako Nodia
Project Assigned : dolphicom
dolphicom is a GitLab-based project that provides software and hardware solutions for digital signal processing and communication systems. They engage with the community through access to their source code repositories, documentation, issue trackers, and forums. dolphicom offers FPGA-based development boards, software-defined radio platforms, and intellectual property cores for DSP and communication applications. To contribute to the project, interested individuals can explore the dolphicom GitLab repository, join the forum to ask questions and participate in discussions, and submit bug reports, feature requests, code changes, and documentation. dolphicom has a governance model based on a core team of maintainers who are responsible for managing the development process and ensuring the quality of the codebase while emphasizing transparency and inclusiveness in their decision-making processes.
The Project Governance Model Link
The Governance Model
The governance model for the dolphicom project is described in a document on their GitLab repository (mentionned above). The model is based on a core team of maintainers who are responsible for managing the development process and ensuring the quality of the codebase. The maintainers are selected based on their contributions to the project and their ability to work collaboratively with others. In addition to the maintainers, the project also has a larger community of contributors who can submit bug reports, feature requests, and code changes for review. The governance model emphasizes transparency, with all decisions and discussions taking place in public forums where anyone can participate. Overall, the model aims to balance the need for centralized decision-making with the desire for an open and inclusive development process.
The Project Roles
The governance model defines three key roles in the project
Decision-making Process
The decision-making process for the dolphicom project is based on collaboration and consensus building. Decisions are made in public forums where anyone can participate. The maintainers have the final say on decisions related to the project, but they aim to work collaboratively with other contributors and consider feedback from the community.
Voting Procedures
Voting procedures are not specifically outlined in the governance model, but the project aims to reach decisions through consensus rather than voting. Approval processes for code changes and other contributions are outlined in the project's contribution guidelines.
How easy or difficult it was to find and understand the governance model
The governance model for the dolphicom project was fairly easy to find and understand. The project has a governance document that provides a clear overview of the model and the roles of different contributors. Additionally, the project's contribution guidelines outline the approval process for code changes and other contributions.
Name: Bazgha Razi
Project Name: BentoML
Project Governance Model: BentoML Governance Model
BentoML takes a meritocratic, consensus-based approach to its governance structure. Anyone with an interest in the project can join the community, contribute to the project and participate in the decision making process.
Project Roles:
Decision Making Process:
How easy or difficult it was to find and understand the governance model?
It was easy to find the governance model because it's added inside the repository, so it didn't take time to find it.
As a beginner, understanding the governance model was also quite easy for me because it's well-written.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
