PEP 8002: Add description of the Astropy project

This commit is contained in:
Antoine Pitrou 2018-09-17 23:14:26 +02:00
parent 1fda80f6ad
commit 6a5694c17b
1 changed files with 128 additions and 3 deletions

View File

@ -456,7 +456,7 @@ experienced contributors.
For controversial issues, the contributor community works together to refine For controversial issues, the contributor community works together to refine
potential solutions, iterate as necessary, and build consensus by sharing potential solutions, iterate as necessary, and build consensus by sharing
information and views constructively and openly. The Steering Council may information and views constructively and openly. The Steering Council may
make decisions when regular community discussion doesnt produce consensus make decisions when regular community discussion doesn't produce consensus
on an issue in a reasonable time frame. on an issue in a reasonable time frame.
Voting Voting
@ -658,8 +658,130 @@ a well-defined routine of accepting external contributions. Community
engagement rose significantly after the project got moved. engagement rose significantly after the project got moved.
Microsoft Astropy
========= =======
Key people and their functions
------------------------------
The Astropy Project team's responsibilites are spread over many different
roles [#astropy-team]_, though frequently a person will have several roles.
The main body overseeing the Astropy Project is the Astropy
*Coordination Committee* (CoCo) . Its key roles are dealing with any
financial issues, approving new packages wanting to join the Astropy
Project, approving or rejecting *Astropy Proposals for Enhancement*
(APEs) [#astropy-apes]_, and generally anything that's "leadership"-oriented
or time-sensitive. As of this writing, the committee has four members,
and might grow or shrink as the demands on the committee change.
Regular decision process
------------------------
Code-level decisions
~~~~~~~~~~~~~~~~~~~~
The Astropy Project is organized as *sub-packages*. Each sub-package has an
official *maintainer* as well as one or more *deputies*, who are responsible
for ensuring code is reviewed and generally architecting the subpackage.
Code-level decisions are therefore made in GitHub issues or pull requests
(PRs), usually on the basis of consensus, moderated by the maintainer
and deputies of that sub-package.
When there is specific disagreement, majority vote of those who are involved
in the discussion (e.g. PR) determines the winner, with the CoCo called on
to break ties or mediate disagreements.
Non-code decisions
~~~~~~~~~~~~~~~~~~
Non-code decisions (like sprint scheduling, bugfix release timing, etc)
are usually announced on the *astropy-dev mailing list* [#astropy-dev]_ with
a vote-by-message format, or a "if there are no objections"-style message
for highly uncontroversial items. In general, on astropy-dev the expectation
is a concrete proposal which other members are welcome to comment or vote on.
Voting
~~~~~~
Voting usually involves either using the +1/-1 format on GitHub or the
astropy-dev mailing list. There, any interested person can vote regardless
of their official role in the project, or lack thereof. Furthermore, there
is no veto mechanism for the CoCo to override decisions of the majority.
Controversial decision process
------------------------------
Simpler controversial decisions are generally discussed on the astropy-dev
mailing list [#astropy-dev]_, and after a reasonable time either there is
a clear consensus/compromise (this happens most of the time), or the CoCo
makes a decision to avoid stalling.
More complicated decisions follow the APE process, which is modeled after the
PEP process. Here, the CoCo makes the final decision after a discussion
period, open to everyone, has passed. Generally the CoCo would follow the
consensus or majority will.
Ethical issues
~~~~~~~~~~~~~~
The Project has an *Ombudsperson* who ensures there is an alternate contact
for sensitive issues, such as Code of Conduct violations, independent
from the Coordination Committee. In practice, the CoCo, the Community
engagement coordinators and the Ombudsperson would work together privately
to try and communicate with the violator to address the situation.
Planning a new release
----------------------
The major release timing is on a fixed schedule (every 6 months); whatever
is in at that time goes in.
Changes in the process over time
--------------------------------
The CoCo and the "Open Development" ethos came from the inception of the
Project after a series of votes by interested Python-oriented astronomers
and allied software engineers. The core results of that initial discussion
were embodied in the *Vision for Astropy* document [#astropy-vision]_.
The existence of the formal roles and most of the rest of the above
came as evolutionary steps as the community grew larger, each following
either the APE process, or the regular process of a proposal being brought
up for discussion and vote in astropy-dev [#astropy-dev]_. In general all
evolved as sort of ratification of already-existing practices, only after
they were first tested in the wild.
Self-appreciation
-----------------
The fact that anyone who has the time can step in and suggest something
(usually via PR) or vote on their preference, leads to a sense that
"we are all in this together", leading to better-coordinated effort.
Additionally, the function of the CoCo as mostly a tie-breaking body means
that there's no sense of a dictator who enforces their will, while still
giving clear points of contact for external organizations that are
leery of fully-democratic governance models.
References
----------
.. [#astropy-team] Astropy roles and responsibilites
https://www.astropy.org/team.html
.. [#astropy-apes] Astropy Proposals for Enhancement
https://github.com/astropy/astropy-APEs
.. [#astropy-dev] Astropy-dev mailing list
https://groups.google.com/forum/#!forum/astropy-dev
.. [#astropy-vision] Vision for a Common Astronomy Python Package
https://docs.astropy.org/en/stable/development/vision.html
Bonus: Microsoft
================
Despite the selection process for "relevant projects" described above, Despite the selection process for "relevant projects" described above,
it is worthwhile considering how companies that are held financially it is worthwhile considering how companies that are held financially
@ -823,6 +945,9 @@ project's governance is set up.
The TypeScript and Swift sections were created after conversations with The TypeScript and Swift sections were created after conversations with
Joe Pamer and Vlad Matveev. Thanks! Joe Pamer and Vlad Matveev. Thanks!
Answers about the Astropy project were kindly contributed, in significant
detail, by Erik Tollerud and reviewed by other members of the project.
Annex 1: Template questions Annex 1: Template questions
=========================== ===========================