-
Notifications
You must be signed in to change notification settings - Fork 51
Governance
The BigBang project is based on the recognition that the design of our technical systems are the result of many human choices. As a reflective microcosm of sociotechnical organization in general, BigBang encourages activate participation in its governance. This document details the bylaws of the BigBang community.
As of October 21, 2016, BigBang is governed by its contributors as a consensus-based democracy. For a definitive description of how this process should work in an open source project, please read the relevant section of "Chapter 4. Social and Political Infrastructure", in Producing Open Source Software, by Karl Fogel.
Open source projects often take their governance processes from projects that are technically "upstream" of them. As precedent for its own governance mechanisms, BigBang looks to the bylaws of scientific computing (especially, Python) projects such as NumPy and Jupyter.
We look to the Apache Voting Process for our model of voting, when necessary.
As these projects are much more mature, have larger contributing communities, and have more complex relationships with external organizations, we also look to the smaller project, GeoNode, for inspiration on structuring a light-weight governance structure suitable for a smaller team.
The BigBang project (The Project) is an open source software project. The goal of The Project is to develop open source software for research and education. The Software developed by The Project is released under the Affero-GPL license, developed openly and hosted on public GitHub repositories.
The Project is developed by a team of distributed developers, called Contributors. Contributors are individuals who have contributed code, documentation, designs or other work to one or more Project repositories. Anyone can be a Contributor. Contributors can be affiliated with any legal entity or none. Contributors participate in the project by submitting, reviewing and discussing GitHub Pull Requests and Issues and participating in open and public Project discussions on GitHub and mailing lists. The foundation of Project participation is openness and transparency.
Here is a list of the current Contributors to the main BigBang repository, https://github.com/datactive/bigbang/:
https://github.com/datactive/bigbang/graphs/contributors
The Project Community consists of all Contributors and Users of the Project. Contributors work on behalf of and are responsible to the larger Project Community and we strive to keep the barrier between Contributors and Users as low as possible.
All members of the Project Community are expected to abide by and maintain the code of conduct in order to make participation in our project and our community a harassment-free experience for everyone.
This section describes the governance and leadership model of The Project.
The foundations of Project governance are:
- Openness & Transparency
- Active Contribution
- Institutional Neutrality
For the first two years of its development (2014-2016), BigBang leadership was provided informally by Sebastian Benthall. As the project has expanded in scope and its community grown, we see a need to transition into a more community-based model.
Governance will now be determined by consensus of the Core Developers. Core Developers are those whose active and consistent contributions are 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.
To become a Core Developer, one must be voted in by consensus of the current active Core Developers.
This is a list of the current Core Developers, which must be updated by the Project Steering Committee after the induction of each new Core Developer:
- Sebastian Benthall
- Aryan Falahatpisheh
- Nick Doty
- Niels ten Oever
- Christoph Becker
Core Developers must:
- Make useful contributions to the project in the form of commits at least once in a 9-month period, else they become Inactive. Inactive Core Developers have the same project privileges as Contributors.
- Review code contributions, which may come from other Core Developers and Contributors. A review should result in either (a) instructions on how to bring the code to a more acceptable condition or (b) merging the changes in and notifying the submitter that this has been done.
Core Developers also have the option to “self-review” and commit changes directly. It is at the discretion of individual Core Developers when this is appropriate, but it should be rare - we encourage committers to only use this option when they deem a change extremely minor.
If a committer thinks a proposed change to the software is particularly destabilizing or far-reaching, that committer can upgrade the ticket for that change to a BigBang Improvement Proposal (BBIP). BBIP tickets are an opportunity for committers and users alike to provide feedback about the design of a proposed feature or architectural change. The proposal should be iteratively edited in response to community feedback.
To upgrade an issue to a BBIP, an active committer should give the ticket the ‘BBIP’ label in the issue tracker, and announce the issue on the developer mailing list.
If a ticket has a BBIP label, any corresponding changes can’t be committed unless the proposal has also received ‘Approved’ label. To be approved, it must pass community vote (see below).
When the BBIP is announced, other Core Developers should review and provide feedback in the issue comments. Feedback should take the form of:
- +1 (with optional comment)
- -1, with mandatory rationale and suggestion for a better approach. The suggestion may be omitted if the objection doesn’t have a straightforward solution - we don’t want to withhold feedback just because problems with a proposal are hard to solve.
After receiving feedback, the proposal’s author should discuss the feedback on the list if necessary and adjust the proposal in response.
A proposal can be Approved when there are 3 +1 responses (including the author’s implicit approval) and no -1 responses from committers; and no feedback is offered in 3 days. If a proposal fails to receive multiple +1 responses within 5 days of the request for feedback it is rejected and the issue should be closed (but the author is free to draft similar proposals in the future.) Any committer may reverse or withdraw votes on a proposal until the proposal is closed.
If a Contributor would like to submit a BBIP, they are welcome to write it as a ticket but should find an active Core Developer willing to promote it to BBIP status.
In the event that a revision to these bylaws becomes necessary, authority for that decision lies with the currently presiding Project Steering Committee (PSC). The PSC at any time is made up of the top 5 Core Developers over the past 365 days, by number of commits. If there are fewer than five active Core Developers available to serve on the Project Steering Committee, the Contributors with the highest number of commits in the past 365 days may fill the remaining positions. Changes to these bylaws should be made by consensus if at all possible.
For the purpose of considering place in the Steering committee, "number of commits" here means the sum of commits to the master and gh-pages branches of the https://github.com/datactive/bigbang/ repository.
Unless specifically required, all Governance related discussions and activities will be public and done in collaboration and discussion with the Project Contributors and Community. Private communications will be used sparingly and only when a specific matter requires privacy. When private communications and decisions are needed, the Core Developers will do its best to summarize those to the Community after eliding personal/private/sensitive information that should not be posted to the public internet.