organization.txt 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299
  1. ==================================
  2. Organization of the Django Project
  3. ==================================
  4. Principles
  5. ==========
  6. The Django Project is managed by a team of volunteers pursuing three goals:
  7. - Driving the development of the Django web framework,
  8. - Fostering the ecosystem of Django-related software,
  9. - Leading the Django community in accordance with the values described in the
  10. `Django Code of Conduct`_.
  11. The Django Project isn't a legal entity. The `Django Software Foundation`_, a
  12. non-profit organization, handles financial and legal matters related to the
  13. Django Project. Other than that, the Django Software Foundation lets the
  14. Django Project manage the development of the Django framework, its ecosystem
  15. and its community.
  16. .. _Django Code of Conduct: https://www.djangoproject.com/conduct/
  17. .. _Django Software Foundation: https://www.djangoproject.com/foundation/
  18. .. _mergers-team:
  19. Mergers
  20. =======
  21. Role
  22. ----
  23. Mergers_ are a small set of people who merge pull requests to the `Django Git
  24. repository`_.
  25. Prerogatives
  26. ------------
  27. Mergers hold the following prerogatives:
  28. - Merging any pull request which constitutes a `minor change`_ (small enough
  29. not to require the use of the `DEP process`_). A Merger must not merge a
  30. change primarily authored by that Merger, unless the pull request has been
  31. approved by:
  32. - another Merger,
  33. - a steering council member,
  34. - a member of the `triage & review team`_, or
  35. - a member of the `security team`_.
  36. - Initiating discussion of a minor change in the appropriate venue, and request
  37. that other Mergers refrain from merging it while discussion proceeds.
  38. - Requesting a vote of the steering council regarding any minor change if, in
  39. the Merger's opinion, discussion has failed to reach a consensus.
  40. - Requesting a vote of the steering council when a `major change`_ (significant
  41. enough to require the use of the `DEP process`_) reaches one of its
  42. implementation milestones and is intended to merge.
  43. .. _`minor change`: https://github.com/django/deps/blob/main/final/0010-new-governance.rst#terminology
  44. .. _`major change`: https://github.com/django/deps/blob/main/final/0010-new-governance.rst#terminology
  45. Membership
  46. ----------
  47. `The steering council`_ selects Mergers_ as necessary to maintain their number
  48. at a minimum of three, in order to spread the workload and avoid over-burdening
  49. or burning out any individual Merger. There is no upper limit to the number of
  50. Mergers.
  51. It's not a requirement that a Merger is also a Django Fellow, but the Django
  52. Software Foundation has the power to use funding of Fellow positions as a way
  53. to make the role of Merger sustainable.
  54. The following restrictions apply to the role of Merger:
  55. - A person must not simultaneously serve as a member of the steering council. If
  56. a Merger is elected to the steering council, they shall cease to be a Merger
  57. immediately upon taking up membership in the steering council.
  58. - A person may serve in the roles of Releaser and Merger simultaneously.
  59. The selection process, when a vacancy occurs or when the steering council deems
  60. it necessary to select additional persons for such a role, occur as follows:
  61. - Any member in good standing of an appropriate discussion venue, or the Django
  62. Software Foundation board acting with the input of the DSF's Fellowship
  63. committee, may suggest a person for consideration.
  64. - The steering council considers the suggestions put forth, and then any member
  65. of the steering council formally nominates a candidate for the role.
  66. - The steering council votes on nominees.
  67. Mergers may resign their role at any time, but should endeavor to provide some
  68. advance notice in order to allow the selection of a replacement. Termination of
  69. the contract of a Django Fellow by the Django Software Foundation temporarily
  70. suspends that person's Merger role until such time as the steering council can
  71. vote on their nomination.
  72. Otherwise, a Merger may be removed by:
  73. - Becoming disqualified due to election to the steering council.
  74. - Becoming disqualified due to actions taken by the Code of Conduct committee
  75. of the Django Software Foundation.
  76. - A vote of the steering council.
  77. .. _releasers-team:
  78. Releasers
  79. =========
  80. Role
  81. ----
  82. Releasers_ are a small set of people who have the authority to upload packaged
  83. releases of Django to the :pypi:`Python Package Index <Django>` and to the
  84. `djangoproject.com`_ website.
  85. Prerogatives
  86. ------------
  87. Releasers_ :doc:`build Django releases </internals/howto-release-django>` and
  88. upload them to the :pypi:`Python Package Index <Django>` and to the
  89. `djangoproject.com`_ website.
  90. Membership
  91. ----------
  92. `The steering council`_ selects Releasers_ as necessary to maintain their number
  93. at a minimum of three, in order to spread the workload and avoid over-burdening
  94. or burning out any individual Releaser. There is no upper limit to the number
  95. of Releasers.
  96. It's not a requirement that a Releaser is also a Django Fellow, but the Django
  97. Software Foundation has the power to use funding of Fellow positions as a way
  98. to make the role of Releaser sustainable.
  99. A person may serve in the roles of Releaser and Merger simultaneously.
  100. The selection process, when a vacancy occurs or when the steering council deems
  101. it necessary to select additional persons for such a role, occur as follows:
  102. - Any member in good standing of an appropriate discussion venue, or the Django
  103. Software Foundation board acting with the input of the DSF's Fellowship
  104. committee, may suggest a person for consideration.
  105. - The steering council considers the suggestions put forth, and then any member
  106. of the steering council formally nominates a candidate for the role.
  107. - The steering council votes on nominees.
  108. Releasers may resign their role at any time, but should endeavor to provide
  109. some advance notice in order to allow the selection of a replacement.
  110. Termination of the contract of a Django Fellow by the Django Software
  111. Foundation temporarily suspends that person's Releaser role until such time as
  112. the steering council can vote on their nomination.
  113. Otherwise, a Releaser may be removed by:
  114. - Becoming disqualified due to actions taken by the Code of Conduct committee
  115. of the Django Software Foundation.
  116. - A vote of the steering council.
  117. .. _djangoproject.com: https://www.djangoproject.com/download/
  118. .. _steering-council:
  119. Steering council
  120. ================
  121. Role
  122. ----
  123. The steering council is a group of experienced contributors who:
  124. - provide oversight of Django's development and release process,
  125. - assist in setting the direction of feature development and releases,
  126. - select Mergers and Releasers, and
  127. - have a tie-breaking vote when other decision-making processes fail.
  128. Their main concern is to maintain the quality and stability of the Django Web
  129. Framework.
  130. Prerogatives
  131. ------------
  132. The steering council holds the following prerogatives:
  133. - Making a binding decision regarding any question of a technical change to
  134. Django.
  135. - Vetoing the merging of any particular piece of code into Django or ordering
  136. the reversion of any particular merge or commit.
  137. - Announcing calls for proposals and ideas for the future technical direction
  138. of Django.
  139. - Selecting and removing mergers and releasers.
  140. - Participating in the removal of members of the steering council, when deemed
  141. appropriate.
  142. - Calling elections of the steering council outside of those which are
  143. automatically triggered, at times when the steering council deems an election
  144. is appropriate.
  145. - Participating in modifying Django's governance (see
  146. :ref:`organization-change`).
  147. - Declining to vote on a matter the steering council feels is unripe for a
  148. binding decision, or which the steering council feels is outside the scope of
  149. its powers.
  150. - Taking charge of the governance of other technical teams within the Django
  151. open-source project, and governing those teams accordingly.
  152. Membership
  153. ----------
  154. `The steering council`_ is an elected group of five experienced contributors
  155. who demonstrate:
  156. - A history of substantive contributions to Django or the Django ecosystem.
  157. This history must begin at least 18 months prior to the individual's
  158. candidacy for the Steering Council, and include substantive contributions in
  159. at least two of these bullet points:
  160. - Code contributions to Django projects or major third-party packages in the
  161. Django ecosystem
  162. - Reviewing pull requests and/or triaging Django project tickets
  163. - Documentation, tutorials or blog posts
  164. - Discussions about Django on the django-developers mailing list or the Django
  165. Forum
  166. - Running Django-related events or user groups
  167. - A history of engagement with the direction and future of Django. This does
  168. not need to be recent, but candidates who have not engaged in the past three
  169. years must still demonstrate an understanding of Django's changes and
  170. direction within those three years.
  171. A new council is elected after each release cycle of Django. The election process
  172. works as follows:
  173. #. The steering council directs one of its members to notify the Secretary of the
  174. Django Software Foundation, in writing, of the triggering of the election,
  175. and the condition which triggered it. The Secretary post to the appropriate
  176. venue -- the |django-developers| mailing list and the `Django forum`_ to
  177. announce the election and its timeline.
  178. #. As soon as the election is announced, the `DSF Board`_ begin a period of
  179. voter registration. All `individual members of the DSF`_ are automatically
  180. registered and need not explicitly register. All other persons who believe
  181. themselves eligible to vote, but who have not yet registered to vote, may
  182. make an application to the DSF Board for voting privileges. The voter
  183. registration form and roll of voters is maintained by the DSF Board. The DSF
  184. Board may challenge and reject the registration of voters it believes are
  185. registering in bad faith or who it believes have falsified their
  186. qualifications or are otherwise unqualified.
  187. #. Registration of voters close one week after the announcement of the
  188. election. At that point, registration of candidates begin. Any qualified
  189. person may register as a candidate. The candidate registration form and
  190. roster of candidates are maintained by the DSF Board, and candidates must
  191. provide evidence of their qualifications as part of registration. The DSF
  192. Board may challenge and reject the registration of candidates it believes do
  193. not meet the qualifications of members of the Steering Council, or who it
  194. believes are registering in bad faith.
  195. #. Registration of candidates close one week after it has opened. One week
  196. after registration of candidates closes, the Secretary of the DSF publish
  197. the roster of candidates to the |django-developers| mailing list and the
  198. `Django forum`_, and the election begin. The DSF Board provide a voting form
  199. accessible to registered voters, and is the custodian of the votes.
  200. #. Voting is by secret ballot containing the roster of candidates, and any
  201. relevant materials regarding the candidates, in a randomized order. Each
  202. voter may vote for up to five candidates on the ballot.
  203. #. The election conclude one week after it begins. The DSF Board then tally the
  204. votes and produce a summary, including the total number of votes cast and
  205. the number received by each candidate. This summary is ratified by a
  206. majority vote of the DSF Board, then posted by the Secretary of the DSF to
  207. the |django-developers| mailing list and the Django Forum. The five
  208. candidates with the highest vote totals are immediately become the new
  209. steering council.
  210. A member of the steering council may be removed by:
  211. - Becoming disqualified due to actions taken by the Code of Conduct committee
  212. of the Django Software Foundation.
  213. - Determining that they did not possess the qualifications of a member of the
  214. steering council. This determination must be made jointly by the other members
  215. of the steering council, and the `DSF Board`_. A valid determination of
  216. ineligibility requires that all other members of the steering council and all
  217. members of the DSF Board vote who can vote on the issue (the affected person,
  218. if a DSF Board member, must not vote) vote "yes" on a motion that the person
  219. in question is ineligible.
  220. .. _`Django forum`: https://forum.djangoproject.com/
  221. .. _`Django Git repository`: https://github.com/django/django/
  222. .. _`DSF Board`: https://www.djangoproject.com/foundation/#board
  223. .. _`individual members of the DSF`: https://www.djangoproject.com/foundation/individual-members/
  224. .. _mergers: https://www.djangoproject.com/foundation/teams/#mergers-team
  225. .. _releasers: https://www.djangoproject.com/foundation/teams/#releasers-team
  226. .. _`security team`: https://www.djangoproject.com/foundation/teams/#security-team
  227. .. _`the steering council`: https://www.djangoproject.com/foundation/teams/#steering-council-team
  228. .. _`triage & review team`: https://www.djangoproject.com/foundation/teams/#triage-review-team
  229. .. _organization-change:
  230. Changing the organization
  231. =========================
  232. Changes to this document require the use of the `DEP process`_, with
  233. modifications described in `DEP 0010`_.
  234. .. _`DEP process`: https://github.com/django/deps/blob/main/final/0001-dep-process.rst
  235. .. _`DEP 0010`: https://github.com/django/deps/blob/main/final/0010-new-governance.rst#changing-this-governance-process