1 files changed, 17 insertions, 17 deletions
diff --git a/docs/topics/2.3-announcement.md b/docs/topics/2.3-announcement.md
index 9fdebcd9..21d9f1db 100644
--- a/docs/topics/2.3-announcement.md
+++ b/docs/topics/2.3-announcement.md
@@ -1,4 +1,4 @@
-# REST framework 2.3 announcement
+# Django REST framework 2.3
 
 REST framework 2.3 makes it even quicker and easier to build your Web APIs.
 
@@ -15,7 +15,7 @@ As an example of just how simple REST framework APIs can now be, here's an API w
     """
     A REST framework API for viewing and editing users and groups.
     """
-    from django.conf.urls.defaults import url, patterns, include
+    from django.conf.urls.defaults import url, include
     from django.contrib.auth.models import User, Group
     from rest_framework import viewsets, routers
 
@@ -27,7 +27,7 @@ As an example of just how simple REST framework APIs can now be, here's an API w
     class GroupViewSet(viewsets.ModelViewSet):
         model = Group
 
-    
+
     # Routers provide an easy way of automatically determining the URL conf
     router = routers.DefaultRouter()
     router.register(r'users', UserViewSet)
@@ -35,11 +35,11 @@ As an example of just how simple REST framework APIs can now be, here's an API w
 
 
     # Wire up our API using automatic URL routing.
-    # Additionally, we include login URLs for the browseable API.
-    urlpatterns = patterns('',
+    # Additionally, we include login URLs for the browsable API.
+    urlpatterns = [
         url(r'^', include(router.urls)),
         url(r'^api-auth/', include('rest_framework.urls', namespace='rest_framework'))
-    )
+    ]
 
 The best place to get started with ViewSets and Routers is to take a look at the [newest section in the tutorial][part-6], which demonstrates their usage.
 
@@ -131,7 +131,7 @@ The `get_object` and `get_paginate_by` methods no longer take an optional querys
 
 Using an optional queryset with these methods continues to be supported, but will raise a `PendingDeprecationWarning`.
 
-The `paginate_queryset` method no longer takes a `page_size` argument, or returns a four-tuple of pagination information.  Instead it simply takes a queryset argument, and either returns a `page` object with an appropraite page size, or returns `None`, if pagination is not configured for the view.
+The `paginate_queryset` method no longer takes a `page_size` argument, or returns a four-tuple of pagination information.  Instead it simply takes a queryset argument, and either returns a `page` object with an appropriate page size, or returns `None`, if pagination is not configured for the view.
 
 Using the `page_size` argument is still supported and will trigger the old-style return type, but will raise a `PendingDeprecationWarning`.
 
@@ -195,23 +195,23 @@ Usage of the old-style attributes continues to be supported, but will raise a `P
 
 2.3 introduces a `DecimalField` serializer field, which returns `Decimal` instances.
 
-For most cases APIs using model fields will behave as previously, however if you are using a custom renderer, not provided by REST framework, then you may now need to add support for rendering `Decimal` instances to your renderer implmentation.
+For most cases APIs using model fields will behave as previously, however if you are using a custom renderer, not provided by REST framework, then you may now need to add support for rendering `Decimal` instances to your renderer implementation.
 
-## ModelSerializers and reverse relationships 
+## ModelSerializers and reverse relationships
 
 The support for adding reverse relationships to the `fields` option on a `ModelSerializer` class means that the `get_related_field` and `get_nested_field` method signatures have now changed.
 
-In the unlikely event that you're providing a custom serializer class, and implementing these methods you should note the new call signature for both methods is now `(self, model_field, related_model, to_many)`.  For revese relationships `model_field` will be `None`.
+In the unlikely event that you're providing a custom serializer class, and implementing these methods you should note the new call signature for both methods is now `(self, model_field, related_model, to_many)`.  For reverse relationships `model_field` will be `None`.
 
-The old-style signature will continue to function but will raise a `PendingDeprecationWarning`. 
+The old-style signature will continue to function but will raise a `PendingDeprecationWarning`.
 
 ## View names and descriptions
 
-The mechanics of how the names and descriptions used in the browseable API are generated has been modified and cleaned up somewhat.
+The mechanics of how the names and descriptions used in the browsable API are generated has been modified and cleaned up somewhat.
 
-If you've been customizing this behavior, for example perhaps to use `rst` markup for the browseable API, then you'll need to take a look at the implementation to see what updates you need to make.
+If you've been customizing this behavior, for example perhaps to use `rst` markup for the browsable API, then you'll need to take a look at the implementation to see what updates you need to make.
 
-Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated. 
+Note that the relevant methods have always been private APIs, and the docstrings called them out as intended to be deprecated.
 
 ---
 
@@ -219,7 +219,7 @@ Note that the relevant methods have always been private APIs, and the docstrings
 
 ## More explicit style
 
-The usage of `model` attribute in generic Views is still supported, but it's usage is generally being discouraged throughout the documentation, in favour of the setting the more explict `queryset` and `serializer_class` attributes.
+The usage of `model` attribute in generic Views is still supported, but it's usage is generally being discouraged throughout the documentation, in favour of the setting the more explicit `queryset` and `serializer_class` attributes.
 
 For example, the following is now the recommended style for using generic views:
 
@@ -227,7 +227,7 @@ For example, the following is now the recommended style for using generic views:
         queryset = MyModel.objects.all()
         serializer_class = MyModelSerializer
 
-Using an explict `queryset` and `serializer_class` attributes makes the functioning of the view more clear than using the shortcut `model` attribute.
+Using an explicit `queryset` and `serializer_class` attributes makes the functioning of the view more clear than using the shortcut `model` attribute.
 
 It also makes the usage of the `get_queryset()` or `get_serializer_class()` methods more obvious.
 
@@ -246,7 +246,7 @@ It also makes the usage of the `get_queryset()` or `get_serializer_class()` meth
 
 ## Django 1.3 support
 
-The 2.3.x release series will be the last series to provide compatiblity with Django 1.3.
+The 2.3.x release series will be the last series to provide compatibility with Django 1.3.
 
 ## Version 2.2 API changes