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.
This commit is contained in:
Aymeric Augustin 2014-07-13 19:42:06 +02:00
parent dd9c8f9382
commit a4ead67ee9
11 changed files with 48 additions and 50 deletions

View File

@ -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

View File

@ -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?**

View File

@ -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 File

@ -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 File

@ -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

View File

@ -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`_

View File

@ -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
===============

View File

@ -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 File

@ -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
=========

View File

@ -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.
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.
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 Django development team within 48
hours, and depending on the action to be taken, you may receive
further followup emails.
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 File

@ -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