This PEP surveys existing and similar open source and free software projectsfor their governance models, providing summaries that will serve as usefulreferences for Python’s own selection of a new governance model in the wake ofGuido’s retirement.
Rather than an individual PEP for each of these community surveys, they willall be collected here in this PEP.
CPython is not the first open source project to undergo a governance crisis.Other projects have experimented various governance options, sometimes severaltimes during their existence. There are useful lessons to take away of theirexperience, which will help inform our own decision.
There are many open source projects out there, but it will be most fruitfulto survey those which are similar enough to CPython on a couple key metrics:
The governance structure is documented inRust RFC #1068.
The effective governance process grows organically over time without being entirelycodified as RFCs, especially in case of day-to-day operation details. One example istheformation of Domain Working Groups inFebruary 2018.
In the Rust project there are teams responsible for certain areas. For language featuresthere 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 decisionmakers. Typically the facilitators are authors of the proposed changes (see“Controversial decision process” below). They ensure all key decision makers areinvolved along with interested community members. They push towards an agreeableoutcome via iteration.
In practice this means decisions are rarely escalated to the core team.
The most common role of a contributor is team membership. Issue triage/code reviewprivileges without team membership is rare. Contributors have full commit access,code ownership separation is based on trust. Writing to the compiler repository isfrowned upon, all changes go through pull requests and get merged by an integrationbot after they were reviewed and approved.
New team members are added by nomination by an existing team member.
Primary work happens via GitHub issues and pull requests. Approving a pull requestby any team member allows it to be merged without further process. All merged pullrequests end up in the next stable version of Rust.
Notifying relevant people by mentions is important. Listening to the firehose ofe-mails for all GitHub activity is not popular.
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 alsohappen on official Rust forums (https://users.rust-lang.org/ andhttps://internals.rust-lang.org/). There is a dedicated moderation team responsible fortaking notes and enforcingcode of conduct.
Larger or controversial work goes through aRFC process. It allows everyone to express their thoughts anditerates towards a resolution. At some point when all blocking concerns of relevantteam members are addressed, they sign off on the RFC and it reaches a “final commentperiod”. That does not require consensus amongst all participants, rather there shouldnot be a strong consensus against the proposal.
After 10 days the RFC ismerged unless any new blocking concerns are raised by teammembers. A “merge” signifies that work towards implementing the feature and integratingit can now happen without interruption. An RFC doesn’t have to have a referenceimplementation for it to be accepted.
The other possible results of the “final comment period” are to:
In practice registering concerns with an RFC happens very often initially but rarelycauses for the RFC to be entirely killed.
This process scales well for small-contention changes and/or smaller changes. For thelargest controversial changes the discussion gets unwieldy. This is a topic currently(as of August 2018) on the minds of the Rust team (see:“Listening and Trust, part 1”,“Listening and Trust, part 2”,“Listening and Trust, part 3”,“Proposal for a staged RFC process”).
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 makeredistributors able to keep up with development better.
Every few years a so-called“Edition” is released.Those are milestone releases with full sets of updated documentation and tooling. Theycan be backwards incompatible with previous editions. External packages opt intobreaking changes in their crate metadata. The Rust compiler supports all editions thatexisted prior to its release. Linking between crates of any supported edition ispossible.
The Rust programming language was started by Graydon Hoare who developed it asa personal project for a few years. When Mozilla started sponsoring the project,the team slowly grew with Graydon as a BDFL-style figure. Heleft the projectin 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 meetingswhich wasshut downin May 2015 (before the 1.0 release of Rust), organically replaced with open discussionand direct influence of teams.
The number of teams is growing in time. The number of technical decisions made by thecore team is decreasing, instead those get delegated to respective teams.
The concept of a “final comment period” was introduced to encourage more publicdiscussion and enable reacting to a changeabout to being made, instead of having torevert a rushed decision that was already made.
The OpenStack Foundation Bylaws lay out the basic structure forproject governance, withArticle IVdelegating day-to-day management of the open source project to theOpenStack Technical Committee (TC), andThe TC member policydefining broadly how the Technical Committee shall be elected. The TCpublishes a set of more detailedgovernance documents, includingthe TC charter, whichdescribes the team structure, precise rules for establishingeligibility to run for office, and criteria for establishing thevarious electorates.
The OpenStack community is made up of many distinctproject teams,responsible for producing different components of the software (blockstorage management, compute management, etc.) or managing differentparts of the processes the community follows (such as tracking therelease schedule). Each team is led by aProject Team Lead (PTL),elected by theActive Project Contributors for that project.
Active Project Contributors (APCs) are recent contributors to a givenproject team. APC status formally requires two things: becoming anindividual member of the OpenStack Foundation (membership is free) andhaving a change merged within the last year (two development cycles)in a repository managed by a project team.
The elected PTL serves a term equal to one development cycle (roughly6 months). There is no restriction on the number of consecutive termsa person may serve as PTL, and it is common for someone to serve forseveral terms in a row. It is also not unusual for a team to have onlyone candidate volunteer to serve as PTL for a given cycle, in whichcase there is no need for an election.
The PTL represents the team in all cases except where they haveexplicitly delegated some responsibility. For example, many teamsdesignate a separaterelease liaison to manage the release processfor a development cycle. The PTL also serves as a final decisionmaker in cases where consensus cannot be reached between the teammembers.
While the APCs all vote for the PTL of a team, in many other casesonly thecore reviewer team will be consulted on policy decisionsfor the team. Anyone may review any patch for any OpenStackproject. After someone demonstrates that they have a good grasp of thetechnical issues of a project, that they provide useful feedback onreviews, and that they understand the direction the project is going,they may be invited to become a member of the core review team. Unlikein many other communities, this status does not grant them the rightto submit code without having it reviewed. Rather, it asks them tocommit to reviewing code written by other contributors, and toparticipate in team decision-making discussions. Asking someone tobecome a member of the core review team is a strong indication oftrust.
The Technical Committee (TC) is responsible for managing thedevelopment of OpenStack as a whole. The 13 members of the TechnicalCommittee are directly elected by APCs from all project teams. Eachmember serves a term of two development cycles (roughly 1 year), withthe elections split so that only about half of the members’ termsexpire at any time, to ensure continuity. The TC establishes overallpolicies, such as the criteria for adding new project teams, thedeprecation policy for Python 2, testing requirements, etc.
All elections for PTL or TC members usehttps://civs.cs.cornell.edu torun aCondorcet election. This system was selected because itemphasizes consensus candidates over strict popularity.
The OpenStack contributor community relies on 3 primary tools fordiscussion: theopenstack-dev mailing list,a gerrit code review instance athttps://review.openstack.org, and aset ofOpenStack-specific IRC channels on Freenode. There are a few teamswhose contributors are based primarily in China, and they have troubleaccessing IRC. Those teams tend to use alternative platforms such asWeChat, instead.
The tool used for discussing any given decision will vary based on itsweight and impact. Everyone is encouraged to use either the mailinglist or gerrit to support asynchronous discussion across a wider rangeof timezones and firewalls, especially for publicizing finaldecisions for the rest of the community.
Policy decisions limited to a single team are usually made by the corereview team for a project, and the policies and decision processes mayvary between teams. Some groups write down their team policies intheir documentation repository, and use the code review tool (gerrit)to vote on them. Some teams discuss policies on IRC, either ad hoc orduring a regularly scheduled meeting, and make decisions there. Someteams use the mailing list for those discussions. The PTL for the teamis responsible for ensuring the discussion is managed and the outcomeis communicated (either by doing so directly or ensuring that the taskis delegated to someone else).
All team policy decisions need to be compatible with the overallpolicies set by the Technical Committee. Because the TC tends to makebroader governance decisions that apply to the entire contributorcommunity, the process for discussing and voting on those decisions isdescribed more formally, including specifying the number of votesneeded to pass and the minimum length of time required fordiscussion. For example, most motions require 1/3 of the members (5)to pass and must stay open at least 3 days after receiving sufficientvotes to pass, ensuring that there is time for dissent to beregistered. See theTechnical Committee Charterandhouse rulesfor more details.
Significant design decisions are usually discussed by reviewing aspecification document, somewhatsimilar to a PEP, that covers the requirements, alternatives, andimplementation details. Feedback is solicited from all contributors,and then specifications are eventually approved or rejected by membersof the core review team for a project. Some teams require only 2reviewers to approve a design, while other teams require a strongerindication of consensus before a design is approved. Each team sets adeadline for approving specifications within each development cycle, to encouragecontributors to work out designs for significant new features earlyand avoid risk from changes late in the cycle.
Smaller technical decisions are typically made by reviewing thepatch(es) needed to implement the change. Anyone may review any patchand provide technical feedback, but ultimately two core reviewers fora team are needed to approve most changes (exceptions are often madefor trivial changes such as typos or for fixes that unblock the CIgating system).
Controversial, or merely complicated, decisions frequently expandoutside of specification reviews to mailing list discussions. Theyoften also result in discussions at one of the regularly scheduledin-person community gatherings. Because many members of the communitycannot attend these events, the discussions are summarized and finaldecisions are made using on-line tools as much as possible.
The PTL is responsible for deciding when consensus has been reachedfor decisions that affect a single team, and to make a final call inrare cases where consensus has not been reached and a decisionabsolutely needs to be made. The TC acts as a similar decision-makinggroup of last resort for cases where issuesbetween teams cannot beresolved in another way. Such escalation of decision-making ends upbeing rarely necessary, because the contributors directly involvedgenerally prefer to come to a consensual agreement rather thanescalate the decision to others.
OpenStack has a major release about every 6 months. These arecoordinated date-based releases, which include the work finished up tothat point in time in all of the member projects. Some project teamsrelease more often than every 6 months (this is especially true forteams building libraries consumed by other teams). Those smallerreleases tend to be produced when there is content (new features orbug fixes) to justify them.
The schedule for each development cycle, with deadlines and a finalrelease date, is proposed by the release management team, incoordination with the Foundation staff (releases are generally alignedwith the calendar of in-person events), and then the community has anopportunity to provide feedback before the final dates are set.
Decisions about priorities for each development cycle are made at theteam level and the TC level. Core review teams prioritize internalwork, such as fixing bugs and implementing new features. The TCselectscommunity goals, whichusually require some amount of work from all teams. Agreeing to thesepriorities at the start of each cycle helps the teams coordinate theirwork, which is especially important because the implementation willrequire reviews from multiple team members.
Over the last 8 years the number of OpenStack project teams has grownfrom 2 to 63. The makeup of the Technical Committee has changed toaccommodate that growth. Originally the TC was made up of PTLs, but asthe membership grew it became impractical for the group to functioneffectively.
The community also used to be organized around “program areas” ratherthan project teams. A program area covered a feature set, such asgathering telemetry or managing block storage. This organizationfailed when multiple teams of people wanted to work on the samefeature set using different solutions. Organizing teams around thecode they deliver allows different teams to have differentinterpretations of the same requirements. For example, there are nowseveral teams working on different deployment tools.
The governance structure is documented in theMain Governance Documentwithin theJupyter Governance repo.
The effective governance process grows organically over time as the needs ofthe project evolve. Formal changes to the Governance Document are submitted viaPull Request, with an open period for comments. After the open period, aSteering Council may call for a vote to ratify the PR changes. Acceptancerequires a minimum of 80% of the Steering Council to vote and at least 2/3 ofthe vote must be positive. The BDFL can act alone to accept or reject changesor override the Steering Council decision; though this would be an extremelyrare event.
The key people in Jupyter’s Governance are the BDFL, Fernando Perez, and theSteering Council. Contributors can be given a special status of core contributor.Some may also be Institutional Contributors, who are individuals who contributeto the project as part of their official duties at an Institutional Partner.
Fernando Perez, the project founder, is the current and first BDFL. The BDFLmay serve as long as desired. TheBDFL succession planis described in the Main Governance Document. In summary, the BDFL may appointthe next BDFL. As a courtesy, it is expected that the BDFL will consult with theSteering Council. In the event that the BDFL can not appoint a successor, theSteering Council will recommend one.
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 orsubproject.An existing core contributor typically recommends someone be givencore contributor rights by gathering consensus from project leads, who areexperienced core contributors as listed in the README of the project repo.
To be recommended and invited as a Steering Council member, an individual mustbe a Project Contributor who has produced contributions that are substantial inquality and quantity, and sustained over at least one year. Potential CouncilMembers are nominated by existing Council members and voted upon by theexisting Council after asking if the potential Member is interested and willingto serve in that capacity.
Project Jupyter is made up of a number of GitHub organizations and subprojectswithin those organizations. Primary work happens via GitHub issues and pullrequests. Approving a pull request by any team member allows it to be mergedwithout further process. All merged pull requests end up in the next stablerelease of a subproject.
There is a weekly, public Project-wide meeting that is recorded and posted onYouTube. Some larger GitHub organizations, which are subprojects ofProject Jupyter, e.g. JupyterLab and JupyterHub, mayhave additional public team meetings on a weekly or monthly schedule.Discussions occur on Gitter, the Jupyter mailing list, and most frequently anopen issue and/or pull request on GitHub.
The foundations of Project Jupyter’s governance are:
During the everyday project activities, Steering Council members participate inall discussions, code review and other project activities as peers with allother Contributors and the Community. In these everyday activities,Council Members do not have any special power or privilege through theirmembership on the Council. However, it is expected that because of the qualityand quantity of their contributions and their expert knowledge of theProject Software and Services that Council Members will provide useful guidance,both technical and in terms of project direction, to potentially lessexperienced contributors.
For controversial issues, the contributor community works together to refinepotential solutions, iterate as necessary, and build consensus by sharinginformation and views constructively and openly. The Steering Council maymake decisions when regular community discussion doesn’t produce consensuson an issue in a reasonable time frame.
Rarely, if ever, is voting done for technical decisions.
For other Project issues, the Steering Council may call for a vote for adecision via a Governance PR or email proposal. Acceptancerequires a minimum of 80% of the Steering Council to vote and at least 2/3 ofthe vote must be positive.
The BDFL can act alone to accept or reject changes or override the SteeringCouncil decision; though this would be an extremely rare event. As Benevolent,the BDFL, in practice chooses to defer that authority to the consensus of thecommunity discussion channels and the Steering Council.
Since Project Jupyter has a number of projects, not just a single project, therelease planning is largely driven by the core contributors of a project.
The process has remained consistent over time, and the approach has served uswell. Moving forward The Project leadership will consist of a BDFL andSteering Council. This governance model was a formalization of whatthe Project was doing (prior to 2015 when the Main Governance Document wasadopted by the Steering Council), rather than a change in direction.
The governance structure is documented inOrganization of the Django Project.
The project recognizes three kinds of contributors. Members of thecore team, the Technical Board, and Fellows. Regular core committersno longer exercise their “commit bit”, instead they rely on pullrequests being reviewed and accepted. The Technical Board steerstechnical choices. Fellows are hired contractors who triage newtickets, review and merge patches from the committers and community,including non-trivial ones.
Core team members are added by nomination and vote within the coreteam, with technical board veto (so far not exercised). Technicalboard is elected by and from the core team membership every 18 months(every major Django release). Sub-teams within the core team areself-selected by interest.
Most day-to-day decisions are made by Fellows and sometimes other activecore team members.
The core team votes on new members which requires a 4/5 majority ofvotes cast, no quorum requirement. The Technical Board has veto power.This power was never exercised
The Technical Board occasionally approves DjangoEnhancement Proposals (DEPs) but those are rare. The DEP process isroughly modeled after PEPs and documented inDEP 1.DEPs are mostly used to design major new features, but also forinformation on general guidelines and process.
An idea for a DEP should be first publicly vetted on thedjango-developers mailing list. After it was roughly validated, theauthor forms a team with three roles:
The DEP’s draft is submitted, assigned a number, and discussed. Authorscollect feedback and steer discussion as they see fit. Suggested venuesto avoid endless open-ended discussions are: separate mailing lists,Wiki pages, working off of pull requests on the DEP.
Once the feedback round is over, the shepherd asks the Technical Boardfor review and pronouncement. The Board can rule on a DEP as a team ordesignate one member to review and decide.
In any case where consensus can’t be reached, the Technical Board hasfinal say. This was never exercised.
The main difference is that the entire workflow is based on pullrequests rather than e-mail. They are pronounced upon by the TechnicalBoard. They need to have the key roles identified before submissionand throughout the process. Theshepherd role exists to guide a DEPto completion without engaging the Technical Board.
Those changes to the process make it more distributed and workable ina governance model without a BDFL.
Releases are done on a fixed time-based schedule, with a major versionevery 18 months. With paid Fellows to ensure the necessary work getsdown, on-time releases are routine.
Django originally had two BDFLs: Jacob Kaplan-Moss and Adrian Holovaty.They retired (Adrian’s post,Jacob’s post)9 years into the project’s history. Following the stepping down,the DEP process was defined.
The governance structure is not externally documented besides theCONTRIBUTING.mddocument in the main TypeScript repository.
There is a formal design team and a release management team working atMicrosoft. The main person behind the project is currently AndersHejlsberg as some of the original members of the team have left thecompany.
Microsoft, where the project is developed, has a strong planning cultureso development roadmaps are released long in advanced, notes fromdesign discussions held at Microsoft get published quickly and meetingsare sometimes broadcast using Skype.
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 discussionover social media (Twitter) as well.
Hejlsberg is the central figure of the project in terms of languagedesign, synthesizing community needs into a cohesive whole. There isno formal process to externally contribute to the design of thelanguage.
The TypeScript team filters through and integrates communitysuggestions. The main advantages of this setup are that there isstrong and consistent design with dependable scheduling andexecution. While there is transparency of intentions and plans, thedisadvantage of this model is that community involvement is limitedto pull requests and suggestions.
Microsoft determines the release schedule, communicates dates andfeatures well in advance. Nightly builds are usually stable (witha significant portion of users on this release form).
Versioned releases are done every 1 - 3 months, with a roadmap availableon GitHub.
TypeScript is likely the first notable project by Microsoft developedfully in the open (versus source-available).
Open-sourcing of TypeScript by Microsoft was a planned feature from theinception of the project. Before the first open release was made, thelanguage was driven fully by needs identified by the original teams andthe early in-house users. The initial open-sourcing happened viathe now-defunct Microsoft CodePlex platform. It didn’t havea well-defined routine of accepting external contributions. Communityengagement rose significantly after the project got moved.
The Astropy Project team’s responsibilities are spread over many differentroles[1], though frequently a person will have several roles.
The main body overseeing the Astropy Project is the AstropyCoordination Committee (CoCo) . Its key roles are dealing with anyfinancial issues, approving new packages wanting to join the AstropyProject, approving or rejectingAstropy Proposals for Enhancement(APEs)[2], and generally anything that’s “leadership”-orientedor time-sensitive. As of this writing, the committee has four members,and might grow or shrink as the demands on the committee change.
The Astropy Project includes thecore Astropy package and otheraffiliated packages. For the sake of simplicity, we will avoiddiscussing affiliated packages, which can have their own rules.Therefore, everything below will concern the core Astropy package.
The core Astropy package is organized assub-packages. Each sub-packagehas an officialmaintainer as well as one or moredeputies, who areresponsible for ensuring code is reviewed and generally architecting thesubpackage. Code-level decisions are therefore made in GitHub issues orpull requests (PRs), usually on the basis of consensus, moderated by themaintainer and deputies of that sub-package.
When there is specific disagreement, majority vote of those who are involvedin the discussion (e.g. PR) determines the winner, with the CoCo called onto break ties or mediate disagreements.
Non-code decisions (like sprint scheduling, bugfix release timing, etc)are usually announced on theastropy-dev mailing list[3] witha vote-by-message format, or a “if there are no objections”-style messagefor highly uncontroversial items. In general, on astropy-dev the expectationis a concrete proposal which other members are welcome to comment or vote on.
Voting usually involves either using the +1/-1 format on GitHub or theastropy-dev mailing list. There, any interested person can vote regardlessof their official role in the project, or lack thereof. Furthermore, thereis no veto mechanism for the CoCo to override decisions of the majority.
Simpler controversial decisions are generally discussed on the astropy-devmailing list[3], and after a reasonable time either there isa clear consensus/compromise (this happens most of the time), or the CoComakes a decision to avoid stalling.
More complicated decisions follow the APE process, which is modeled after thePEP process. Here, the CoCo makes the final decision after a discussionperiod, open to everyone, has passed. Generally the CoCo would follow theconsensus or majority will.
The Project has anOmbudsperson who ensures there is an alternate contactfor sensitive issues, such as Code of Conduct violations, independentfrom the Coordination Committee. In practice, the CoCo, the Communityengagement coordinators and the Ombudsperson would work together privatelyto try and communicate with the violator to address the situation.
The major release timing is on a fixed schedule (every 6 months); whateveris in at that time goes in.
The CoCo and the “Open Development” ethos came from the inception of theProject after a series of votes by interested Python-oriented astronomersand allied software engineers. The core results of that initial discussionwere embodied in theVision for Astropy document[4].
The existence of the formal roles and most of the rest of the abovecame as evolutionary steps as the community grew larger, each followingeither the APE process, or the regular process of a proposal being broughtup for discussion and vote in astropy-dev[3]. In general allevolved as sort of ratification of already-existing practices, only afterthey were first tested in the wild.
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 meansthat there’s no sense of a dictator who enforces their will, while stillgiving clear points of contact for external organizations that areleery of fully-democratic governance models.
Despite the selection process for “relevant projects” described above,it is worthwhile considering how companies that are held financiallyaccountable for their decisions go about making them. This is notintended as a readily-usable model for Python, but as additional insightthat may influence the final design or selection.
This section is not taken from any official documentation, but has beenabstracted by Steve Dower, a current Microsoft employee, to reflect theprocesses that are most applicable to individual projects in theengineering departments. Role titles are used (and defined) rather thanidentifying specific individuals, and all names are examples and shouldnot be taken as a precise description of the company at any particulartime in history.
This is also highly simplified and idealised. There are plenty ofunhealthy teams that do not look like this description, and thosetypically have high attrition (people leave the team more frequentlythan other teams). Teams that retain their people are usually closer tothe model described here, but ultimately everything involving humans isimperfect and Microsoft is no exception.
Microsoft has a hierarchy that ultimately reports to the CEO. Below theCEO are a number of organisations, some of which are focused onengineering projects (as opposed to sales, marketing or other functions).These engineering organisations roughly break down into significantproduct families - for example, there has been a “Windows group”, an“Xbox group”, and a “server and tools group”. These are typically led byExecutive Vice Presidents (EVPs), who report to the CEO.
Below each EVP are manyCorporate Vice Presidents (CVPs), each of whichis responsible for one or more products. This level is where the hierarchybecomes relevant for the purposes of this PEP - the CEO and EVPs arerarely involved in most decision processes, but set the direction underwhich CVPs make decisions.
Each product under a CVP has a team consisting ofProgram Managers(PMs) andEngineering Managers. Engineering Managers have teams ofengineers who are largely uninvolved in decision making, though may beused as specialists in some cases. For the rest of this section,Engineering refers to anyone from the engineering team who iscontributing with a technical-focus, andPM refers to anyone from theprogram management team contributing with a customer-focus. Afterdecisions are made, Engineering does the implementation and testing work,and PM validates with users that their problem has been solved.
(This is actually a huge simplification, to the point where some peoplein these roles are offended by this characterisation. In reality, mostpeople in PM or Engineering do work that crosses the boundary betweenthe two roles, and so they should be treated as a term describing thework that somebody is doing in the moment, rather than an identifier orrestriction for a person.)
Teams generally represent a feature, while the CVP represents a product.For example, Visual Studio Code has a CVP who is ultimately responsiblefor decisions about that product and its overall direction (in the contextset by their EVP). But many teams contribute features into Visual StudioCode.
For complete clarity, the CEO, EVPs, and CVPs do not ever directlymodify source code. Their entire role is to provide direction forwhoever is immediately below them and to adjudicate on controversialdecisions.
Changes to product code that are not visible to external users are madesolely by Engineering. Individual engineers will be assigned tasks by adesignated engineering manager, or may self-assign. Promotion toincreasingly senior positions generally reflects trust in theindividual’s decision-making ability, and more senior engineers aretrusted to make decisions with less validation from the rest of the team.Most bugs are covered by this process (that is, fixing a user-visibleproblem without changing the intended experience is an Engineeringdecision).
Decisions affecting users of a particular feature are made by the PMteam for that feature. They will use whatever data sources available toidentify an issue, experiment with alternatives, and ultimately preparea design document. Senior members from PM and Engineering will reviewdesigns to clarify the details, and ultimately an artifact is createdthat the feature team agrees on. Engineering will use this artifact toimplement the work, and PM will later use this artifact to validate thatthe original issue has been resolved.
Senior members of Engineering and PM teams for a feature are expected tomake decisions in the spirit of the direction set by their CVP. Teamshave regular meetings with their CVP to discuss recent decisions andensure consistency. Decisions that are not obviously in line with CVPexpectations are escalated to the controversial process.
When decisions require cross-team coordination, or do not obviouslyalign 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 andremoving significant features (or on a short timeframe), or changes thatrequire quick releases.
In general, CVPs are not intimately familiar with all aspects of thefeature team’s work. As a result, the feature team must provide both arecommendation and sufficient context for the decision that the CVP candecidewithout additional knowledge. Most of the time, the firstattempt results in a series of questions from the CVP, which the teamwill research, answer and attempt the decision again at a later date.
Common questions asked by CVPs are:
CVPs are expected to have a strong understanding of the entire field, sothat they can evaluate some questions for themselves, such as:
Decisions made by CVPs are generally arbitrary and final, though theytypically will provide their rationale.
Releases involve coordinating a number of feature teams, and so rarelyattempt to include input from all teams. A schedule will be determinedbased on broader ecosystem needs, such as planned events/conferences oropportunities to take advantage of media attention.
Teams are informed of the release date, the theme of the release, andmake their own plans around it following the above decision makingprocess. Changing the release date is considered a controversialdecision.
Thank you to Alex Crichton from the Rust team for an extensive explanation of how thecore team governs the project.
Jeremy Stanley, Chris Dent, Julia Kreger, Sean McGinnis, Emmet Hikory,and Thierry Carrez contributed to the OpenStack section.
The Project Jupyter Steering Council created the Main Governance Document forProject Jupyter, and Carol Willing summarized the key points of that documentfor the Jupyter section.
Thank you to Carl Meyer from the Django team for explanation how theirproject’s governance is set up.
The TypeScript and Swift sections were created after conversations withJoe Pamer and Vlad Matveev. Thanks!
Answers about the Astropy project were kindly contributed, in significantdetail, by Erik Tollerud and reviewed by other members of the project.
The following set of questions was used as a template to guide evaluation andinteraction with the surveyed projects:
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-8002.rst
Last modified:2025-02-01 08:55:40 GMT