Organisation du projet Django

Principes

Le projet Django est géré par une équipe de volontaires poursuivant trois buts :

  • Driving the development of the Django web framework,
  • la promotion des logiciels de l’écosystème Django ;
  • la conduite de la communauté Django en accord avec les valeurs décrites dans le code de conduite de Django.

Le projet Django n’est pas une entité légalement constituée. La fondation Django Software, une organisation à but non lucratif, gère les affaires financières et légales liées au projet Django. En dehors de ces domaines, la fondation laisse le projet Django gérer le développement du logiciel Django, son écosystème et sa communauté.

Mergers

Rôle

Mergers are a small set of people who merge pull requests to the Django Git repository.

Prérogatives

Mergers hold the following prerogatives:

  • Merging any pull request which constitutes a minor change (small enough not to require the use of the DEP process). A Merger must not merge a change primarily authored by that Merger, unless the pull request has been approved by:
  • Initiating discussion of a minor change in the appropriate venue, and request that other Mergers refrain from merging it while discussion proceeds.
  • Requesting a vote of the technical board regarding any minor change if, in the Merger’s opinion, discussion has failed to reach a consensus.
  • Requesting a vote of the technical board when a major change (significant enough to require the use of the DEP process) reaches one of its implementation milestones and is intended to merge.

Composition

The technical board selects Mergers as necessary to maintain their number at a minimum of three, in order to spread the workload and avoid over-burdening or burning out any individual Merger. There is no upper limit to the number of Mergers.

It’s not a requirement that a Merger is also a Django Fellow, but the Django Software Foundation has the power to use funding of Fellow positions as a way to make the role of Merger sustainable.

The following restrictions apply to the role of Merger:

  • A person must not simultaneously serve as a member of the technical board. If a Merger is elected to the technical board, they shall cease to be a Merger immediately upon taking up membership in the technical board.
  • Une personne peut serveur à la fois dans les rôles de « Releaser » et de « Merger ».

The selection process, when a vacancy occurs or when the technical board deems it necessary to select additional persons for such a role, occur as follows:

  • Any member in good standing of an appropriate discussion venue, or the Django Software Foundation board acting with the input of the DSF’s Fellowship committee, may suggest a person for consideration.
  • Le comité technique considère les suggestions proposées, puis chaque membre du comité technique nomme formellement un candidat pour le rôle.
  • Le comité technique vote sur les nominés.

Mergers may resign their role at any time, but should endeavor to provide some advance notice in order to allow the selection of a replacement. Termination of the contract of a Django Fellow by the Django Software Foundation temporarily suspends that person’s Merger role until such time as the technical board can vote on their nomination.

Otherwise, a Merger may be removed by:

  • Becoming disqualified due to election to the technical board.
  • Becoming disqualified due to actions taken by the Code of Conduct committee of the Django Software Foundation.
  • A vote of the technical board.

Releasers

Rôle

Releasers are a small set of people who have the authority to upload packaged releases of Django to the Python Package Index, and to the djangoproject.com website.

Prérogatives

Releasers build Django releases and upload them to the Python Package Index, and to the djangoproject.com website.

Composition

The technical board selects Releasers as necessary to maintain their number at a minimum of three, in order to spread the workload and avoid over-burdening or burning out any individual Releaser. There is no upper limit to the number of Releasers.

It’s not a requirement that a Releaser is also a Django Fellow, but the Django Software Foundation has the power to use funding of Fellow positions as a way to make the role of Releaser sustainable.

Une personne peut serveur à la fois dans les rôles de « Releaser » et de « Merger ».

The selection process, when a vacancy occurs or when the technical board deems it necessary to select additional persons for such a role, occur as follows:

  • Any member in good standing of an appropriate discussion venue, or the Django Software Foundation board acting with the input of the DSF’s Fellowship committee, may suggest a person for consideration.
  • Le comité technique considère les suggestions proposées, puis chaque membre du comité technique nomme formellement un candidat pour le rôle.
  • Le comité technique vote sur les nominés.

Releasers may resign their role at any time, but should endeavor to provide some advance notice in order to allow the selection of a replacement. Termination of the contract of a Django Fellow by the Django Software Foundation temporarily suspends that person’s Releaser role until such time as the technical board can vote on their nomination.

Otherwise, a Releaser may be removed by:

  • Becoming disqualified due to actions taken by the Code of Conduct committee of the Django Software Foundation.
  • A vote of the technical board.

