Permalink
Browse files

Adjusted 'internals' docs to the new organization.

Most of these changes are about using the correct vocabulary -- "core
team member" vs "core developer/committer" and adding internal links.
  • Loading branch information...
aaugustin committed Jul 13, 2014
1 parent dd9c8f9 commit a4ead67ee9000a41f7bdca2978c5b2e309066220
@@ -2,9 +2,9 @@
Committing code
===============
-This section is addressed to the :doc:`/internals/team` and to anyone
-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
+This section is addressed to the :ref:`committers` and to anyone 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.
.. _handling-pull-requests:
@@ -109,7 +109,7 @@ Django's Git repository:
If you bring something up on |django-developers| and nobody responds,
please don't take that to mean your idea is great and should be
- implemented immediately because nobody contested it. Django's lead
+ implemented immediately because nobody contested it. Django's core
developers don't have a lot of time to read mailing-list discussions
immediately, so you may have to wait a couple of days before getting a
response.
@@ -142,7 +142,7 @@ Django's Git repository:
use frequent small commits rather than infrequent large commits. For
example, if implementing feature X requires a small change to library Y,
first commit the change to library Y, then commit feature X in a
- separate commit. This goes a *long way* in helping all core Django
+ separate commit. This goes a *long way* in helping all Django core
developers follow your changes.
* Separate bug fixes from feature changes. Bugfixes may need to be backported
@@ -169,7 +169,6 @@ Django's Git repository:
commit message, GitHub will close the pull request, but the Trac plugin
will also close the same numbered ticket in Trac.
-
.. _Trac plugin: https://github.com/aaugustin/trac-github
* If your commit references a ticket in the Django `ticket tracker`_ but
@@ -102,8 +102,8 @@ some advice to make your work on Django more useful and rewarding.
Sometimes it can be scary to put your opinion out to the world and say "this
ticket is correct" or "this patch needs work", but it's the only way the
project moves forward. The contributions of the broad Django community
- ultimately have a much greater impact than that of the core developers. We
- can't do it without YOU!
+ ultimately have a much greater impact than that of the core team. We can't
+ do it without **you**!
* **Err on the side of caution when marking things Ready For Check-in**
@@ -138,10 +138,10 @@ FAQ
I do to get it committed?**
First off, it's not personal. Django is entirely developed by volunteers
- (even the core developers), and sometimes folks just don't have time. The
- best thing to do is to send a gentle reminder to the |django-developers|
- mailing list asking for review on the ticket, or to bring it up in the
- #django-dev IRC channel.
+ (even the core team), and sometimes folks just don't have time. The best
+ thing to do is to send a gentle reminder to the |django-developers| mailing
+ list asking for review on the ticket, or to bring it up in the #django-dev
+ IRC channel.
2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
myself?**
@@ -29,7 +29,7 @@ possible, and raise issues for discussion on our mailing lists when there is
confusion or disagreement.
Django is a community project, and every contribution helps. We can't do this
-without YOU!
+without **you**!
Triage workflow
---------------
@@ -146,7 +146,7 @@ Ready For Checkin
The ticket was reviewed by any member of the community other than the person
who supplied the patch and found to meet all the requirements for a
-commit-ready patch. A core committer now needs to give the patch a final
+commit-ready patch. A committer now needs to give the patch a final
review prior to being committed. See the
:ref:`New contributors' FAQ<new-contributors-faq>` for "My ticket has been in
RFC forever! What should I do?"
View
@@ -243,7 +243,8 @@ branches, used for Google Summer of Code projects.
Tags
====
-Each Django release is tagged and signed by Django's release manager.
+Each Django release is tagged and signed by a :ref:`releaser
+<releasers-list>`.
The tags can be found on GitHub's `tags`_ page.
View
@@ -2,16 +2,7 @@ Django internals
================
Documentation for people hacking on Django itself. This is the place to go if
-you'd like to help improve Django, learn or learn about how Django works "under
-the hood".
-
-.. warning::
-
- Elsewhere in the Django documentation, coverage of a feature is a sort of a
- contract: once an API is in the official documentation, we consider it
- "stable" and don't change it without a good reason. APIs covered here,
- however, are considered "internal-only": we reserve the right to change
- these internals if we must.
+you'd like to help improve Django or learn about how Django is managed.
.. toctree::
:maxdepth: 2
@@ -40,9 +40,9 @@ installation, usage, or debugging of Django.
``django-core-mentorship``
--------------------------
-The Django Core Development Mentorship list is intended to provide a welcoming
-introductory environment for developers interested in contributing to core
-Django development.
+The Django Core Mentorship list is intended to provide a welcoming
+introductory environment for community members interested in contributing to
+the Django Project.
* `django-core-mentorship mailing archive`_
* `django-core-mentorship subscription email address`_
@@ -33,6 +33,8 @@ Until 2014, the Django Project was a benevolent_ dictatorship_.
.. _benevolent: http://www.holovaty.com/writing/bdfls-retiring/
.. _dictatorship: http://jacobian.org/writing/retiring-as-bdfls/
+.. _core-team:
+
Core team
=========
@@ -130,6 +132,8 @@ 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
===============
@@ -144,11 +144,11 @@ Release process
Django uses a time-based release schedule, with major (i.e. 1.6, 1.7, etc.)
releases every nine months, or more, depending on features.
-After each release, and after a suitable cooling-off period of a few weeks, the
-core development team will examine the landscape and announce a timeline for the
-next release. Most releases will be scheduled in the 6-9 month range, but if we
-have bigger features to development we might schedule a longer period to allow
-for more ambitious work.
+After each release, and after a suitable cooling-off period of a few weeks,
+core developers will examine the landscape and announce a timeline for the
+next release. Most releases will be scheduled in the 6-9 month range, but if
+we have bigger features to development we might schedule a longer period to
+allow for more ambitious work.
Release cycle
-------------
View
@@ -9,6 +9,8 @@ Technical board
The first technical board hasn't been elected yet.
+.. _committers:
+
Committers
==========
@@ -17,6 +19,8 @@ Most :ref:`core team <core-team>` members have commit access. They're called
Being part of the core team is a pre-requisite for having commit access.
+.. _security-team-list:
+
Security team
=============
@@ -35,6 +39,8 @@ The current security team members are:
- Carl Meyer
- Donald Stufft
+.. _releasers-list:
+
Releasers
=========
@@ -19,21 +19,20 @@ Reporting security issues
**Short version: please report security issues by emailing
security@djangoproject.com**.
-Most normal bugs in Django are reported to `our public Trac
-instance`_, but due to the sensitive nature of security issues, we ask
-that they **not** be publicly reported in this fashion.
-
-Instead, if you believe you've found something in Django which has
-security implications, please send a description of the issue via
-email to ``security@djangoproject.com``. Mail sent to that address
-reaches a subset of the core development team, who can forward
-security issues into the private committers' mailing list for broader
-discussion if needed.
-
-Once you've submitted an issue via email, you should receive an
-acknowledgment from a member of the Django development team within 48
-hours, and depending on the action to be taken, you may receive
-further followup emails.
+Most normal bugs in Django are reported to `our public Trac instance`_, but
+due to the sensitive nature of security issues, we ask that they **not** be
+publicly reported in this fashion.
+
+Instead, if you believe you've found something in Django which has security
+implications, please send a description of the issue via email to
+``security@djangoproject.com``. Mail sent to that address reaches a
+:ref:`subset of the core team <security-team-list>`, who can forward security
+issues into the private committers' mailing list for broader discussion if
+needed.
+
+Once you've submitted an issue via email, you should receive an acknowledgment
+from a member of the security team within 48 hours, and depending on the
+action to be taken, you may receive further followup emails.
.. note::
View
@@ -62,12 +62,10 @@ Journal-World`_ of Lawrence, Kansas, USA.
The current team
================
-Currently, Django is led by a team of volunteers from around the globe.
-
These are the folks who have a long history of contributions, a solid track
record of being helpful on the mailing lists, and a proven desire to dedicate
-serious time to Django. In return, they've been granted the coveted commit bit,
-and have free rein to hack on all parts of Django.
+serious time to Django. In return, they've been invited to join the :ref:`core
+team <core-team>`.
Malcolm Tredinnick
Malcolm originally wanted to be a mathematician, somehow ended up a software

0 comments on commit a4ead67

Please sign in to comment.