|
|
@@ -0,0 +1,193 @@
|
|
|
+==================================
|
|
|
+Organization of the Django Project
|
|
|
+==================================
|
|
|
+
|
|
|
+Principles
|
|
|
+==========
|
|
|
+
|
|
|
+The Django Project is managed by a team of volunteers pursuing three goals:
|
|
|
+
|
|
|
+- Driving the development of the Django Web Framework,
|
|
|
+- Fostering the ecosystem of Django-related software,
|
|
|
+- Leading the Django community in accordance with the values described in the
|
|
|
+ `Django Code of Conduct`_.
|
|
|
+
|
|
|
+The Django Project isn't a legal entity. The `Django Software Foundation`_, a
|
|
|
+non-profit organization, handles financial and legal matters related to the
|
|
|
+Django Project. Other than that, the Django Software Foundation lets the
|
|
|
+Django Project manage the development of the Django framework, its ecosystem
|
|
|
+and its community.
|
|
|
+
|
|
|
+.. _Django Code of Conduct: https://www.djangoproject.com/conduct/
|
|
|
+.. _Django Software Foundation: https://www.djangoproject.com/foundation/
|
|
|
+
|
|
|
+Since 2014, the Django Project is an aristocracy_. The Django core team makes
|
|
|
+the decisions, elects its technical board, and nominates new team members.
|
|
|
+While it holds decision power in theory, it aims at using it as rarely as
|
|
|
+possible in practice. Rough consensus should be the norm and formal voting an
|
|
|
+exception.
|
|
|
+
|
|
|
+Until 2014, the Django Project was a benevolent_ dictatorship_.
|
|
|
+
|
|
|
+.. _aristocracy: http://en.wikipedia.org/wiki/Aristocracy
|
|
|
+.. _benevolent: http://www.holovaty.com/writing/bdfls-retiring/
|
|
|
+.. _dictatorship: http://jacobian.org/writing/retiring-as-bdfls/
|
|
|
+
|
|
|
+Core team
|
|
|
+=========
|
|
|
+
|
|
|
+Role
|
|
|
+----
|
|
|
+
|
|
|
+The core team is the group of trusted volunteers who manage the Django
|
|
|
+Project. They assume many roles required to achieve the project's goals,
|
|
|
+especially those that require a high level of trust. They make the decisions
|
|
|
+that shape the future of the project.
|
|
|
+
|
|
|
+Core team members are expected to act as role models for the community and
|
|
|
+custodians of the project, on behalf of the community and all those who rely
|
|
|
+on Django.
|
|
|
+
|
|
|
+They will intervene, where necessary, in online discussions or at official
|
|
|
+Django events on the rare occasions that a situation arises that requires
|
|
|
+intervention.
|
|
|
+
|
|
|
+They have authority over the Django Project infrastructure, including the
|
|
|
+Django Project website itself, the Django GitHub organization and
|
|
|
+repositories, the Trac bug tracker, the mailing lists, IRC channels, etc.
|
|
|
+
|
|
|
+Prerogatives
|
|
|
+------------
|
|
|
+
|
|
|
+Core team members may participate in formal votes, typically to nominate new
|
|
|
+team members and to elect the technical board.
|
|
|
+
|
|
|
+Some contributions don't require commit access. Depending on the reasons why a
|
|
|
+contributor joins the team, they may or may not have commit permissions to the
|
|
|
+Django code repository.
|
|
|
+
|
|
|
+However, should the need arise, any team member may ask for commit access by
|
|
|
+writing to the core team's mailing list. Access will be granted unless the
|
|
|
+person withdraws their request or the technical board vetoes the proposal.
|
|
|
+
|
|
|
+Core team members who have commit access are referred to as "committers" or
|
|
|
+"core developers".
|
|
|
+
|
|
|
+Other permissions, such as access to the servers, are granted to those who
|
|
|
+need them through the same process.
|
|
|
+
|
|
|
+Membership
|
|
|
+----------
|
|
|
+
|
|
|
+The core team finds its origins with the :ref:`four people
|
|
|
+<original-team-list>` who created Django. It has grown to :ref:`a few dozen
|
|
|
+people <core-team-list>` by co-opting volunteers who demonstrate:
|
|
|
+
|
|
|
+- a good grasp of the philosophy of the Django Project
|
|
|
+- a solid track record of being constructive and helpful
|
|
|
+- significant contributions to the project's goals, in any form
|
|
|
+- willingness to dedicate some time to improving Django
|
|
|
+
|
|
|
+As the project matures, contributions go way beyond code. Here's an incomplete
|
|
|
+list of areas where contributions may be considered for joining the core team,
|
|
|
+in no particular order:
|
|
|
+
|
|
|
+- Working on community management and outreach
|
|
|
+- Providing support on the mailing-lists and on IRC
|
|
|
+- Triaging tickets
|
|
|
+- Writing patches (code, docs, or tests)
|
|
|
+- Reviewing patches (code, docs, or tests)
|
|
|
+- Participating in design decisions
|
|
|
+- Providing expertise in a particular domain (security, i18n, etc.)
|
|
|
+- Managing the continuous integration infrastructure
|
|
|
+- Managing the servers (website, tracker, documentation, etc.)
|
|
|
+- Maintaining related projects (djangoproject.com site, ex-contrib apps, etc.)
|
|
|
+- Creating visual designs
|
|
|
+
|
|
|
+Very few areas are reserved to core team members:
|
|
|
+
|
|
|
+- Reviewing security reports
|
|
|
+- Merging patches (code, docs, or tests)
|
|
|
+- Packaging releases
|
|
|
+
|
|
|
+Core team membership acknowledges sustained and valuable efforts that align
|
|
|
+well with the philosophy and the goals of the Django Project.
|
|
|
+
|
|
|
+It is granted by a four fifths majority of votes cast in a core team vote and
|
|
|
+no veto by the technical board.
|
|
|
+
|
|
|
+Core team members are always looking for promising contributors, teaching them
|
|
|
+how the project is managed, and submitting their names to the core team's vote
|
|
|
+when they're ready. If you would like to join the core team, you can contact a
|
|
|
+core team member privately or ask for guidance on the :ref:`Django Core
|
|
|
+Mentorship mailing-list <django-core-mentorship-mailing-list>`.
|
|
|
+
|
|
|
+There's no time limit on core team membership. However, in order to provide
|
|
|
+the general public with a reasonable idea of how many people maintain Django,
|
|
|
+core team members who have stopped contributing are encouraged to declare
|
|
|
+themselves as "past team members". Those who haven't made any non-trivial
|
|
|
+contribution in two years may be asked to move themselves to this category,
|
|
|
+and moved there if they don't respond. Past team members lose their privileges
|
|
|
+such as voting rights and commit access.
|
|
|
+
|
|
|
+Technical board
|
|
|
+===============
|
|
|
+
|
|
|
+Role
|
|
|
+----
|
|
|
+
|
|
|
+The technical board is a group of experienced and active committers who steer
|
|
|
+technical choices. Their main concern is to maintain the quality and stability
|
|
|
+of the Django Web Framework.
|
|
|
+
|
|
|
+Prerogatives
|
|
|
+------------
|
|
|
+
|
|
|
+The technical board holds two prerogatives:
|
|
|
+
|
|
|
+- Making major technical decisions when no consensus is found otherwise. This
|
|
|
+ happens on the |django-developers| mailing-list.
|
|
|
+- Veto a grant of commit access or remove commit access. This happens on the
|
|
|
+ django-core mailing-list.
|
|
|
+
|
|
|
+In both cases, the technical board is a last resort. In these matters, it
|
|
|
+fulfills a similar function to the former Benevolent Dictators For Life.
|
|
|
+
|
|
|
+When the board wants to exercise one of these prerogatives, it must hold a
|
|
|
+private, simple majority vote on the resolution. The quorum is the full
|
|
|
+committee — each member must cast a vote or abstain explicitly. Then the board
|
|
|
+communicates the result, and if possible the reasons, on the appropriate
|
|
|
+mailing-list. There's no appeal for such decisions.
|
|
|
+
|
|
|
+In addition, at its discretion, the technical board may act in an advisory
|
|
|
+capacity on non-technical decisions.
|
|
|
+
|
|
|
+Membership
|
|
|
+----------
|
|
|
+
|
|
|
+The technical board is an elected group of five committers. They're expected
|
|
|
+to be experienced but there's no formal seniority requirement. Its current
|
|
|
+composition is published :ref:`here <technical-board-list>`.
|
|
|
+
|
|
|
+A new board is elected after each major release of Django. The election
|
|
|
+process is managed by the outgoing technical board. The first election is
|
|
|
+bootstrapped by the retiring BDFLs. The election process works as follows:
|
|
|
+
|
|
|
+1. Candidates advertise their application for the technical board to the team.
|
|
|
+
|
|
|
+ They must be committers already. There's no term limit for technical board
|
|
|
+ members.
|
|
|
+
|
|
|
+2. Each team member can vote for zero to five people among the candidates.
|
|
|
+ Candidates are ranked by the total number of votes they received.
|
|
|
+
|
|
|
+ In case of a tie, the person who joined the core team earlier wins.
|
|
|
+
|
|
|
+Both the application and the voting period last between one and two weeks, at
|
|
|
+the outgoing board's discretion.
|
|
|
+
|
|
|
+Changing the organization
|
|
|
+=========================
|
|
|
+
|
|
|
+Changes to this document require a four fifths majority of votes cast in a
|
|
|
+core team vote and no veto by the technical board.
|
Aymeric Augustin