|
|
|
|
@ -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