Comité technique

Rôle

Le comité technique est un groupe de contributeurs expérimentés qui :

  • supervise le développement de Django et le processus de publication ;
  • assiste dans la conduite du développement et des publications des fonctionnalités ;
  • prend une part active dans certains rôles, et
  • procède à des votes pour départager lorsque les autres processus de décision ont échoué.

Leur préoccupation principale est de maintenir la qualité et la stabilité du cadriciel web Django.

Prérogatives

Le comité technique possède les prérogatives suivantes :

  • Making a binding decision regarding any question of a technical change to Django.
  • Vetoing the merging of any particular piece of code into Django or ordering the reversion of any particular merge or commit.
  • Announcing calls for proposals and ideas for the future technical direction of 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 appropriate.
  • Calling elections of the technical board outside of those which are automatically triggered, at times when the technical board deems an election is appropriate.
  • Participating in modifying Django’s governance (see Changement d’organisation).
  • Declining to vote on a matter the technical board feels is unripe for a binding decision, or which the technical board feels is outside the scope of its powers.
  • Taking charge of the governance of other technical teams within the Django open-source project, and governing those teams accordingly.

Composition

The technical board is an elected group of five experienced contributors who demonstrate:

  • A history of technical contributions to Django or the Django ecosystem. This history must begin at least 18 months prior to the individual’s candidacy for the technical board.
  • A history of participation in Django’s development outside of contributions merged to the Django Git repository. This may include, but is not restricted to:
    • Participation in discussions on the django-developers mailing list or the Django forum.
    • Reviewing and offering feedback on pull requests in the Django source-code repository.
    • Assisting in triage and management of the Django bug tracker.
  • A history of recent engagement with the direction and development of Django. Such engagement must have occurred within a period of no more than two years prior to the individual’s candidacy for the technical board.

A new board is elected after each release cycle of Django. The election process works as follows:

  1. The technical board direct one of its members to notify the Secretary of the Django Software Foundation, in writing, of the triggering of the election, and the condition which triggered it. The Secretary post to the appropriate venue – the django-developers mailing list and the Django forum to announce the election and its timeline.
  2. As soon as the election is announced, the DSF Board begin a period of voter registration. All individual members of the DSF are automatically registered and need not explicitly register. All other persons who believe themselves eligible to vote, but who have not yet registered to vote, may make an application to the DSF Board for voting privileges. The voter registration form and roll of voters is maintained by the DSF Board. The DSF Board may challenge and reject the registration of voters it believes are registering in bad faith or who it believes have falsified their qualifications or are otherwise unqualified.
  3. Registration of voters close one week after the announcement of the election. At that point, registration of candidates begin. Any qualified person may register as a candidate. The candidate registration form and roster of candidates are maintained by the DSF Board, and candidates must provide evidence of their qualifications as part of registration. The DSF Board may challenge and reject the registration of candidates it believes do not meet the qualifications of members of the Technical Board, or who it believes are registering in bad faith.
  4. Registration of candidates close one week after it has opened. One week after registration of candidates closes, the Secretary of the DSF publish the roster of candidates to the django-developers mailing list and the Django forum, and the election begin. The DSF Board provide a voting form accessible to registered voters, and is the custodian of the votes.
  5. Voting is by secret ballot containing the roster of candidates, and any relevant materials regarding the candidates, in a randomized order. Each voter may vote for up to five candidates on the ballot.
  6. The election conclude one week after it begins. The DSF Board then tally the votes and produce a summary, including the total number of votes cast and the number received by each candidate. This summary is ratified by a majority vote of the DSF Board, then posted by the Secretary of the DSF to the django-developers mailing list and the Django Forum. The five candidates with the highest vote totals are immediately become the new technical board.

A member of the technical board may be removed by:

  • Becoming disqualified due to actions taken by the Code of Conduct committee of the Django Software Foundation.
  • Determining that they did not possess the qualifications of a member of the technical board. This determination must be made jointly by the other members of the technical board, and the DSF Board. A valid determination of ineligibility requires that all other members of the technical board and all members of the DSF Board vote who can vote on the issue (the affected person, if a DSF Board member, must not vote) vote « yes » on a motion that the person in question is ineligible.

Changement d’organisation

Changes to this document require the use of the DEP process, with modifications described in DEP 0010.

Back to Top