123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190 |
- ==================================
- 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/
- The Django core team makes the decisions, nominates its new members, and
- elects its technical board. 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.
- .. _core-team:
- 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
- ----------
- `Django team members <https://www.djangoproject.com/foundation/teams/>`_
- 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:
- 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.
- A new board is elected after each feature release of Django. The election
- process is managed by a returns officer nominated by the outgoing technical
- board. 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.
- .. _the technical board: https://www.djangoproject.com/foundation/teams/#technical-board-team
- 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.
|