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:
parent
dd9c8f9382
commit
a4ead67ee9
|
@ -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?"
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
-------------
|
||||
|
|
|
@ -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.
|
||||
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::
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in New Issue