PEP 8002: Add description of the Astropy project
This commit is contained in:
Antoine Pitrou
parent
1fda80f6ad
commit
6a5694c17b
131
pep-8002.rst
131
pep-8002.rst
|
|
@ -456,7 +456,7 @@ experienced contributors.
|
|||
For controversial issues, the contributor community works together to refine
|
||||
potential solutions, iterate as necessary, and build consensus by sharing
|
||||
information and views constructively and openly. The Steering Council may
|
||||
make decisions when regular community discussion doesn’t produce consensus
|
||||
make decisions when regular community discussion doesn't produce consensus
|
||||
on an issue in a reasonable time frame.
|
||||
|
||||
Voting
|
||||
|
|
@ -658,8 +658,130 @@ a well-defined routine of accepting external contributions. Community
|
|||
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,
|
||||
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
|
||||
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
|
||||
===========================
|
||||
|
|
|
|||
Loading…
Reference in New Issue