mirror of
https://github.com/django/django.git
synced 2024-12-23 01:25:58 +00:00
Introduced a technical board.
Extended the scope of the core team a bit (depending on your current perspective on that scope).
This commit is contained in:
parent
e9fde1c7ec
commit
4a475ce1c8
@ -310,7 +310,9 @@ you can contribute:
|
||||
* **Community:**
|
||||
:doc:`How to get involved <internals/contributing/index>` |
|
||||
:doc:`The release process <internals/release-process>` |
|
||||
:doc:`Team organization <internals/organization>` |
|
||||
:doc:`Meet the team <internals/team>` |
|
||||
:doc:`Current roles <internals/roles>` |
|
||||
:doc:`The Django source code repository <internals/git>` |
|
||||
:doc:`Security policies <internals/security>` |
|
||||
:doc:`Mailing lists <internals/mailing-lists>`
|
||||
|
@ -7,19 +7,6 @@ interested in knowing how code gets committed into Django core. If you're a
|
||||
community member who wants to contribute code to Django, have a look at
|
||||
:doc:`writing-code/working-with-git` instead.
|
||||
|
||||
Commit access
|
||||
-------------
|
||||
|
||||
Core developers are people who have a long history of contributions to
|
||||
Django's codebase, a solid track record of being polite and helpful on the
|
||||
mailing lists, and a proven desire to dedicate serious time to Django's
|
||||
development. The bar is high for full commit access.
|
||||
|
||||
Decisions on new committers will follow the process explained in
|
||||
:ref:`how-we-make-decisions`. To request commit access, please contact an
|
||||
existing committer privately. Public requests for commit access are potential
|
||||
flame-war starters, and will simply be ignored.
|
||||
|
||||
.. _handling-pull-requests:
|
||||
|
||||
Handling pull requests
|
||||
|
@ -18,7 +18,9 @@ the hood".
|
||||
|
||||
contributing/index
|
||||
mailing-lists
|
||||
organization
|
||||
team
|
||||
roles
|
||||
security
|
||||
release-process
|
||||
deprecation
|
||||
|
193
docs/internals/organization.txt
Normal file
193
docs/internals/organization.txt
Normal file
@ -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.
|
10
docs/internals/roles.txt
Normal file
10
docs/internals/roles.txt
Normal file
@ -0,0 +1,10 @@
|
||||
=====
|
||||
Roles
|
||||
=====
|
||||
|
||||
.. _technical-board-list:
|
||||
|
||||
Technical board
|
||||
===============
|
||||
|
||||
The first technical board hasn't been elected yet.
|
@ -2,6 +2,8 @@
|
||||
Django team
|
||||
===========
|
||||
|
||||
.. _original-team-list:
|
||||
|
||||
The original team
|
||||
=================
|
||||
|
||||
@ -55,6 +57,8 @@ Journal-World`_ of Lawrence, Kansas, USA.
|
||||
.. _heroku: http://heroku.com/
|
||||
.. _Rdio: http://rdio.com
|
||||
|
||||
.. _core-team-list:
|
||||
|
||||
The current team
|
||||
================
|
||||
|
||||
@ -551,8 +555,8 @@ Baptiste Mispelon
|
||||
.. _Solid Links: http://solidlinks.nl/
|
||||
.. _Erik's Pony Checkup: http://ponycheckup.com/
|
||||
|
||||
Retired team members
|
||||
====================
|
||||
Past team members
|
||||
=================
|
||||
|
||||
Georg "Hugo" Bauer
|
||||
Georg created Django's internationalization system, managed i18n
|
||||
|
Loading…
Reference in New Issue
Block a user