summaryrefslogtreecommitdiff
path: root/docs/internals
diff options
context:
space:
mode:
authorakki <akki@users.noreply.github.com>2016-11-16 03:30:50 +0530
committerTim Graham <timograham@gmail.com>2016-11-15 17:00:50 -0500
commit74ed20b49ade9f1cbd9af294e35478d8e0f59344 (patch)
tree102d77120cfc313b98ed02a8e9801666255d1725 /docs/internals
parent7c6efb3233ce01db96384483cef47769fba58ce2 (diff)
Replaced "django" with "Django" in spelling_wordlist.
Diffstat (limited to 'docs/internals')
-rw-r--r--docs/internals/contributing/committing-code.txt8
-rw-r--r--docs/internals/contributing/new-contributors.txt4
-rw-r--r--docs/internals/contributing/writing-code/working-with-git.txt10
-rw-r--r--docs/internals/deprecation.txt2
-rw-r--r--docs/internals/howto-release-django.txt2
-rw-r--r--docs/internals/organization.txt2
-rw-r--r--docs/internals/team.txt14
7 files changed, 21 insertions, 21 deletions
diff --git a/docs/internals/contributing/committing-code.txt b/docs/internals/contributing/committing-code.txt
index 32be5f1f06..445e341dda 100644
--- a/docs/internals/contributing/committing-code.txt
+++ b/docs/internals/contributing/committing-code.txt
@@ -109,9 +109,9 @@ Committing guidelines
In addition, please follow the following guidelines when committing code to
Django's Git repository:
-* Never change the published history of django/django branches! **Never
- force-push your changes to django/django.** If you absolutely must (for
- security reasons for example) first discuss the situation with the core team.
+* Never change the published history of ``django/django`` branches by force
+ pushing. If you absolutely must (for security reasons for example), first
+ discuss the situation with the team.
* For any medium-to-big changes, where "medium-to-big" is according to
your judgment, please bring things up on the |django-developers|
@@ -242,7 +242,7 @@ When a mistaken commit is discovered, please follow these guidelines:
* The release branch maintainer may back out commits to the release
branch without permission if the commit breaks the release branch.
-* If you mistakenly push a topic branch to django/django, just delete it.
+* If you mistakenly push a topic branch to ``django/django``, just delete it.
For instance, if you did: ``git push upstream feature_antigravity``,
just do a reverse push: ``git push upstream :feature_antigravity``.
diff --git a/docs/internals/contributing/new-contributors.txt b/docs/internals/contributing/new-contributors.txt
index a4be802909..379b0f8971 100644
--- a/docs/internals/contributing/new-contributors.txt
+++ b/docs/internals/contributing/new-contributors.txt
@@ -145,8 +145,8 @@ FAQ
First off, it's not personal. Django is entirely developed by volunteers
(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.
+ 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?**
diff --git a/docs/internals/contributing/writing-code/working-with-git.txt b/docs/internals/contributing/writing-code/working-with-git.txt
index 4bfeece755..7cea064b2a 100644
--- a/docs/internals/contributing/writing-code/working-with-git.txt
+++ b/docs/internals/contributing/writing-code/working-with-git.txt
@@ -55,8 +55,8 @@ cloned directory, so switch to it now::
Your GitHub repository will be called "origin" in Git.
-You should also setup django/django as an "upstream" remote (that is, tell git
-that the reference Django repository was the source of your fork of it)::
+You should also setup ``django/django`` as an "upstream" remote (that is, tell
+git that the reference Django repository was the source of your fork of it)::
git remote add upstream git@github.com:django/django.git
git fetch upstream
@@ -116,7 +116,7 @@ their clone would become corrupt when you edit commits.
There are also "public branches". These are branches other people are supposed
to fork, so the history of these branches should never change. Good examples
of public branches are the ``master`` and ``stable/A.B.x`` branches in the
-django/django repository.
+``django/django`` repository.
When you think your work is ready to be pulled into Django, you should create
a pull request at GitHub. A good pull request means:
@@ -193,14 +193,14 @@ a topic branch, and nobody should be basing their work on it.
After upstream has changed
--------------------------
-When upstream (django/django) has changed, you should rebase your work. To
+When upstream (``django/django``) has changed, you should rebase your work. To
do this, use::
git fetch upstream
git rebase
The work is automatically rebased using the branch you forked on, in the
-example case using upstream/master.
+example case using ``upstream/master``.
The rebase command removes all your local commits temporarily, applies the
upstream commits, and then applies your local commits again on the work.
diff --git a/docs/internals/deprecation.txt b/docs/internals/deprecation.txt
index 2d247d8f65..53d3ef4e9c 100644
--- a/docs/internals/deprecation.txt
+++ b/docs/internals/deprecation.txt
@@ -307,7 +307,7 @@ details on these changes.
* ``django.db.models.field.subclassing.SubfieldBase`` will be removed.
* ``django.utils.checksums`` will be removed; its functionality is included
- in django-localflavor 1.1+.
+ in ``django-localflavor`` 1.1+.
* The ``original_content_type_id`` attribute on
``django.contrib.admin.helpers.InlineAdminForm`` will be removed.
diff --git a/docs/internals/howto-release-django.txt b/docs/internals/howto-release-django.txt
index 40e5c25b34..6a91069abc 100644
--- a/docs/internals/howto-release-django.txt
+++ b/docs/internals/howto-release-django.txt
@@ -343,7 +343,7 @@ Now you're ready to actually put the release out there. To do this:
announcement blog post. If this is a security release, also include
oss-security@lists.openwall.com.
-#. Add a link to the blog post in the topic of the #django IRC channel:
+#. Add a link to the blog post in the topic of the `#django` IRC channel:
``/msg chanserv TOPIC #django new topic goes here``.
Post-release
diff --git a/docs/internals/organization.txt b/docs/internals/organization.txt
index 0d120fff2a..5982621757 100644
--- a/docs/internals/organization.txt
+++ b/docs/internals/organization.txt
@@ -145,7 +145,7 @@ The technical board holds two prerogatives:
- Making major technical decisions when no consensus is found otherwise. This
happens on the |django-developers| mailing-list.
- Veto a grant of commit access or remove commit access. This happens on the
- django-core mailing-list.
+ ``django-core`` mailing-list.
In both cases, the technical board is a last resort. In these matters, it
fulfills a similar function to the former Benevolent Dictators For Life.
diff --git a/docs/internals/team.txt b/docs/internals/team.txt
index e5e5090a5c..8af0fa00b8 100644
--- a/docs/internals/team.txt
+++ b/docs/internals/team.txt
@@ -191,7 +191,7 @@ Ramiro Morales
`Chris Beaven`_
Chris has been submitting patches and suggesting crazy ideas for Django
since early 2006. An advocate for community involvement and a long-term
- triager, he is still often found answering questions in the #django IRC
+ triager, he is still often found answering questions in the `#django` IRC
channel.
Chris lives in Napier, New Zealand (adding to the pool of Oceanic core
@@ -423,9 +423,9 @@ Daniele Procida
`Michael Manfre`_
Michael started running Django on Windows against a Microsoft SQL Server
(MSSQL) database in 2008. He quickly became the maintainer of the
- django-mssql 3rd party database backend. Much of his involvement with
- Django relates to the ORM, the private 3rd party database API, and using
- Django on Windows.
+ ``django-mssql`` database backend. Much of his involvement with Django
+ relates to the ORM, the private 3rd party database API, and using Django on
+ Windows.
Michael lives in Cary, NC, USA.
@@ -461,11 +461,11 @@ Daniele Procida
specialization. Upon finding Django when it was first open sourced, he
realized it was possible to enjoy web development.
- He spends a lot of time helping people on the #django IRC channel, and has
- authored and released a number of `smaller django apps`_.
+ He spends a lot of time helping people on the `#django` IRC channel, and
+ has authored and released a number of `smaller Django apps`_.
.. _Curtis Maloney: http://musings.tinbrain.net/blog/
- .. _smaller django apps: https://github.com/funkybob/
+ .. _smaller Django apps: https://github.com/funkybob/
`Markus Holtermann`_
Markus is a senior backend developer at `LaterPay`_ in Munich. He studied