diff options
author | Nathaniel J. Smith <njs@pobox.com> | 2015-09-23 20:40:03 -0700 |
---|---|---|
committer | Nathaniel J. Smith <njs@pobox.com> | 2015-09-23 20:40:03 -0700 |
commit | 763f49df46678aadd1cfebe5d8497ad0b089fe12 (patch) | |
tree | 9b39030d93df2cea31e414afae23ec9b13ebf3fd | |
parent | 772c80b1ce1db7e30497fcf555ac9af56b0d7fce (diff) | |
download | numpy-763f49df46678aadd1cfebe5d8497ad0b089fe12.tar.gz |
DEV: Draft governance document + list of people and positions
This is definitely *not* the final version -- it's the version
originally posted to the mailing list, reformatted as ReST. I'll make
further changes on top of this as further commits, in order to preserve
the historical record.
-rw-r--r-- | doc/source/dev/governance/governance.rst | 405 | ||||
-rw-r--r-- | doc/source/dev/governance/index.rst | 9 | ||||
-rw-r--r-- | doc/source/dev/governance/people.rst | 49 | ||||
-rw-r--r-- | doc/source/dev/index.rst | 1 |
4 files changed, 464 insertions, 0 deletions
diff --git a/doc/source/dev/governance/governance.rst b/doc/source/dev/governance/governance.rst new file mode 100644 index 000000000..8f06129b5 --- /dev/null +++ b/doc/source/dev/governance/governance.rst @@ -0,0 +1,405 @@ +================================================================ + NumPy project governance and decision-making +================================================================ + +[DRAFT, not yet accepted] + +The purpose of this document is to formalize the governance process +used by the NumPy project in both ordinary and extraordinary +situations, and to clarify how decisions are made and how the various +elements of our community interact, including the relationship between +open source collaborative development and work that may be funded by +for-profit or non-profit entities. + +Summary +======= + +NumPy is a community-owned and community-run project. To the maximum +extent possible, decisions about project direction are made by community +consensus (but note that "consensus" here has a somewhat technical +meaning that might not match everyone's expectations -- see below). Some +members of the community additionally contribute by serving on the NumPy +steering council, where they are responsible for facilitating the +establishment of community consensus, for stewarding project resources, +and -- in extreme cases -- for making project decisions if the normal +community-based process breaks down. + +The Project +=========== + +The NumPy Project (The Project) is an open source software project +affiliated with the 501(c)3 NumFocus Foundation. The goal of The Project +is to develop open source software for array-based computing in Python, +and in particular the ``numpy`` package, along with related software +such as ``f2py`` and the NumPy Sphinx extensions. The Software developed +by The Project is released under the BSD (or similar) open source +license, developed openly and hosted on public GitHub repositories under +the ``numpy`` GitHub organization. + +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 the Project. 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, mailing lists, and other +channels. The foundation of Project participation is openness and +transparency. + +Here is a list of the current Contributors to the main NumPy repository: + +https://github.com/numpy/numpy/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. + +The Project is formally affiliated with the 501(c)3 NumFOCUS Foundation +(http://numfocus.org), which serves as its fiscal sponsor, may hold +project trademarks and other intellectual property, helps manage project +donations and acts as a parent legal entity. NumFOCUS is the only legal +entity that has a formal relationship with the project (see +Institutional Partners section below). + +Governance +========== + +This section describes the governance and leadership model of The +Project. + +The foundations of Project governance are: + +- Openness & Transparency +- Active Contribution +- Institutional Neutrality + +Consensus-based decision making by the community +------------------------------------------------ + +Normally, all project decisions will be made by consensus of all +interested Contributors. The primary goal of this approach is to ensure +that the people who are most affected by and involved in any given +change can contribute their knowledge in the confidence that their +voices will be heard, because thoughtful review from a broad community +is the best mechanism we know of for creating high-quality software. + +The mechanism we use to accomplish this goal may be unfamiliar for those +who are not experienced with the cultural norms around free/open-source +software development. We provide a summary here, and highly recommend +that all Contributors additionally read `Chapter 4: Social and Political +Infrastructure <http://producingoss.com/en/producingoss.html#social-infrastructure>`__ +of Karl Fogel's classic *Producing Open Source Software*, and in +particular the section on `Consensus-based +Democracy <http://producingoss.com/en/producingoss.html#consensus-democracy>`__, +for a more detailed discussion. + +In this context, consensus does *not* require: + +- that we wait to solicit everybody's opinion on every change, +- that we ever hold a vote on anything, +- or that everybody is happy or agrees with every decision. + +For us, what consensus means is that we entrust *everyone* with the +right to veto any change if they feel it necessary. While this may sound +like a recipe for obstruction and pain, this is not what happens. +Instead, we find that most people take this responsibility seriously, +and only invoke their veto when they judge that a serious problem is +being ignored, and that their veto is necessary to protect the project. +And in practice, it turns out that such vetoes are almost never formally +invoked, because their mere possibility ensures that Contributors are +motivated from the start to find some solution that everyone can live +with -- thus accomplishing our goal of ensuring that all interested +perspectives are taken into account. + +How do we know when consensus has been achieved? In principle, this is +rather difficult, since consensus is defined by the absence of vetos, +which requires us to somehow prove a negative. In practice, we use a +combination of our best judgement (e.g., a simple and uncontroversial +bug fix posted on GitHub and reviewed by a core developer is probably +fine) and best efforts (e.g., all substantive API changes must be posted +to the mailing list in order to give the broader community a chance to +catch any problems and suggest improvements; we assume that anyone who +cares enough about NumPy to invoke their veto right should be on the +mailing list). If no-one bothers to comment on the mailing list after a +few days, then it's probably fine. And worst case, if a change is more +controversial than expected, or a crucial critique is delayed because +someone was on vacation, then it's no big deal: we apologize for +misjudging the situation, `back up, and sort things +out <http://producingoss.com/en/producingoss.html#version-control-relaxation>`__. + +If one does need to invoke a formal veto, then it should consist of: + +- an unambiguous statement that a veto is being invoked, +- an explanation of why it is being invoked, and +- a description of what conditions (if any) would convince the vetoer + to withdraw their veto. + +If all proposals for resolving some issue are vetoed, then the status +quo wins by default. + +In the worst case, if a Contributor is genuinely misusing their veto in +an obstructive fashion to the detriment of the project, then they can be +ejected from the project by consensus of the Steering Council -- see +below. + +Steering Council +---------------- + +The Project will have a Steering Council that consists of Project +Contributors who have produced contributions that are substantial in +quality and quantity, and sustained over at least one year. The overall +role of the Council is to ensure, with input from the Community, the +long-term well-being of the project, both technically and as a +community. + +During the everyday project activities, council members participate in +all discussions, code review and other project activities as peers with +all other Contributors and the Community. In these everyday activities, +Council Members do not have any special power or privilege through their +membership on the Council. However, it is expected that because of the +quality and quantity of their contributions and their expert knowledge +of the Project Software and Services that Council Members will provide +useful guidance, both technical and in terms of project direction, to +potentially less experienced contributors. + +The Steering Council and its Members play a special role in certain +situations. In particular, the Council may, if necessary: + +- Make decisions about the overall scope, vision and direction of the + project. +- Make decisions about strategic collaborations with other + organizations or individuals. +- Make decisions about specific technical issues, features, bugs and + pull requests. They are the primary mechanism of guiding the code + review process and merging pull requests. +- Make decisions about the Services that are run by The Project and + manage those Services for the benefit of the Project and Community. +- Update policy documents such as this one. +- Make decisions when regular community discussion doesn’t produce + consensus on an issue in a reasonable time frame. + +However, the Council's primary responsibility is to facilitate the +ordinary community-based decision making procedure described above. If +we ever have to step in and formally override the community for the +health of the Project, then we will do so, but we will consider reaching +this point to indicate a failure in our leadership. + +Council decision making +~~~~~~~~~~~~~~~~~~~~~~~ + +If it becomes necessary for the Steering Council to produce a formal +decision, then they will use a form of the `Apache Foundation voting +process <https://www.apache.org/foundation/voting.html>`__. This is a +formalized version of consensus, in which +1 votes indicate agreement, +-1 votes are vetoes (and must be accompanied with a rationale, as +above), and one can also vote fractionally (e.g. -0.5, +0.5) if one +wishes to express an opinion without registering a full veto. These +numeric votes are also 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, and if this does occur then the vote should be held +open for long enough to give all interested Council Members a chance to +respond -- at least one week. + +In practice, we anticipate that for most Steering Council decisions +(e.g., voting in new members) a more informal process will suffice. + +Council membership +~~~~~~~~~~~~~~~~~~ + +To become eligible to join the Steering Council, an individual must be a +Project Contributor who has produced contributions that are substantial +in quality and quantity, and sustained over at least one year. Potential +Council Members are nominated by existing Council members and voted upon +by the existing Council after asking if the potential Member is +interested and willing to serve in that capacity. The Council will be +initially formed from the set of existing Core Developers who, as of +late 2015, have been significantly active over the last year. + +When considering potential Members, the Council will look at candidates +with a comprehensive view of their contributions. This will include but +is not limited to code, code review, infrastructure work, mailing list +and chat participation, community help/building, education and outreach, +design work, etc. We are deliberately not setting arbitrary quantitative +metrics (like “100 commits in this repo”) to avoid encouraging behavior +that plays to the metrics rather than the project’s overall well-being. +We want to encourage a diverse array of backgrounds, viewpoints and +talents in our team, which is why we explicitly do not define code as +the sole metric on which council membership will be evaluated. + +If a Council member becomes inactive in the project for a period of one +year, they will be considered for removal from the Council. Before +removal, inactive Member will be approached to see if they plan on +returning to active participation. If not they will be removed +immediately upon a Council vote. If they plan on returning to active +participation soon, they will be given a grace period of one year. If +they don’t return to active participation within that time period they +will be removed by vote of the Council without further grace period. All +former Council members can be considered for membership again at any +time in the future, like any other Project Contributor. Retired Council +members will be listed on the project website, acknowledging the period +during which they were active in the Council. + +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. This requires the +consensus of the remaining Members. + +[We also have to decide on the initial membership for the Council. While +the above text makes pains to distinguish between "committer" and +"Council Member", in the past we've pretty much treated them as the +same. So to keep things simple and deterministic, I propose that we seed +the Council with everyone who has reviewed/merged a pull request since +Jan 1, 2014, and move those who haven't used their commit bit in >1.5 +years to the emeritus list. Based on the output of + +git log --grep="^Merge pull request" --since 2014-01-01 \| grep Author: +\| sort -u + +I believe this would give us an initial Steering Council of: Sebastian +Berg, Jaime Fernández del Río, Ralf Gommers, Alex Griffing, Charles +Harris, Nathaniel Smith, Julian Taylor, and Pauli Virtanen (assuming +everyone on that list is interested/willing to serve).] + +Conflict of interest +~~~~~~~~~~~~~~~~~~~~ + +It is expected that the Council Members will be employed at a wide range +of companies, universities and non-profit organizations. Because of +this, it is possible that Members will have conflict of interests. Such +conflict of interests include, but are not limited to: + +- Financial interests, such as investments, employment or contracting + work, outside of The Project that may influence their work on The + Project. +- Access to proprietary information of their employer that could + potentially leak into their work with the Project. + +All members of the Council shall disclose to the rest of the Council any +conflict of interest they may have. Members with a conflict of interest +in a particular issue may participate in Council discussions on that +issue, but must recuse themselves from voting on the issue. + +Private communications of the Council +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Unless specifically required, all Council discussions and activities +will be public and done in collaboration and discussion with the Project +Contributors and Community. The Council will have a private mailing list +that will be used sparingly and only when a specific matter requires +privacy. When private communications and decisions are needed, the +Council 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. + +Subcommittees +~~~~~~~~~~~~~ + +The Council can create subcommittees that provide leadership and +guidance for specific aspects of the project. Like the Council as a +whole, subcommittees should conduct their business in an open and public +manner unless privacy is specifically called for. Private subcommittee +communications should happen on the main private mailing list of the +Council unless specifically called for. + +NumFOCUS Subcommittee +~~~~~~~~~~~~~~~~~~~~~ + +The Council will maintain one narrowly focused subcommittee to manage +its interactions with NumFOCUS. + +- The NumFOCUS Subcommittee is comprised of 5 persons who manage + project funding that comes through NumFOCUS. It is expected that + these funds will be spent in a manner that is consistent with the + non-profit mission of NumFOCUS and the direction of the Project as + determined by the full Council. +- This Subcommittee shall NOT make decisions about the direction, scope + or technical direction of the Project. +- This Subcommittee will have 5 members, 4 of whom will be current + Council Members and 1 of whom will be external to the Steering + Council. No more than 2 Subcommitee Members can report to one person + through employment or contracting work (including the reportee, i.e. + the reportee + 1 is the max). This avoids effective majorities + resting on one person. + +[Initially, the NumFOCUS subcommittee will consist of: Chuck Harris, +Ralf Gommers, Nathaniel Smith, and ???? as internal members, and Thomas +Caswell as external member.] + +Institutional Partners and Funding +================================== + +The Steering Council are the primary leadership for the project. No +outside institution, individual or legal entity has the ability to own, +control, usurp or influence the project other than by participating in +the Project as Contributors and Council Members. However, because +institutions can be an important funding mechanism for the project, it +is important to formally acknowledge institutional participation in the +project. These are Institutional Partners. + +An Institutional Contributor is any individual Project Contributor who +contributes to the project as part of their official duties at an +Institutional Partner. Likewise, an Institutional Council Member is any +Project Steering Council Member who contributes to the project as part +of their official duties at an Institutional Partner. + +With these definitions, an Institutional Partner is any recognized legal +entity in the United States or elsewhere that employs at least 1 +Institutional Contributor of Institutional Council Member. Institutional +Partners can be for-profit or non-profit entities. + +Institutions become eligible to become an Institutional Partner by +employing individuals who actively contribute to The Project as part of +their official duties. To state this another way, the only way for a +Partner to influence the project is by actively contributing to the open +development of the project, in equal terms to any other member of the +community of Contributors and Council Members. Merely using Project +Software in institutional context does not allow an entity to become an +Institutional Partner. Financial gifts do not enable an entity to become +an Institutional Partner. Once an institution becomes eligible for +Institutional Partnership, the Steering Council must nominate and +approve the Partnership. + +If an existing Institutional Partner no longer has a contributing +employee, they will be given a 1 year grace period for remaining +employees to begin contributing. + +An Institutional Partner is free to pursue funding for their work on The +Project through any legal means. This could involve a non-profit +organization raising money from private foundations and donors or a +for-profit company building proprietary products and services that +leverage Project Software and Services. Funding acquired by +Institutional Partners to work on The Project is called Institutional +Funding. However, no funding obtained by an Institutional Partner can +override the Steering Council. If a Partner has funding to do NumPy work +and the Council decides to not pursue that work as a project, the +Partner is free to pursue it on their own. However in this situation, +that part of the Partner’s work will not be under the NumPy umbrella and +cannot use the Project trademarks in a way that suggests a formal +relationship. + +Institutional Partner benefits are: + +- Acknowledgement on the NumPy websites, in talks and T-shirts. +- Ability to acknowledge their own funding sources on the NumPy + websites, in talks and T-shirts. +- Ability to influence the project through the participation of their + Council Member. +- Council Members invited to NumPy Developer Meetings. + +Existing Institutional Partners: + +- UC Berkeley (Nathaniel Smith) + +Document history +================ + +[TODO: add a link to the git log for this file] + +Acknowledgements +================ + +Substantial portions of this document were [STRIKEOUT:inspired] stolen +wholesale from the Jupyter/IPython project's governance document, `IPEP +29 <https://github.com/ipython/ipython/wiki/IPEP-29:-Project-Governance>`__. diff --git a/doc/source/dev/governance/index.rst b/doc/source/dev/governance/index.rst new file mode 100644 index 000000000..9a611a2fe --- /dev/null +++ b/doc/source/dev/governance/index.rst @@ -0,0 +1,9 @@ +##################### +Contributing to Numpy +##################### + +.. toctree:: + :maxdepth: 3 + + governance + people diff --git a/doc/source/dev/governance/people.rst b/doc/source/dev/governance/people.rst new file mode 100644 index 000000000..6c6ccf305 --- /dev/null +++ b/doc/source/dev/governance/people.rst @@ -0,0 +1,49 @@ +Current steering council and institutional partners +=================================================== + +[DRAFT, not yet accepted] + +Steering council +---------------- + +* Sebastian Berg + +* Jaime Fernández del Río + +* Ralf Gommers + +* Alex Griffing + +* Charles Harris + +* Nathaniel Smith + +* Julian Taylor + +* Pauli Virtanen + + +Emeritus members +---------------- + +* Travis Oliphant - Project Founder / Emeritus Leader (served: 2001(??)-2012) + + +NumFOCUS Subcommittee +--------------------- + +* Chuck Harris + +* Ralf Gommers + +* Jaime Fernández del Río + +* Nathaniel Smith + +* External member: Thomas Caswell + + +Institutional Partners +---------------------- + +* UC Berkeley (Nathaniel Smith) diff --git a/doc/source/dev/index.rst b/doc/source/dev/index.rst index b0d0ec483..cb71a3e5c 100644 --- a/doc/source/dev/index.rst +++ b/doc/source/dev/index.rst @@ -7,5 +7,6 @@ Contributing to Numpy gitwash/index development_environment + governance/index For core developers: see :ref:`development-workflow`. |