The Django Project is managed by a team of volunteers pursuing three goals:
\nDriving 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\nDjango Code of Conduct.
The Django Project isn’t a legal entity. The Django Software Foundation, a\nnon-profit organization, handles financial and legal matters related to the\nDjango Project. Other than that, the Django Software Foundation lets the\nDjango Project manage the development of the Django framework, its ecosystem\nand its community.
\nMergers are a small set of people who merge pull requests to the Django Git\nrepository.
\nMergers hold the following prerogatives:
\nMerging any pull request which constitutes a minor change (small enough\nnot to require the use of the DEP process). A Merger must not merge a\nchange primarily authored by that Merger, unless the pull request has been\napproved by:
\nanother Merger,
a technical board member,
a member of the triage & review team, or
a member of the security team.
Initiating discussion of a minor change in the appropriate venue, and request\nthat other Mergers refrain from merging it while discussion proceeds.
Requesting a vote of the technical board regarding any minor change if, in\nthe Merger’s opinion, discussion has failed to reach a consensus.
Requesting a vote of the technical board when a major change (significant\nenough to require the use of the DEP process) reaches one of its\nimplementation milestones and is intended to merge.
The technical board selects Mergers as necessary to maintain their number\nat a minimum of three, in order to spread the workload and avoid over-burdening\nor burning out any individual Merger. There is no upper limit to the number of\nMergers.
\nIt’s not a requirement that a Merger is also a Django Fellow, but the Django\nSoftware Foundation has the power to use funding of Fellow positions as a way\nto make the role of Merger sustainable.
\nThe following restrictions apply to the role of Merger:
\nA person must not simultaneously serve as a member of the technical board. If\na Merger is elected to the technical board, they shall cease to be a Merger\nimmediately upon taking up membership in the technical board.
A person may serve in the roles of Releaser and Merger simultaneously.
The selection process, when a vacancy occurs or when the technical board deems\nit necessary to select additional persons for such a role, occur as follows:
\nAny member in good standing of an appropriate discussion venue, or the Django\nSoftware Foundation board acting with the input of the DSF’s Fellowship\ncommittee, may suggest a person for consideration.
The technical board considers the suggestions put forth, and then any member\nof the technical board formally nominates a candidate for the role.
The technical board votes on nominees.
Mergers may resign their role at any time, but should endeavor to provide some\nadvance notice in order to allow the selection of a replacement. Termination of\nthe contract of a Django Fellow by the Django Software Foundation temporarily\nsuspends that person’s Merger role until such time as the technical board can\nvote on their nomination.
\nOtherwise, a Merger may be removed by:
\nBecoming disqualified due to election to the technical board.
Becoming disqualified due to actions taken by the Code of Conduct committee\nof the Django Software Foundation.
A vote of the technical board.
Releasers are a small set of people who have the authority to upload packaged\nreleases of Django to the Python Package Index, and to the\ndjangoproject.com website.
\nReleasers build Django releases and\nupload them to the Python Package Index, and to the djangoproject.com\nwebsite.
\nThe technical board selects Releasers as necessary to maintain their number\nat a minimum of three, in order to spread the workload and avoid over-burdening\nor burning out any individual Releaser. There is no upper limit to the number\nof Releasers.
\nIt’s not a requirement that a Releaser is also a Django Fellow, but the Django\nSoftware Foundation has the power to use funding of Fellow positions as a way\nto make the role of Releaser sustainable.
\nA person may serve in the roles of Releaser and Merger simultaneously.
\nThe selection process, when a vacancy occurs or when the technical board deems\nit necessary to select additional persons for such a role, occur as follows:
\nAny member in good standing of an appropriate discussion venue, or the Django\nSoftware Foundation board acting with the input of the DSF’s Fellowship\ncommittee, may suggest a person for consideration.
The technical board considers the suggestions put forth, and then any member\nof the technical board formally nominates a candidate for the role.
The technical board votes on nominees.
Releasers may resign their role at any time, but should endeavor to provide\nsome advance notice in order to allow the selection of a replacement.\nTermination of the contract of a Django Fellow by the Django Software\nFoundation temporarily suspends that person’s Releaser role until such time as\nthe technical board can vote on their nomination.
\nOtherwise, a Releaser may be removed by:
\nBecoming disqualified due to actions taken by the Code of Conduct committee\nof the Django Software Foundation.
A vote of the technical board.
The technical board is a group of experienced contributors who:
\nprovide oversight of Django’s development and release process,
assist in setting the direction of feature development and releases,
take part in filling certain roles, and
have a tie-breaking vote when other decision-making processes fail.
Their main concern is to maintain the quality and stability of the Django Web\nFramework.
\nThe technical board holds the following prerogatives:
\nMaking a binding decision regarding any question of a technical change to\nDjango.
Vetoing the merging of any particular piece of code into Django or ordering\nthe reversion of any particular merge or commit.
Announcing calls for proposals and ideas for the future technical direction\nof Django.
Setting and adjusting the schedule of releases of Django.
Selecting and removing mergers and releasers.
Participating in the removal of members of the technical board, when deemed\nappropriate.
Calling elections of the technical board outside of those which are\nautomatically triggered, at times when the technical board deems an election\nis appropriate.
Participating in modifying Django’s governance (see\nChanging the organization).
Declining to vote on a matter the technical board feels is unripe for a\nbinding decision, or which the technical board feels is outside the scope of\nits powers.
Taking charge of the governance of other technical teams within the Django\nopen-source project, and governing those teams accordingly.
The technical board is an elected group of five experienced contributors\nwho demonstrate:
\nA history of technical contributions to Django or the Django ecosystem. This\nhistory must begin at least 18 months prior to the individual’s candidacy for\nthe technical board.
A history of participation in Django’s development outside of contributions\nmerged to the Django Git repository. This may include, but is not\nrestricted to:
\nParticipation in discussions on the django-developers mailing list or\nthe Django forum.
Reviewing and offering feedback on pull requests in the Django source-code\nrepository.
Assisting in triage and management of the Django bug tracker.
A history of recent engagement with the direction and development of Django.\nSuch engagement must have occurred within a period of no more than two years\nprior to the individual’s candidacy for the technical board.
A new board is elected after each release cycle of Django. The election process\nworks as follows:
\nThe technical board direct one of its members to notify the Secretary of the\nDjango Software Foundation, in writing, of the triggering of the election,\nand the condition which triggered it. The Secretary post to the appropriate\nvenue – the django-developers mailing list and the Django forum to\nannounce the election and its timeline.
As soon as the election is announced, the DSF Board begin a period of\nvoter registration. All individual members of the DSF are automatically\nregistered and need not explicitly register. All other persons who believe\nthemselves eligible to vote, but who have not yet registered to vote, may\nmake an application to the DSF Board for voting privileges. The voter\nregistration form and roll of voters is maintained by the DSF Board. The DSF\nBoard may challenge and reject the registration of voters it believes are\nregistering in bad faith or who it believes have falsified their\nqualifications or are otherwise unqualified.
Registration of voters close one week after the announcement of the\nelection. At that point, registration of candidates begin. Any qualified\nperson may register as a candidate. The candidate registration form and\nroster of candidates are maintained by the DSF Board, and candidates must\nprovide evidence of their qualifications as part of registration. The DSF\nBoard may challenge and reject the registration of candidates it believes do\nnot meet the qualifications of members of the Technical Board, or who it\nbelieves are registering in bad faith.
Registration of candidates close one week after it has opened. One week\nafter registration of candidates closes, the Secretary of the DSF publish\nthe roster of candidates to the django-developers mailing list and the\nDjango forum, and the election begin. The DSF Board provide a voting form\naccessible to registered voters, and is the custodian of the votes.
Voting is by secret ballot containing the roster of candidates, and any\nrelevant materials regarding the candidates, in a randomized order. Each\nvoter may vote for up to five candidates on the ballot.
The election conclude one week after it begins. The DSF Board then tally the\nvotes and produce a summary, including the total number of votes cast and\nthe number received by each candidate. This summary is ratified by a\nmajority vote of the DSF Board, then posted by the Secretary of the DSF to\nthe django-developers mailing list and the Django Forum. The five\ncandidates with the highest vote totals are immediately become the new\ntechnical board.
A member of the technical board may be removed by:
\nBecoming disqualified due to actions taken by the Code of Conduct committee\nof the Django Software Foundation.
Determining that they did not possess the qualifications of a member of the\ntechnical board. This determination must be made jointly by the other members\nof the technical board, and the DSF Board. A valid determination of\nineligibility requires that all other members of the technical board and all\nmembers of the DSF Board vote who can vote on the issue (the affected person,\nif a DSF Board member, must not vote) vote «yes» on a motion that the person\nin question is ineligible.
Changes to this document require the use of the DEP process, with\nmodifications described in DEP 0010.
\n