1114 lines
70 KiB
HTML
1114 lines
70 KiB
HTML
|
||
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<meta charset="utf-8">
|
||
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
||
<meta name="color-scheme" content="light dark">
|
||
<title>PEP 8002 – Open Source Governance Survey | peps.python.org</title>
|
||
<link rel="shortcut icon" href="../_static/py.png">
|
||
<link rel="canonical" href="https://peps.python.org/pep-8002/">
|
||
<link rel="stylesheet" href="../_static/style.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/mq.css" type="text/css">
|
||
<link rel="stylesheet" href="../_static/pygments.css" type="text/css" media="(prefers-color-scheme: light)" id="pyg-light">
|
||
<link rel="stylesheet" href="../_static/pygments_dark.css" type="text/css" media="(prefers-color-scheme: dark)" id="pyg-dark">
|
||
<link rel="alternate" type="application/rss+xml" title="Latest PEPs" href="https://peps.python.org/peps.rss">
|
||
<meta property="og:title" content='PEP 8002 – Open Source Governance Survey | peps.python.org'>
|
||
<meta property="og:description" content="This PEP surveys existing and similar open source and free software projects for their governance models, providing summaries that will serve as useful references for Python’s own selection of a new governance model in the wake of Guido’s retirement.">
|
||
<meta property="og:type" content="website">
|
||
<meta property="og:url" content="https://peps.python.org/pep-8002/">
|
||
<meta property="og:site_name" content="Python Enhancement Proposals (PEPs)">
|
||
<meta property="og:image" content="https://peps.python.org/_static/og-image.png">
|
||
<meta property="og:image:alt" content="Python PEPs">
|
||
<meta property="og:image:width" content="200">
|
||
<meta property="og:image:height" content="200">
|
||
<meta name="description" content="This PEP surveys existing and similar open source and free software projects for their governance models, providing summaries that will serve as useful references for Python’s own selection of a new governance model in the wake of Guido’s retirement.">
|
||
<meta name="theme-color" content="#3776ab">
|
||
</head>
|
||
<body>
|
||
|
||
<svg xmlns="http://www.w3.org/2000/svg" style="display: none;">
|
||
<symbol id="svg-sun-half" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Following system colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="9"></circle>
|
||
<path d="M12 3v18m0-12l4.65-4.65M12 14.3l7.37-7.37M12 19.6l8.85-8.85"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-moon" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected dark colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<path stroke="none" d="M0 0h24v24H0z" fill="none"></path>
|
||
<path d="M12 3c.132 0 .263 0 .393 0a7.5 7.5 0 0 0 7.92 12.446a9 9 0 1 1 -8.313 -12.454z"></path>
|
||
</svg>
|
||
</symbol>
|
||
<symbol id="svg-sun" viewBox="0 0 24 24" pointer-events="all">
|
||
<title>Selected light colour scheme</title>
|
||
<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" fill="none"
|
||
stroke="currentColor" stroke-width="2" stroke-linecap="round" stroke-linejoin="round">
|
||
<circle cx="12" cy="12" r="5"></circle>
|
||
<line x1="12" y1="1" x2="12" y2="3"></line>
|
||
<line x1="12" y1="21" x2="12" y2="23"></line>
|
||
<line x1="4.22" y1="4.22" x2="5.64" y2="5.64"></line>
|
||
<line x1="18.36" y1="18.36" x2="19.78" y2="19.78"></line>
|
||
<line x1="1" y1="12" x2="3" y2="12"></line>
|
||
<line x1="21" y1="12" x2="23" y2="12"></line>
|
||
<line x1="4.22" y1="19.78" x2="5.64" y2="18.36"></line>
|
||
<line x1="18.36" y1="5.64" x2="19.78" y2="4.22"></line>
|
||
</svg>
|
||
</symbol>
|
||
</svg>
|
||
<script>
|
||
|
||
document.documentElement.dataset.colour_scheme = localStorage.getItem("colour_scheme") || "auto"
|
||
</script>
|
||
<section id="pep-page-section">
|
||
<header>
|
||
<h1>Python Enhancement Proposals</h1>
|
||
<ul class="breadcrumbs">
|
||
<li><a href="https://www.python.org/" title="The Python Programming Language">Python</a> » </li>
|
||
<li><a href="../pep-0000/">PEP Index</a> » </li>
|
||
<li>PEP 8002</li>
|
||
</ul>
|
||
<button id="colour-scheme-cycler" onClick="setColourScheme(nextColourScheme())">
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-auto"><use href="#svg-sun-half"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-dark"><use href="#svg-moon"></use></svg>
|
||
<svg aria-hidden="true" class="colour-scheme-icon-when-light"><use href="#svg-sun"></use></svg>
|
||
<span class="visually-hidden">Toggle light / dark / auto colour theme</span>
|
||
</button>
|
||
</header>
|
||
<article>
|
||
<section id="pep-content">
|
||
<h1 class="page-title">PEP 8002 – Open Source Governance Survey</h1>
|
||
<dl class="rfc2822 field-list simple">
|
||
<dt class="field-odd">Author<span class="colon">:</span></dt>
|
||
<dd class="field-odd">Barry Warsaw <barry at python.org>, Łukasz Langa <lukasz at python.org>,
|
||
Antoine Pitrou <solipsis at pitrou.net>, Doug Hellmann <doug at doughellmann.com>,
|
||
Carol Willing <willingc at gmail.com></dd>
|
||
<dt class="field-even">Status<span class="colon">:</span></dt>
|
||
<dd class="field-even"><abbr title="Accepted and implementation complete, or no longer active">Final</abbr></dd>
|
||
<dt class="field-odd">Type<span class="colon">:</span></dt>
|
||
<dd class="field-odd"><abbr title="Non-normative PEP containing background, guidelines or other information relevant to the Python ecosystem">Informational</abbr></dd>
|
||
<dt class="field-even">Topic<span class="colon">:</span></dt>
|
||
<dd class="field-even"><a class="reference external" href="../topic/governance/">Governance</a></dd>
|
||
<dt class="field-odd">Created<span class="colon">:</span></dt>
|
||
<dd class="field-odd">24-Aug-2018</dd>
|
||
</dl>
|
||
<hr class="docutils" />
|
||
<section id="contents">
|
||
<details><summary>Table of Contents</summary><ul class="simple">
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
|
||
<li><a class="reference internal" href="#project-choice">Project choice</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#rust">Rust</a><ul>
|
||
<li><a class="reference internal" href="#key-people-and-their-functions">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#regular-decision-process">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#controversial-decision-process">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#planning-a-new-release">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#changes-in-the-process-over-time">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#openstack">OpenStack</a><ul>
|
||
<li><a class="reference internal" href="#id1">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id2">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id3">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id4">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id5">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#jupyter">Jupyter</a><ul>
|
||
<li><a class="reference internal" href="#id6">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id7">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id8">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#voting">Voting</a></li>
|
||
<li><a class="reference internal" href="#planning-releases">Planning releases</a></li>
|
||
<li><a class="reference internal" href="#id9">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#django">Django</a><ul>
|
||
<li><a class="reference internal" href="#id10">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id11">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id12">Controversial decision process</a><ul>
|
||
<li><a class="reference internal" href="#differences-between-deps-and-peps">Differences between DEPs and PEPs</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id13">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id14">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#typescript">TypeScript</a><ul>
|
||
<li><a class="reference internal" href="#id15">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id16">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id17">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id18">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id19">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#astropy">Astropy</a><ul>
|
||
<li><a class="reference internal" href="#id20">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id23">Regular decision process</a><ul>
|
||
<li><a class="reference internal" href="#code-level-decisions">Code-level decisions</a></li>
|
||
<li><a class="reference internal" href="#non-code-decisions">Non-code decisions</a></li>
|
||
<li><a class="reference internal" href="#id25">Voting</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id26">Controversial decision process</a><ul>
|
||
<li><a class="reference internal" href="#ethical-issues">Ethical issues</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id28">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id29">Changes in the process over time</a></li>
|
||
<li><a class="reference internal" href="#self-appreciation">Self-appreciation</a></li>
|
||
<li><a class="reference internal" href="#references">References</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#bonus-microsoft">Bonus: Microsoft</a><ul>
|
||
<li><a class="reference internal" href="#id32">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id33">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id34">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id35">Planning a new release</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
|
||
<li><a class="reference internal" href="#annex-1-template-questions">Annex 1: Template questions</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
</details></section>
|
||
<section id="abstract">
|
||
<h2><a class="toc-backref" href="#abstract" role="doc-backlink">Abstract</a></h2>
|
||
<p>This PEP surveys existing and similar open source and free software projects
|
||
for their governance models, providing summaries that will serve as useful
|
||
references for Python’s own selection of a new governance model in the wake of
|
||
<a class="reference external" href="https://mail.python.org/pipermail/python-committers/2018-July/005664.html">Guido’s retirement</a>.</p>
|
||
<p>Rather than an individual PEP for each of these community surveys, they will
|
||
all be collected here in this PEP.</p>
|
||
</section>
|
||
<section id="rationale">
|
||
<h2><a class="toc-backref" href="#rationale" role="doc-backlink">Rationale</a></h2>
|
||
<p>CPython is not the first open source project to undergo a governance crisis.
|
||
Other projects have experimented various governance options, sometimes several
|
||
times during their existence. There are useful lessons to take away of their
|
||
experience, which will help inform our own decision.</p>
|
||
<section id="project-choice">
|
||
<h3><a class="toc-backref" href="#project-choice" role="doc-backlink">Project choice</a></h3>
|
||
<p>There are many open source projects out there, but it will be most fruitful
|
||
to survey those which are similar enough to CPython on a couple key metrics:</p>
|
||
<ol class="arabic simple">
|
||
<li>the number of contributors and their activity (there are scaling issues that
|
||
don’t make the governance models of very small projects very enlightening
|
||
for our purposes) ;</li>
|
||
<li>being mostly or partly community-driven (company-driven projects can afford
|
||
different governance options, since the company hierarchy has power over
|
||
the main participants) ;</li>
|
||
<li>being faced with important design decisions that require a somewhat formal
|
||
decision process.</li>
|
||
</ol>
|
||
</section>
|
||
</section>
|
||
<section id="rust">
|
||
<h2><a class="toc-backref" href="#rust" role="doc-backlink">Rust</a></h2>
|
||
<p>The governance structure is documented in <a class="reference external" href="https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md">Rust RFC #1068</a>.</p>
|
||
<p>The effective governance process grows organically over time without being entirely
|
||
codified as RFCs, especially in case of day-to-day operation details. One example is
|
||
the <a class="reference external" href="https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737">formation of Domain Working Groups</a> in
|
||
February 2018.</p>
|
||
<section id="key-people-and-their-functions">
|
||
<h3><a class="toc-backref" href="#key-people-and-their-functions" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>In the Rust project there are teams responsible for certain areas. For language features
|
||
there is a “lang team”, for tooling there’s “dev tools” and “Cargo”, and so on.
|
||
Contentious issues have facilitators to drive discussion who often aren’t the decision
|
||
makers. Typically the facilitators are authors of the proposed changes (see
|
||
“Controversial decision process” below). They ensure all key decision makers are
|
||
involved along with interested community members. They push towards an agreeable
|
||
outcome via iteration.</p>
|
||
<p>In practice this means decisions are rarely escalated to the core team.</p>
|
||
<p>The most common role of a contributor is team membership. Issue triage/code review
|
||
privileges without team membership is rare. Contributors have full commit access,
|
||
code ownership separation is based on trust. Writing to the compiler repository is
|
||
frowned upon, all changes go through pull requests and get merged by an integration
|
||
bot after they were reviewed and approved.</p>
|
||
<p>New team members are added by nomination by an existing team member.</p>
|
||
</section>
|
||
<section id="regular-decision-process">
|
||
<h3><a class="toc-backref" href="#regular-decision-process" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Primary work happens via GitHub issues and pull requests. Approving a pull request
|
||
by any team member allows it to be merged without further process. All merged pull
|
||
requests end up in the next stable version of Rust.</p>
|
||
<p>Notifying relevant people by mentions is important. Listening to the firehose of
|
||
e-mails for all GitHub activity is not popular.</p>
|
||
<p>There are planning and triage meetings open to the public happening on IRC and Discord.
|
||
They are not very popular because most of work happens through GitHub. Discussions also
|
||
happen on official Rust forums (<a class="reference external" href="https://users.rust-lang.org/">https://users.rust-lang.org/</a> and
|
||
<a class="reference external" href="https://internals.rust-lang.org/">https://internals.rust-lang.org/</a>). There is a dedicated moderation team responsible for
|
||
taking notes and enforcing <a class="reference external" href="https://www.rust-lang.org/en-US/conduct.html">code of conduct</a>.</p>
|
||
</section>
|
||
<section id="controversial-decision-process">
|
||
<h3><a class="toc-backref" href="#controversial-decision-process" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>Larger or controversial work goes through a <a class="reference external" href="https://github.com/rust-lang/rfcs">RFC process</a>. It allows everyone to express their thoughts and
|
||
iterates towards a resolution. At some point when all blocking concerns of relevant
|
||
team members are addressed, they sign off on the RFC and it reaches a “final comment
|
||
period”. That does not require consensus amongst all participants, rather there should
|
||
not be a strong consensus against the proposal.</p>
|
||
<p>After 10 days the RFC is <em>merged</em> unless any new blocking concerns are raised by team
|
||
members. A “merge” signifies that work towards implementing the feature and integrating
|
||
it can now happen without interruption. An RFC doesn’t have to have a reference
|
||
implementation for it to be accepted.</p>
|
||
<p>The other possible results of the “final comment period” are to:</p>
|
||
<ul class="simple">
|
||
<li><em>postpone</em> the RFC (similar to the Deferred status in PEPs),</li>
|
||
<li>get it <em>back into discussion</em> if blocking concerns can be addressed, or</li>
|
||
<li><em>close it</em> if blocking concerns are not solvable. When an RFC is marked as
|
||
<em>closed</em>, there is a 7-day grace period to debate whether it should be closed.</li>
|
||
</ul>
|
||
<p>In practice registering concerns with an RFC happens very often initially but rarely
|
||
causes for the RFC to be entirely killed.</p>
|
||
<p>This process scales well for small-contention changes and/or smaller changes. For the
|
||
largest controversial changes the discussion gets unwieldy. This is a topic currently
|
||
(as of August 2018) on the minds of the Rust team (see:
|
||
<a class="reference external" href="http://aturon.github.io/2018/05/25/listening-part-1/">“Listening and Trust, part 1”</a>,
|
||
<a class="reference external" href="http://aturon.github.io/2018/06/02/listening-part-2/">“Listening and Trust, part 2”</a>,
|
||
<a class="reference external" href="http://aturon.github.io/2018/06/18/listening-part-3/">“Listening and Trust, part 3”</a>,
|
||
<a class="reference external" href="http://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/">“Proposal for a staged RFC process”</a>).</p>
|
||
</section>
|
||
<section id="planning-a-new-release">
|
||
<h3><a class="toc-backref" href="#planning-a-new-release" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>Every six weeks the Rust compiler is released with whatever it contained at the time.
|
||
There are no LTS channels or releases yet but this concept is planned to make
|
||
redistributors able to keep up with development better.</p>
|
||
<p>Every few years a so-called <a class="reference external" href="https://rust-lang-nursery.github.io/edition-guide/editions/index.html">“Edition”</a> is released.
|
||
Those are milestone releases with full sets of updated documentation and tooling. They
|
||
can be backwards incompatible with previous editions. External packages opt into
|
||
breaking changes in their crate metadata. The Rust compiler supports all editions that
|
||
existed prior to its release. Linking between crates of any supported edition is
|
||
possible.</p>
|
||
</section>
|
||
<section id="changes-in-the-process-over-time">
|
||
<h3><a class="toc-backref" href="#changes-in-the-process-over-time" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>The Rust programming language was started by Graydon Hoare who developed it as
|
||
a personal project for a few years. When Mozilla started sponsoring the project,
|
||
the team slowly grew with Graydon as a BDFL-style figure. He <a class="reference external" href="https://www.reddit.com/r/rust/comments/7qels2/i_wonder_why_graydon_hoare_the_author_of_rust/dsqeh1d/">left the project</a>
|
||
in 2013. Rust functions without a BDFL since. The RFC process was put in place later.
|
||
Initially some design discussions happened during closed-door weekly video meetings
|
||
which was <a class="reference external" href="https://github.com/rust-lang/meeting-minutes/blob/master/weekly-meetings/2015-05-26.md#future-of-weekly-meeting">shut down</a>
|
||
in May 2015 (before the 1.0 release of Rust), organically replaced with open discussion
|
||
and direct influence of teams.</p>
|
||
<p>The number of teams is growing in time. The number of technical decisions made by the
|
||
core team is decreasing, instead those get delegated to respective teams.</p>
|
||
<p>The concept of a “final comment period” was introduced to encourage more public
|
||
discussion and enable reacting to a change <em>about to</em> being made, instead of having to
|
||
revert a rushed decision that was already made.</p>
|
||
</section>
|
||
</section>
|
||
<section id="openstack">
|
||
<h2><a class="toc-backref" href="#openstack" role="doc-backlink">OpenStack</a></h2>
|
||
<p>The OpenStack Foundation Bylaws lay out the basic structure for
|
||
project governance, with <a class="reference external" href="https://www.openstack.org/legal/bylaws-of-the-openstack-foundation/">Article IV</a>
|
||
delegating day-to-day management of the open source project to the
|
||
OpenStack Technical Committee (TC), and <a class="reference external" href="https://www.openstack.org/legal/technical-committee-member-policy/">The TC member policy</a>
|
||
defining broadly how the Technical Committee shall be elected. The TC
|
||
publishes a set of more detailed <a class="reference external" href="https://governance.openstack.org/tc/">governance documents</a>, including <a class="reference external" href="https://governance.openstack.org/tc/reference/charter.html">the TC charter</a>, which
|
||
describes the team structure, precise rules for establishing
|
||
eligibility to run for office, and criteria for establishing the
|
||
various electorates.</p>
|
||
<section id="id1">
|
||
<h3><a class="toc-backref" href="#id1" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>The OpenStack community is made up of many distinct <a class="reference external" href="https://governance.openstack.org/tc/reference/projects/index.html">project teams</a>,
|
||
responsible for producing different components of the software (block
|
||
storage management, compute management, etc.) or managing different
|
||
parts of the processes the community follows (such as tracking the
|
||
release schedule). Each team is led by a <em>Project Team Lead</em> (PTL),
|
||
elected by the <em>Active Project Contributors</em> for that project.</p>
|
||
<p>Active Project Contributors (APCs) are recent contributors to a given
|
||
project team. APC status formally requires two things: becoming an
|
||
individual member of the OpenStack Foundation (membership is free) and
|
||
having a change merged within the last year (two development cycles)
|
||
in a repository managed by a project team.</p>
|
||
<p>The elected PTL serves a term equal to one development cycle (roughly
|
||
6 months). There is no restriction on the number of consecutive terms
|
||
a person may serve as PTL, and it is common for someone to serve for
|
||
several terms in a row. It is also not unusual for a team to have only
|
||
one candidate volunteer to serve as PTL for a given cycle, in which
|
||
case there is no need for an election.</p>
|
||
<p>The PTL represents the team in all cases except where they have
|
||
explicitly delegated some responsibility. For example, many teams
|
||
designate a separate <em>release liaison</em> to manage the release process
|
||
for a development cycle. The PTL also serves as a final decision
|
||
maker in cases where consensus cannot be reached between the team
|
||
members.</p>
|
||
<p>While the APCs all vote for the PTL of a team, in many other cases
|
||
only the <em>core reviewer</em> team will be consulted on policy decisions
|
||
for the team. Anyone may review any patch for any OpenStack
|
||
project. After someone demonstrates that they have a good grasp of the
|
||
technical issues of a project, that they provide useful feedback on
|
||
reviews, and that they understand the direction the project is going,
|
||
they may be invited to become a member of the core review team. Unlike
|
||
in many other communities, this status does not grant them the right
|
||
to submit code without having it reviewed. Rather, it asks them to
|
||
commit to reviewing code written by other contributors, and to
|
||
participate in team decision-making discussions. Asking someone to
|
||
become a member of the core review team is a strong indication of
|
||
trust.</p>
|
||
<p>The Technical Committee (TC) is responsible for managing the
|
||
development of OpenStack as a whole. The 13 members of the Technical
|
||
Committee are directly elected by APCs from all project teams. Each
|
||
member serves a term of two development cycles (roughly 1 year), with
|
||
the elections split so that only about half of the members’ terms
|
||
expire at any time, to ensure continuity. The TC establishes overall
|
||
policies, such as the criteria for adding new project teams, the
|
||
deprecation policy for Python 2, testing requirements, etc.</p>
|
||
</section>
|
||
<section id="id2">
|
||
<h3><a class="toc-backref" href="#id2" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>All elections for PTL or TC members use <a class="reference external" href="https://civs.cs.cornell.edu">https://civs.cs.cornell.edu</a> to
|
||
run a <em>Condorcet</em> election. This system was selected because it
|
||
emphasizes consensus candidates over strict popularity.</p>
|
||
<p>The OpenStack contributor community relies on 3 primary tools for
|
||
discussion: the <a class="reference external" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">openstack-dev mailing list</a>,
|
||
a gerrit code review instance at <a class="reference external" href="https://review.openstack.org">https://review.openstack.org</a>, and a
|
||
set of <a class="reference external" href="http://eavesdrop.openstack.org">OpenStack-specific IRC channels</a> on Freenode. There are a few teams
|
||
whose contributors are based primarily in China, and they have trouble
|
||
accessing IRC. Those teams tend to use alternative platforms such as
|
||
WeChat, instead.</p>
|
||
<p>The tool used for discussing any given decision will vary based on its
|
||
weight and impact. Everyone is encouraged to use either the mailing
|
||
list or gerrit to support asynchronous discussion across a wider range
|
||
of timezones and firewalls, especially for publicizing final
|
||
decisions for the rest of the community.</p>
|
||
<p>Policy decisions limited to a single team are usually made by the core
|
||
review team for a project, and the policies and decision processes may
|
||
vary between teams. Some groups write down their team policies in
|
||
their documentation repository, and use the code review tool (gerrit)
|
||
to vote on them. Some teams discuss policies on IRC, either ad hoc or
|
||
during a regularly scheduled meeting, and make decisions there. Some
|
||
teams use the mailing list for those discussions. The PTL for the team
|
||
is responsible for ensuring the discussion is managed and the outcome
|
||
is communicated (either by doing so directly or ensuring that the task
|
||
is delegated to someone else).</p>
|
||
<p>All team policy decisions need to be compatible with the overall
|
||
policies set by the Technical Committee. Because the TC tends to make
|
||
broader governance decisions that apply to the entire contributor
|
||
community, the process for discussing and voting on those decisions is
|
||
described more formally, including specifying the number of votes
|
||
needed to pass and the minimum length of time required for
|
||
discussion. For example, most motions require 1/3 of the members (5)
|
||
to pass and must stay open at least 3 days after receiving sufficient
|
||
votes to pass, ensuring that there is time for dissent to be
|
||
registered. See the <a class="reference external" href="https://governance.openstack.org/tc/reference/charter.html#motions">Technical Committee Charter</a>
|
||
and <a class="reference external" href="https://governance.openstack.org/tc/reference/house-rules.html">house rules</a>
|
||
for more details.</p>
|
||
<p>Significant design decisions are usually discussed by reviewing a
|
||
<a class="reference external" href="http://specs.openstack.org">specification document</a>, somewhat
|
||
similar to a PEP, that covers the requirements, alternatives, and
|
||
implementation details. Feedback is solicited from all contributors,
|
||
and then specifications are eventually approved or rejected by members
|
||
of the core review team for a project. Some teams require only 2
|
||
reviewers to approve a design, while other teams require a stronger
|
||
indication of consensus before a design is approved. Each team sets a
|
||
<a class="reference external" href="https://releases.openstack.org/rocky/schedule.html">deadline for approving specifications within each development cycle</a>, to encourage
|
||
contributors to work out designs for significant new features early
|
||
and avoid risk from changes late in the cycle.</p>
|
||
<p>Smaller technical decisions are typically made by reviewing the
|
||
patch(es) needed to implement the change. Anyone may review any patch
|
||
and provide technical feedback, but ultimately two core reviewers for
|
||
a team are needed to approve most changes (exceptions are often made
|
||
for trivial changes such as typos or for fixes that unblock the CI
|
||
gating system).</p>
|
||
</section>
|
||
<section id="id3">
|
||
<h3><a class="toc-backref" href="#id3" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>Controversial, or merely complicated, decisions frequently expand
|
||
outside of specification reviews to mailing list discussions. They
|
||
often also result in discussions at one of the regularly scheduled
|
||
in-person community gatherings. Because many members of the community
|
||
cannot attend these events, the discussions are summarized and final
|
||
decisions are made using on-line tools as much as possible.</p>
|
||
<p>The PTL is responsible for deciding when consensus has been reached
|
||
for decisions that affect a single team, and to make a final call in
|
||
rare cases where consensus has not been reached and a decision
|
||
absolutely needs to be made. The TC acts as a similar decision-making
|
||
group of last resort for cases where issues <em>between</em> teams cannot be
|
||
resolved in another way. Such escalation of decision-making ends up
|
||
being rarely necessary, because the contributors directly involved
|
||
generally prefer to come to a consensual agreement rather than
|
||
escalate the decision to others.</p>
|
||
</section>
|
||
<section id="id4">
|
||
<h3><a class="toc-backref" href="#id4" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>OpenStack has a major release about every 6 months. These are
|
||
coordinated date-based releases, which include the work finished up to
|
||
that point in time in all of the member projects. Some project teams
|
||
release more often than every 6 months (this is especially true for
|
||
teams building libraries consumed by other teams). Those smaller
|
||
releases tend to be produced when there is content (new features or
|
||
bug fixes) to justify them.</p>
|
||
<p>The schedule for each development cycle, with deadlines and a final
|
||
release date, is proposed by the release management team, in
|
||
coordination with the Foundation staff (releases are generally aligned
|
||
with the calendar of in-person events), and then the community has an
|
||
opportunity to provide feedback before the final dates are set.</p>
|
||
<p>Decisions about priorities for each development cycle are made at the
|
||
team level and the TC level. Core review teams prioritize internal
|
||
work, such as fixing bugs and implementing new features. The TC
|
||
selects <a class="reference external" href="https://governance.openstack.org/tc/goals/index.html">community goals</a>, which
|
||
usually require some amount of work from all teams. Agreeing to these
|
||
priorities at the start of each cycle helps the teams coordinate their
|
||
work, which is especially important because the implementation will
|
||
require reviews from multiple team members.</p>
|
||
</section>
|
||
<section id="id5">
|
||
<h3><a class="toc-backref" href="#id5" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>Over the last 8 years the number of OpenStack project teams has grown
|
||
from 2 to 63. The makeup of the Technical Committee has changed to
|
||
accommodate that growth. Originally the TC was made up of PTLs, but as
|
||
the membership grew it became impractical for the group to function
|
||
effectively.</p>
|
||
<p>The community also used to be organized around “program areas” rather
|
||
than project teams. A program area covered a feature set, such as
|
||
gathering telemetry or managing block storage. This organization
|
||
failed when multiple teams of people wanted to work on the same
|
||
feature set using different solutions. Organizing teams around the
|
||
code they deliver allows different teams to have different
|
||
interpretations of the same requirements. For example, there are now
|
||
several teams working on different deployment tools.</p>
|
||
</section>
|
||
</section>
|
||
<section id="jupyter">
|
||
<h2><a class="toc-backref" href="#jupyter" role="doc-backlink">Jupyter</a></h2>
|
||
<p>The governance structure is documented in the <a class="reference external" href="https://github.com/jupyter/governance/blob/master/governance.md">Main Governance Document</a>
|
||
within the <a class="reference external" href="https://github.com/jupyter/governance">Jupyter Governance repo</a>.</p>
|
||
<p>The effective governance process grows organically over time as the needs of
|
||
the project evolve. Formal changes to the Governance Document are submitted via
|
||
Pull Request, with an open period for comments. After the open period, a
|
||
Steering Council may call for a vote to ratify the PR changes. Acceptance
|
||
requires a minimum of 80% of the Steering Council to vote and at least 2/3 of
|
||
the vote must be positive. The BDFL can act alone to accept or reject changes
|
||
or override the Steering Council decision; though this would be an extremely
|
||
rare event.</p>
|
||
<section id="id6">
|
||
<h3><a class="toc-backref" href="#id6" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>The key people in Jupyter’s Governance are the BDFL, Fernando Perez, and the
|
||
Steering Council. Contributors can be given a special status of core contributor.
|
||
Some may also be Institutional Contributors, who are individuals who contribute
|
||
to the project as part of their official duties at an Institutional Partner.</p>
|
||
<p>Fernando Perez, the project founder, is the current and first BDFL. The BDFL
|
||
may serve as long as desired. The <a class="reference external" href="https://github.com/jupyter/governance/blob/master/governance.md#bdfl">BDFL succession plan</a>
|
||
is described in the Main Governance Document. In summary, the BDFL may appoint
|
||
the next BDFL. As a courtesy, it is expected that the BDFL will consult with the
|
||
Steering Council. In the event that the BDFL can not appoint a successor, the
|
||
Steering Council will recommend one.</p>
|
||
<p>Core contributors are individuals who are given rights, such as commit privileges,
|
||
to act in the best interest of the project within their area of expertise or
|
||
<a class="reference external" href="https://github.com/jupyter/governance/blob/master/newsubprojects.md">subproject</a>.
|
||
An existing core contributor typically recommends someone be given
|
||
core contributor rights by gathering consensus from project leads, who are
|
||
experienced core contributors as listed in the README of the project repo.</p>
|
||
<p>To be recommended and invited as a Steering Council member, 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.</p>
|
||
</section>
|
||
<section id="id7">
|
||
<h3><a class="toc-backref" href="#id7" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Project Jupyter is made up of a number of GitHub organizations and subprojects
|
||
within those organizations. Primary work happens via GitHub issues and pull
|
||
requests. Approving a pull request by any team member allows it to be merged
|
||
without further process. All merged pull requests end up in the next stable
|
||
release of a subproject.</p>
|
||
<p>There is a weekly, public Project-wide meeting that is recorded and posted on
|
||
YouTube. Some larger GitHub organizations, which are subprojects of
|
||
Project Jupyter, e.g. JupyterLab and JupyterHub, may
|
||
have additional public team meetings on a weekly or monthly schedule.
|
||
Discussions occur on Gitter, the Jupyter mailing list, and most frequently an
|
||
open issue and/or pull request on GitHub.</p>
|
||
</section>
|
||
<section id="id8">
|
||
<h3><a class="toc-backref" href="#id8" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>The foundations of Project Jupyter’s governance are:</p>
|
||
<ul class="simple">
|
||
<li>Openness & Transparency</li>
|
||
<li>Active Contribution</li>
|
||
<li>Institutional Neutrality</li>
|
||
</ul>
|
||
<p>During the everyday project activities, Steering 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.</p>
|
||
<p>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
|
||
on an issue in a reasonable time frame.</p>
|
||
</section>
|
||
<section id="voting">
|
||
<h3><a class="toc-backref" href="#voting" role="doc-backlink">Voting</a></h3>
|
||
<p>Rarely, if ever, is voting done for technical decisions.</p>
|
||
<p>For other Project issues, the Steering Council may call for a vote for a
|
||
decision via a Governance PR or email proposal. Acceptance
|
||
requires a minimum of 80% of the Steering Council to vote and at least 2/3 of
|
||
the vote must be positive.</p>
|
||
<p>The BDFL can act alone to accept or reject changes or override the Steering
|
||
Council decision; though this would be an extremely rare event. As Benevolent,
|
||
the BDFL, in practice chooses to defer that authority to the consensus of the
|
||
community discussion channels and the Steering Council.</p>
|
||
</section>
|
||
<section id="planning-releases">
|
||
<h3><a class="toc-backref" href="#planning-releases" role="doc-backlink">Planning releases</a></h3>
|
||
<p>Since Project Jupyter has a number of projects, not just a single project, the
|
||
release planning is largely driven by the core contributors of a project.</p>
|
||
</section>
|
||
<section id="id9">
|
||
<h3><a class="toc-backref" href="#id9" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>The process has remained consistent over time, and the approach has served us
|
||
well. Moving forward The Project leadership will consist of a BDFL and
|
||
Steering Council. This governance model was a formalization of what
|
||
the Project was doing (prior to 2015 when the Main Governance Document was
|
||
adopted by the Steering Council), rather than a change in direction.</p>
|
||
</section>
|
||
</section>
|
||
<section id="django">
|
||
<h2><a class="toc-backref" href="#django" role="doc-backlink">Django</a></h2>
|
||
<p>The governance structure is documented in <a class="reference external" href="https://docs.djangoproject.com/en/2.1/internals/organization/">Organization of the Django Project</a>.</p>
|
||
<section id="id10">
|
||
<h3><a class="toc-backref" href="#id10" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>The project recognizes three kinds of contributors. Members of the
|
||
core team, the Technical Board, and Fellows. Regular core committers
|
||
no longer exercise their “commit bit”, instead they rely on pull
|
||
requests being reviewed and accepted. The Technical Board steers
|
||
technical choices. Fellows are hired contractors who triage new
|
||
tickets, review and merge patches from the committers and community,
|
||
including non-trivial ones.</p>
|
||
<p>Core team members are added by nomination and vote within the core
|
||
team, with technical board veto (so far not exercised). Technical
|
||
board is elected by and from the core team membership every 18 months
|
||
(every major Django release). Sub-teams within the core team are
|
||
self-selected by interest.</p>
|
||
</section>
|
||
<section id="id11">
|
||
<h3><a class="toc-backref" href="#id11" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Most day-to-day decisions are made by Fellows and sometimes other active
|
||
core team members.</p>
|
||
<p>The core team votes on new members which requires a 4/5 majority of
|
||
votes cast, no quorum requirement. The Technical Board has veto power.
|
||
This power was never exercised</p>
|
||
</section>
|
||
<section id="id12">
|
||
<h3><a class="toc-backref" href="#id12" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>The Technical Board occasionally approves Django
|
||
Enhancement Proposals (DEPs) but those are rare. The DEP process is
|
||
roughly modeled after PEPs and documented in <a class="reference external" href="https://github.com/django/deps/blob/main/final/0001-dep-process.rst">DEP 1</a>.
|
||
DEPs are mostly used to design major new features, but also for
|
||
information on general guidelines and process.</p>
|
||
<p>An idea for a DEP should be first publicly vetted on the
|
||
django-developers mailing list. After it was roughly validated, the
|
||
author forms a team with three roles:</p>
|
||
<ul class="simple">
|
||
<li><em>authors</em> who write the DEP and steers the discussion;</li>
|
||
<li><em>implementers</em> who prepare the implementation of the DEP;</li>
|
||
<li>a <em>shepherd</em> who is a core developer and will be the primary reviewer
|
||
of the DEP.</li>
|
||
</ul>
|
||
<p>The DEP’s draft is submitted, assigned a number, and discussed. Authors
|
||
collect feedback and steer discussion as they see fit. Suggested venues
|
||
to avoid endless open-ended discussions are: separate mailing lists,
|
||
Wiki pages, working off of pull requests on the DEP.</p>
|
||
<p>Once the feedback round is over, the shepherd asks the Technical Board
|
||
for review and pronouncement. The Board can rule on a DEP as a team or
|
||
designate one member to review and decide.</p>
|
||
<p>In any case where consensus can’t be reached, the Technical Board has
|
||
final say. This was never exercised.</p>
|
||
<section id="differences-between-deps-and-peps">
|
||
<h4><a class="toc-backref" href="#differences-between-deps-and-peps" role="doc-backlink">Differences between DEPs and PEPs</a></h4>
|
||
<p>The main difference is that the entire workflow is based on pull
|
||
requests rather than e-mail. They are pronounced upon by the Technical
|
||
Board. They need to have the key roles identified before submission
|
||
and throughout the process. The <em>shepherd</em> role exists to guide a DEP
|
||
to completion without engaging the Technical Board.</p>
|
||
<p>Those changes to the process make it more distributed and workable in
|
||
a governance model without a BDFL.</p>
|
||
</section>
|
||
</section>
|
||
<section id="id13">
|
||
<h3><a class="toc-backref" href="#id13" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>Releases are done on a fixed time-based schedule, with a major version
|
||
every 18 months. With paid Fellows to ensure the necessary work gets
|
||
down, on-time releases are routine.</p>
|
||
</section>
|
||
<section id="id14">
|
||
<h3><a class="toc-backref" href="#id14" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>Django originally had two BDFLs: Jacob Kaplan-Moss and Adrian Holovaty.
|
||
They retired (<a class="reference external" href="http://www.holovaty.com/writing/bdfls-retiring/">Adrian’s post</a>, <a class="reference external" href="https://jacobian.org/writing/retiring-as-bdfls/">Jacob’s post</a>)
|
||
9 years into the project’s history. Following the stepping down,
|
||
the DEP process was defined.</p>
|
||
</section>
|
||
</section>
|
||
<section id="typescript">
|
||
<h2><a class="toc-backref" href="#typescript" role="doc-backlink">TypeScript</a></h2>
|
||
<p>The governance structure is not externally documented besides the
|
||
<a class="reference external" href="https://github.com/Microsoft/TypeScript/blob/main/CONTRIBUTING.md">CONTRIBUTING.md</a>
|
||
document in the main TypeScript repository.</p>
|
||
<section id="id15">
|
||
<h3><a class="toc-backref" href="#id15" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>There is a formal design team and a release management team working at
|
||
Microsoft. The main person behind the project is currently Anders
|
||
Hejlsberg as some of the original members of the team have left the
|
||
company.</p>
|
||
</section>
|
||
<section id="id16">
|
||
<h3><a class="toc-backref" href="#id16" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Microsoft, where the project is developed, has a strong planning culture
|
||
so development roadmaps are released long in advanced, notes from
|
||
design discussions held at Microsoft get published quickly and meetings
|
||
are sometimes broadcast using Skype.</p>
|
||
<p>External contributions are encouraged through pull requests on GitHub.
|
||
Suggestions for new use cases or features are given by issues on GitHub.
|
||
This serves like an ad-hoc PEP-like process. There is some discussion
|
||
over social media (Twitter) as well.</p>
|
||
</section>
|
||
<section id="id17">
|
||
<h3><a class="toc-backref" href="#id17" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>Hejlsberg is the central figure of the project in terms of language
|
||
design, synthesizing community needs into a cohesive whole. There is
|
||
no formal process to externally contribute to the design of the
|
||
language.</p>
|
||
<p>The TypeScript team filters through and integrates community
|
||
suggestions. The main advantages of this setup are that there is
|
||
strong and consistent design with dependable scheduling and
|
||
execution. While there is transparency of intentions and plans, the
|
||
disadvantage of this model is that community involvement is limited
|
||
to pull requests and suggestions.</p>
|
||
</section>
|
||
<section id="id18">
|
||
<h3><a class="toc-backref" href="#id18" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>Microsoft determines the release schedule, communicates dates and
|
||
features well in advance. Nightly builds are usually stable (with
|
||
a significant portion of users on this release form).</p>
|
||
<p>Versioned releases are done every 1 - 3 months, with a roadmap available
|
||
on GitHub.</p>
|
||
</section>
|
||
<section id="id19">
|
||
<h3><a class="toc-backref" href="#id19" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>TypeScript is likely the first notable project by Microsoft developed
|
||
fully in the open (versus source-available).</p>
|
||
<p>Open-sourcing of TypeScript by Microsoft was a planned feature from the
|
||
inception of the project. Before the first open release was made, the
|
||
language was driven fully by needs identified by the original teams and
|
||
the early in-house users. The initial open-sourcing happened via
|
||
the now-defunct Microsoft CodePlex platform. It didn’t have
|
||
a well-defined routine of accepting external contributions. Community
|
||
engagement rose significantly after the project got moved.</p>
|
||
</section>
|
||
</section>
|
||
<section id="astropy">
|
||
<h2><a class="toc-backref" href="#astropy" role="doc-backlink">Astropy</a></h2>
|
||
<section id="id20">
|
||
<h3><a class="toc-backref" href="#id20" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>The Astropy Project team’s responsibilities are spread over many different
|
||
roles <a class="footnote-reference brackets" href="#astropy-team" id="id21">[1]</a>, though frequently a person will have several roles.</p>
|
||
<p>The main body overseeing the Astropy Project is the Astropy
|
||
<em>Coordination Committee</em> (CoCo) . Its key roles are dealing with any
|
||
financial issues, approving new packages wanting to join the Astropy
|
||
Project, approving or rejecting <em>Astropy Proposals for Enhancement</em>
|
||
(APEs) <a class="footnote-reference brackets" href="#astropy-apes" id="id22">[2]</a>, 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.</p>
|
||
</section>
|
||
<section id="id23">
|
||
<h3><a class="toc-backref" href="#id23" role="doc-backlink">Regular decision process</a></h3>
|
||
<section id="code-level-decisions">
|
||
<h4><a class="toc-backref" href="#code-level-decisions" role="doc-backlink">Code-level decisions</a></h4>
|
||
<p>The Astropy Project includes the <em>core Astropy package</em> and other
|
||
<em>affiliated packages</em>. For the sake of simplicity, we will avoid
|
||
discussing affiliated packages, which can have their own rules.
|
||
Therefore, everything below will concern the core Astropy package.</p>
|
||
<p>The core Astropy package is organized as <em>sub-packages</em>. Each sub-package
|
||
has an official <em>maintainer</em> as well as one or more <em>deputies</em>, 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.</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="non-code-decisions">
|
||
<h4><a class="toc-backref" href="#non-code-decisions" role="doc-backlink">Non-code decisions</a></h4>
|
||
<p>Non-code decisions (like sprint scheduling, bugfix release timing, etc)
|
||
are usually announced on the <em>astropy-dev mailing list</em> <a class="footnote-reference brackets" href="#astropy-dev" id="id24">[3]</a> 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.</p>
|
||
</section>
|
||
<section id="id25">
|
||
<h4><a class="toc-backref" href="#id25" role="doc-backlink">Voting</a></h4>
|
||
<p>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.</p>
|
||
</section>
|
||
</section>
|
||
<section id="id26">
|
||
<h3><a class="toc-backref" href="#id26" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>Simpler controversial decisions are generally discussed on the astropy-dev
|
||
mailing list <a class="footnote-reference brackets" href="#astropy-dev" id="id27">[3]</a>, 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.</p>
|
||
<p>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.</p>
|
||
<section id="ethical-issues">
|
||
<h4><a class="toc-backref" href="#ethical-issues" role="doc-backlink">Ethical issues</a></h4>
|
||
<p>The Project has an <em>Ombudsperson</em> 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.</p>
|
||
</section>
|
||
</section>
|
||
<section id="id28">
|
||
<h3><a class="toc-backref" href="#id28" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>The major release timing is on a fixed schedule (every 6 months); whatever
|
||
is in at that time goes in.</p>
|
||
</section>
|
||
<section id="id29">
|
||
<h3><a class="toc-backref" href="#id29" role="doc-backlink">Changes in the process over time</a></h3>
|
||
<p>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 <em>Vision for Astropy</em> document <a class="footnote-reference brackets" href="#astropy-vision" id="id30">[4]</a>.</p>
|
||
<p>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 <a class="footnote-reference brackets" href="#astropy-dev" id="id31">[3]</a>. In general all
|
||
evolved as sort of ratification of already-existing practices, only after
|
||
they were first tested in the wild.</p>
|
||
</section>
|
||
<section id="self-appreciation">
|
||
<h3><a class="toc-backref" href="#self-appreciation" role="doc-backlink">Self-appreciation</a></h3>
|
||
<p>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.</p>
|
||
<p>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.</p>
|
||
</section>
|
||
<section id="references">
|
||
<h3><a class="toc-backref" href="#references" role="doc-backlink">References</a></h3>
|
||
<aside class="footnote-list brackets">
|
||
<aside class="footnote brackets" id="astropy-team" role="doc-footnote">
|
||
<dt class="label" id="astropy-team">[<a href="#id21">1</a>]</dt>
|
||
<dd>Astropy roles and responsibilities
|
||
<a class="reference external" href="https://www.astropy.org/team.html">https://www.astropy.org/team.html</a></aside>
|
||
<aside class="footnote brackets" id="astropy-apes" role="doc-footnote">
|
||
<dt class="label" id="astropy-apes">[<a href="#id22">2</a>]</dt>
|
||
<dd>Astropy Proposals for Enhancement
|
||
<a class="reference external" href="https://github.com/astropy/astropy-APEs">https://github.com/astropy/astropy-APEs</a></aside>
|
||
<aside class="footnote brackets" id="astropy-dev" role="doc-footnote">
|
||
<dt class="label" id="astropy-dev">[3]<em> (<a href='#id24'>1</a>, <a href='#id27'>2</a>, <a href='#id31'>3</a>) </em></dt>
|
||
<dd>Astropy-dev mailing list
|
||
<a class="reference external" href="https://groups.google.com/forum/#!forum/astropy-dev">https://groups.google.com/forum/#!forum/astropy-dev</a></aside>
|
||
<aside class="footnote brackets" id="astropy-vision" role="doc-footnote">
|
||
<dt class="label" id="astropy-vision">[<a href="#id30">4</a>]</dt>
|
||
<dd>Vision for a Common Astronomy Python Package
|
||
<a class="reference external" href="https://docs.astropy.org/en/stable/development/vision.html">https://docs.astropy.org/en/stable/development/vision.html</a></aside>
|
||
</aside>
|
||
</section>
|
||
</section>
|
||
<section id="bonus-microsoft">
|
||
<h2><a class="toc-backref" href="#bonus-microsoft" role="doc-backlink">Bonus: Microsoft</a></h2>
|
||
<p>Despite the selection process for “relevant projects” described above,
|
||
it is worthwhile considering how companies that are held financially
|
||
accountable for their decisions go about making them. This is not
|
||
intended as a readily-usable model for Python, but as additional insight
|
||
that may influence the final design or selection.</p>
|
||
<p>This section is not taken from any official documentation, but has been
|
||
abstracted by Steve Dower, a current Microsoft employee, to reflect the
|
||
processes that are most applicable to individual projects in the
|
||
engineering departments. Role titles are used (and defined) rather than
|
||
identifying specific individuals, and all names are examples and should
|
||
not be taken as a precise description of the company at any particular
|
||
time in history.</p>
|
||
<p>This is also highly simplified and idealised. There are plenty of
|
||
unhealthy teams that do not look like this description, and those
|
||
typically have high attrition (people leave the team more frequently
|
||
than other teams). Teams that retain their people are usually closer to
|
||
the model described here, but ultimately everything involving humans is
|
||
imperfect and Microsoft is no exception.</p>
|
||
<section id="id32">
|
||
<h3><a class="toc-backref" href="#id32" role="doc-backlink">Key people and their functions</a></h3>
|
||
<p>Microsoft has a hierarchy that ultimately reports to the CEO. Below the
|
||
CEO are a number of organisations, some of which are focused on
|
||
engineering projects (as opposed to sales, marketing or other functions).
|
||
These engineering organisations roughly break down into significant
|
||
product families - for example, there has been a “Windows group”, an
|
||
“Xbox group”, and a “server and tools group”. These are typically led by
|
||
<em>Executive Vice Presidents</em> (EVPs), who report to the CEO.</p>
|
||
<p>Below each EVP are many <em>Corporate Vice Presidents</em> (CVPs), each of which
|
||
is responsible for one or more products. This level is where the hierarchy
|
||
becomes relevant for the purposes of this PEP - the CEO and EVPs are
|
||
rarely involved in most decision processes, but set the direction under
|
||
which CVPs make decisions.</p>
|
||
<p>Each product under a CVP has a team consisting of <em>Program Managers</em>
|
||
(PMs) and <em>Engineering Managers</em>. Engineering Managers have teams of
|
||
engineers who are largely uninvolved in decision making, though may be
|
||
used as specialists in some cases. For the rest of this section,
|
||
<em>Engineering</em> refers to anyone from the engineering team who is
|
||
contributing with a technical-focus, and <em>PM</em> refers to anyone from the
|
||
program management team contributing with a customer-focus. After
|
||
decisions are made, Engineering does the implementation and testing work,
|
||
and PM validates with users that their problem has been solved.</p>
|
||
<p>(This is actually a huge simplification, to the point where some people
|
||
in these roles are offended by this characterisation. In reality, most
|
||
people in PM or Engineering do work that crosses the boundary between
|
||
the two roles, and so they should be treated as a term describing the
|
||
work that somebody is doing in the moment, rather than an identifier or
|
||
restriction for a person.)</p>
|
||
<p>Teams generally represent a feature, while the CVP represents a product.
|
||
For example, Visual Studio Code has a CVP who is ultimately responsible
|
||
for decisions about that product and its overall direction (in the context
|
||
set by their EVP). But many teams contribute features into Visual Studio
|
||
Code.</p>
|
||
<p>For complete clarity, the CEO, EVPs, and CVPs do not ever directly
|
||
modify source code. Their entire role is to provide direction for
|
||
whoever is immediately below them and to adjudicate on controversial
|
||
decisions.</p>
|
||
</section>
|
||
<section id="id33">
|
||
<h3><a class="toc-backref" href="#id33" role="doc-backlink">Regular decision process</a></h3>
|
||
<p>Changes to product code that are not visible to external users are made
|
||
solely by Engineering. Individual engineers will be assigned tasks by a
|
||
designated engineering manager, or may self-assign. Promotion to
|
||
increasingly senior positions generally reflects trust in the
|
||
individual’s decision-making ability, and more senior engineers are
|
||
trusted to make decisions with less validation from the rest of the team.
|
||
Most bugs are covered by this process (that is, fixing a user-visible
|
||
problem without changing the intended experience is an Engineering
|
||
decision).</p>
|
||
<p>Decisions affecting users of a particular feature are made by the PM
|
||
team for that feature. They will use whatever data sources available to
|
||
identify an issue, experiment with alternatives, and ultimately prepare
|
||
a design document. Senior members from PM and Engineering will review
|
||
designs to clarify the details, and ultimately an artifact is created
|
||
that the feature team agrees on. Engineering will use this artifact to
|
||
implement the work, and PM will later use this artifact to validate that
|
||
the original issue has been resolved.</p>
|
||
<p>Senior members of Engineering and PM teams for a feature are expected to
|
||
make decisions in the spirit of the direction set by their CVP. Teams
|
||
have regular meetings with their CVP to discuss recent decisions and
|
||
ensure consistency. Decisions that are not obviously in line with CVP
|
||
expectations are escalated to the controversial process.</p>
|
||
</section>
|
||
<section id="id34">
|
||
<h3><a class="toc-backref" href="#id34" role="doc-backlink">Controversial decision process</a></h3>
|
||
<p>When decisions require cross-team coordination, or do not obviously
|
||
align with previous CVP guidance, teams will escalate decision making.
|
||
These often include decisions that involve changing direction,
|
||
attempting to reach a new or different group of users, deprecating and
|
||
removing significant features (or on a short timeframe), or changes that
|
||
require quick releases.</p>
|
||
<p>In general, CVPs are not intimately familiar with all aspects of the
|
||
feature team’s work. As a result, the feature team must provide both a
|
||
recommendation and sufficient context for the decision that the CVP can
|
||
decide <em>without additional knowledge</em>. Most of the time, the first
|
||
attempt results in a series of questions from the CVP, which the team
|
||
will research, answer and attempt the decision again at a later date.</p>
|
||
<p>Common questions asked by CVPs are:</p>
|
||
<ul class="simple">
|
||
<li>how many users are affected by this decision?</li>
|
||
<li>what is the plan for minimizing impact on current users?</li>
|
||
<li>how will the change be “sold”/described to potential users?</li>
|
||
</ul>
|
||
<p>CVPs are expected to have a strong understanding of the entire field, so
|
||
that they can evaluate some questions for themselves, such as:</p>
|
||
<ul class="simple">
|
||
<li>what similar decisions have been made by other projects within Microsoft?</li>
|
||
<li>what other projects have plans that may impact this decision?</li>
|
||
<li>what similar decisions have been made by projects outside Microsoft?</li>
|
||
<li>do users need it?</li>
|
||
<li>is it in line with the direction set by their EVP?</li>
|
||
</ul>
|
||
<p>Decisions made by CVPs are generally arbitrary and final, though they
|
||
typically will provide their rationale.</p>
|
||
</section>
|
||
<section id="id35">
|
||
<h3><a class="toc-backref" href="#id35" role="doc-backlink">Planning a new release</a></h3>
|
||
<p>Releases involve coordinating a number of feature teams, and so rarely
|
||
attempt to include input from all teams. A schedule will be determined
|
||
based on broader ecosystem needs, such as planned events/conferences or
|
||
opportunities to take advantage of media attention.</p>
|
||
<p>Teams are informed of the release date, the theme of the release, and
|
||
make their own plans around it following the above decision making
|
||
process. Changing the release date is considered a controversial
|
||
decision.</p>
|
||
</section>
|
||
</section>
|
||
<section id="acknowledgements">
|
||
<h2><a class="toc-backref" href="#acknowledgements" role="doc-backlink">Acknowledgements</a></h2>
|
||
<p>Thank you to Alex Crichton from the Rust team for an extensive explanation of how the
|
||
core team governs the project.</p>
|
||
<p>Jeremy Stanley, Chris Dent, Julia Kreger, Sean McGinnis, Emmet Hikory,
|
||
and Thierry Carrez contributed to the OpenStack section.</p>
|
||
<p>The Project Jupyter Steering Council created the Main Governance Document for
|
||
Project Jupyter, and Carol Willing summarized the key points of that document
|
||
for the Jupyter section.</p>
|
||
<p>Thank you to Carl Meyer from the Django team for explanation how their
|
||
project’s governance is set up.</p>
|
||
<p>The TypeScript and Swift sections were created after conversations with
|
||
Joe Pamer and Vlad Matveev. Thanks!</p>
|
||
<p>Answers about the Astropy project were kindly contributed, in significant
|
||
detail, by Erik Tollerud and reviewed by other members of the project.</p>
|
||
</section>
|
||
<section id="annex-1-template-questions">
|
||
<h2><a class="toc-backref" href="#annex-1-template-questions" role="doc-backlink">Annex 1: Template questions</a></h2>
|
||
<p>The following set of questions was used as a template to guide evaluation and
|
||
interaction with the surveyed projects:</p>
|
||
<ol class="arabic simple">
|
||
<li>Do you have any open documentation on how the governance model is set up?</li>
|
||
<li>How does the process look like in practice?<ul class="simple">
|
||
<li>Who are the key people?</li>
|
||
<li>What “special statuses” can contributors have?</li>
|
||
<li>How are they elected/how are the statuses assigned?</li>
|
||
<li>How are regular decisions made?</li>
|
||
<li>How are controversial decisions made?</li>
|
||
<li>Is there a voting mechanism? how does it work? how often do votes actually happen?</li>
|
||
<li>Is there a veto mechanism? how often was it actually used?</li>
|
||
</ul>
|
||
</li>
|
||
<li>How do you like the process?<ul class="simple">
|
||
<li>Which parts work well?</li>
|
||
<li>Which parts could work better?</li>
|
||
<li>When it doesn’t work well, how does it look like?</li>
|
||
<li>What would you change if it were only up to you?</li>
|
||
</ul>
|
||
</li>
|
||
<li>Related project work:<ul class="simple">
|
||
<li>How do you decide when a release happens and what goes into it?</li>
|
||
<li>How do you decide who gets commit access?</li>
|
||
<li>Where do you hold discussions? (GitHub, mailing lists, face-to-face meetings, and so on)</li>
|
||
<li>Do you have a RFC/PEP-like process?</li>
|
||
<li>Who has access to those discussion channels?</li>
|
||
<li>How is this access granted/revoked?</li>
|
||
<li>Who moderates those discussions?</li>
|
||
<li>Do you (and how) censure participants and how?</li>
|
||
</ul>
|
||
</li>
|
||
<li>Process evolution<ul class="simple">
|
||
<li>How did this process evolve historically?</li>
|
||
<li>How can it be changed in the future?</li>
|
||
</ul>
|
||
</li>
|
||
</ol>
|
||
</section>
|
||
<section id="copyright">
|
||
<h2><a class="toc-backref" href="#copyright" role="doc-backlink">Copyright</a></h2>
|
||
<p>This document has been placed in the public domain.</p>
|
||
</section>
|
||
</section>
|
||
<hr class="docutils" />
|
||
<p>Source: <a class="reference external" href="https://github.com/python/peps/blob/main/peps/pep-8002.rst">https://github.com/python/peps/blob/main/peps/pep-8002.rst</a></p>
|
||
<p>Last modified: <a class="reference external" href="https://github.com/python/peps/commits/main/peps/pep-8002.rst">2023-09-09 17:39:29 GMT</a></p>
|
||
|
||
</article>
|
||
<nav id="pep-sidebar">
|
||
<h2>Contents</h2>
|
||
<ul>
|
||
<li><a class="reference internal" href="#abstract">Abstract</a></li>
|
||
<li><a class="reference internal" href="#rationale">Rationale</a><ul>
|
||
<li><a class="reference internal" href="#project-choice">Project choice</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#rust">Rust</a><ul>
|
||
<li><a class="reference internal" href="#key-people-and-their-functions">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#regular-decision-process">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#controversial-decision-process">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#planning-a-new-release">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#changes-in-the-process-over-time">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#openstack">OpenStack</a><ul>
|
||
<li><a class="reference internal" href="#id1">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id2">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id3">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id4">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id5">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#jupyter">Jupyter</a><ul>
|
||
<li><a class="reference internal" href="#id6">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id7">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id8">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#voting">Voting</a></li>
|
||
<li><a class="reference internal" href="#planning-releases">Planning releases</a></li>
|
||
<li><a class="reference internal" href="#id9">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#django">Django</a><ul>
|
||
<li><a class="reference internal" href="#id10">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id11">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id12">Controversial decision process</a><ul>
|
||
<li><a class="reference internal" href="#differences-between-deps-and-peps">Differences between DEPs and PEPs</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id13">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id14">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#typescript">TypeScript</a><ul>
|
||
<li><a class="reference internal" href="#id15">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id16">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id17">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id18">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id19">Changes in the process over time</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#astropy">Astropy</a><ul>
|
||
<li><a class="reference internal" href="#id20">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id23">Regular decision process</a><ul>
|
||
<li><a class="reference internal" href="#code-level-decisions">Code-level decisions</a></li>
|
||
<li><a class="reference internal" href="#non-code-decisions">Non-code decisions</a></li>
|
||
<li><a class="reference internal" href="#id25">Voting</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id26">Controversial decision process</a><ul>
|
||
<li><a class="reference internal" href="#ethical-issues">Ethical issues</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#id28">Planning a new release</a></li>
|
||
<li><a class="reference internal" href="#id29">Changes in the process over time</a></li>
|
||
<li><a class="reference internal" href="#self-appreciation">Self-appreciation</a></li>
|
||
<li><a class="reference internal" href="#references">References</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#bonus-microsoft">Bonus: Microsoft</a><ul>
|
||
<li><a class="reference internal" href="#id32">Key people and their functions</a></li>
|
||
<li><a class="reference internal" href="#id33">Regular decision process</a></li>
|
||
<li><a class="reference internal" href="#id34">Controversial decision process</a></li>
|
||
<li><a class="reference internal" href="#id35">Planning a new release</a></li>
|
||
</ul>
|
||
</li>
|
||
<li><a class="reference internal" href="#acknowledgements">Acknowledgements</a></li>
|
||
<li><a class="reference internal" href="#annex-1-template-questions">Annex 1: Template questions</a></li>
|
||
<li><a class="reference internal" href="#copyright">Copyright</a></li>
|
||
</ul>
|
||
|
||
<br>
|
||
<a id="source" href="https://github.com/python/peps/blob/main/peps/pep-8002.rst">Page Source (GitHub)</a>
|
||
</nav>
|
||
</section>
|
||
<script src="../_static/colour_scheme.js"></script>
|
||
<script src="../_static/wrap_tables.js"></script>
|
||
<script src="../_static/sticky_banner.js"></script>
|
||
</body>
|
||
</html> |