24 files changed, 48 insertions, 48 deletions
diff --git a/docs/ref/contrib/auth.txt b/docs/ref/contrib/auth.txt
index 6bcdf5e099..c15ff5f6eb 100644
--- a/docs/ref/contrib/auth.txt
+++ b/docs/ref/contrib/auth.txt
@@ -334,7 +334,7 @@ Manager methods
 
 In practice, you probably won't need to use
 :class:`~django.contrib.auth.models.AnonymousUser` objects on your own, but
-they're used by Web requests, as explained in the next section.
+they're used by web requests, as explained in the next section.
 
 ``Permission`` model
 ====================
diff --git a/docs/ref/contrib/gis/geos.txt b/docs/ref/contrib/gis/geos.txt
index 0bd3c5f8b7..8a45897c31 100644
--- a/docs/ref/contrib/gis/geos.txt
+++ b/docs/ref/contrib/gis/geos.txt
@@ -87,7 +87,7 @@ Finally, there is the :func:`fromfile` factory method which returns a
 .. admonition:: My logs are filled with GEOS-related errors
 
     You find many ``TypeError`` or ``AttributeError`` exceptions filling your
-    Web server's log files. This generally means that you are creating GEOS
+    web server's log files. This generally means that you are creating GEOS
     objects at the top level of some of your Python modules. Then, due to a race
     condition in the garbage collector, your module is garbage collected before
     the GEOS object. To prevent this, create :class:`GEOSGeometry` objects
diff --git a/docs/ref/contrib/gis/index.txt b/docs/ref/contrib/gis/index.txt
index 24d9172841..cee2f93679 100644
--- a/docs/ref/contrib/gis/index.txt
+++ b/docs/ref/contrib/gis/index.txt
@@ -5,8 +5,8 @@ GeoDjango
 .. module:: django.contrib.gis
     :synopsis: Geographic Information System (GIS) extensions for Django
 
-GeoDjango intends to be a world-class geographic Web framework. Its goal is to
-make it as easy as possible to build GIS Web applications and harness the power
+GeoDjango intends to be a world-class geographic web framework. Its goal is to
+make it as easy as possible to build GIS web applications and harness the power
 of spatially enabled data.
 
 .. toctree::
diff --git a/docs/ref/contrib/gis/model-api.txt b/docs/ref/contrib/gis/model-api.txt
index 8ad7cd8772..cd531ce785 100644
--- a/docs/ref/contrib/gis/model-api.txt
+++ b/docs/ref/contrib/gis/model-api.txt
@@ -123,7 +123,7 @@ corresponds to the projection system that will be used to interpret the data
 in the spatial database. [#fnsrid]_  Projection systems give the context to the
 coordinates that specify a location.  Although the details of `geodesy`__ are
 beyond the scope of this documentation, the general problem is that the earth
-is spherical and representations of the earth (e.g., paper maps, Web maps)
+is spherical and representations of the earth (e.g., paper maps, web maps)
 are not.
 
 Most people are familiar with using latitude and longitude to reference a
diff --git a/docs/ref/contrib/gis/tutorial.txt b/docs/ref/contrib/gis/tutorial.txt
index d772d2e76d..82c3c93854 100644
--- a/docs/ref/contrib/gis/tutorial.txt
+++ b/docs/ref/contrib/gis/tutorial.txt
@@ -6,8 +6,8 @@ Introduction
 ============
 
 GeoDjango is an included contrib module for Django that turns it into a
-world-class geographic Web framework.  GeoDjango strives to make it as simple
-as possible to create geographic Web applications, like location-based services.
+world-class geographic web framework. GeoDjango strives to make it as simple
+as possible to create geographic web applications, like location-based services.
 Its features include:
 
 * Django model fields for `OGC`_ geometries and raster data.
diff --git a/docs/ref/contrib/gis/utils.txt b/docs/ref/contrib/gis/utils.txt
index d7c82a248e..614308d41f 100644
--- a/docs/ref/contrib/gis/utils.txt
+++ b/docs/ref/contrib/gis/utils.txt
@@ -6,7 +6,7 @@ GeoDjango Utilities
     :synopsis: GeoDjango's collection of utilities.
 
 The :mod:`django.contrib.gis.utils` module contains various utilities that are
-useful in creating geospatial Web applications.
+useful in creating geospatial web applications.
 
 .. toctree::
     :maxdepth: 2
diff --git a/docs/ref/contrib/index.txt b/docs/ref/contrib/index.txt
index 1890b35cf6..8a9a90e5e8 100644
--- a/docs/ref/contrib/index.txt
+++ b/docs/ref/contrib/index.txt
@@ -4,7 +4,7 @@
 
 Django aims to follow Python's :ref:`"batteries included" philosophy
 <tut-batteries-included>`. It ships with a variety of extra, optional tools
-that solve common Web-development problems.
+that solve common web development problems.
 
 This code lives in ``django/contrib`` in the Django distribution. This document
 gives a rundown of the packages in ``contrib``, along with any dependencies
diff --git a/docs/ref/contrib/sitemaps.txt b/docs/ref/contrib/sitemaps.txt
index 51cd78aafe..709a3679a4 100644
--- a/docs/ref/contrib/sitemaps.txt
+++ b/docs/ref/contrib/sitemaps.txt
@@ -79,7 +79,7 @@ a :class:`~django.contrib.sitemaps.Sitemap` class (e.g.,
 A :class:`~django.contrib.sitemaps.Sitemap` class is a Python class that
 represents a "section" of entries in your sitemap. For example, one
 :class:`~django.contrib.sitemaps.Sitemap` class could represent all the entries
-of your Weblog, while another could represent all of the events in your events
+of your blog, while another could represent all of the events in your events
 calendar.
 
 In the simplest case, all these sections get lumped together into one
diff --git a/docs/ref/contrib/sites.txt b/docs/ref/contrib/sites.txt
index 30d21b17f4..ea9e211964 100644
--- a/docs/ref/contrib/sites.txt
+++ b/docs/ref/contrib/sites.txt
@@ -174,7 +174,7 @@ Getting the current domain for display
 
 LJWorld.com and Lawrence.com both have email alert functionality, which lets
 readers sign up to get notifications when news happens. It's pretty basic: A
-reader signs up on a Web form and immediately gets an email saying,
+reader signs up on a web form and immediately gets an email saying,
 "Thanks for your subscription."
 
 It'd be inefficient and redundant to implement this sign up processing code
diff --git a/docs/ref/contrib/syndication.txt b/docs/ref/contrib/syndication.txt
index a268bad8cc..c71cd53a99 100644
--- a/docs/ref/contrib/syndication.txt
+++ b/docs/ref/contrib/syndication.txt
@@ -13,7 +13,7 @@ To create any syndication feed, all you have to do is write a short
 Python class. You can create as many feeds as you want.
 
 Django also comes with a lower-level feed-generating API. Use this if
-you want to generate feeds outside of a Web context, or in some other
+you want to generate feeds outside of a web context, or in some other
 lower-level way.
 
 .. _RSS: https://developer.mozilla.org/en-US/docs/Glossary/RSS
@@ -1014,7 +1014,7 @@ For example, to create an Atom 1.0 feed and print it to standard output::
     >>> from django.utils import feedgenerator
     >>> from datetime import datetime
     >>> f = feedgenerator.Atom1Feed(
-    ...     title="My Weblog",
+    ...     title="My Blog",
     ...     link="https://www.example.com/",
     ...     description="In which I write about what I ate today.",
     ...     language="en",
diff --git a/docs/ref/django-admin.txt b/docs/ref/django-admin.txt
index 89d945500d..4af510731f 100644
--- a/docs/ref/django-admin.txt
+++ b/docs/ref/django-admin.txt
@@ -918,7 +918,7 @@ detected.
 
 .. django-admin:: runserver [addrport]
 
-Starts a lightweight development Web server on the local machine. By default,
+Starts a lightweight development web server on the local machine. By default,
 the server runs on port 8000 on the IP address ``127.0.0.1``. You can pass in an
 IP address and port number explicitly.
 
@@ -931,7 +931,7 @@ This server uses the WSGI application object specified by the
 
 DO NOT USE THIS SERVER IN A PRODUCTION SETTING. It has not gone through
 security audits or performance tests. (And that's how it's gonna stay. We're in
-the business of making Web frameworks, not Web servers, so improving this
+the business of making web frameworks, not web servers, so improving this
 server to be able to handle a production environment is outside the scope of
 Django.)
 
@@ -1580,12 +1580,12 @@ This is useful in a number of ways:
 
 * When you're writing :doc:`unit tests </topics/testing/overview>` of how your views
   act with certain fixture data, you can use ``testserver`` to interact with
-  the views in a Web browser, manually.
+  the views in a web browser, manually.
 
 * Let's say you're developing your Django application and have a "pristine"
   copy of a database that you'd like to interact with. You can dump your
   database to a fixture (using the :djadmin:`dumpdata` command, explained
-  above), then use ``testserver`` to run your Web application with that data.
+  above), then use ``testserver`` to run your web application with that data.
   With this arrangement, you have the flexibility of messing up your data
   in any way, knowing that whatever data changes you're making are only
   being made to a test database.
diff --git a/docs/ref/forms/widgets.txt b/docs/ref/forms/widgets.txt
index 802ba0055e..f5d42154e6 100644
--- a/docs/ref/forms/widgets.txt
+++ b/docs/ref/forms/widgets.txt
@@ -111,7 +111,7 @@ Customizing widget instances
 When Django renders a widget as HTML, it only renders very minimal markup -
 Django doesn't add class names, or any other widget-specific attributes. This
 means, for example, that all :class:`TextInput` widgets will appear the same
-on your Web pages.
+on your web pages.
 
 There are two ways to customize widgets: :ref:`per widget instance
 <styling-widget-instances>` and :ref:`per widget class <styling-widget-classes>`.
@@ -145,7 +145,7 @@ provided for each widget will be rendered exactly the same::
     <tr><th>Url:</th><td><input type="url" name="url" required></td></tr>
     <tr><th>Comment:</th><td><input type="text" name="comment" required></td></tr>
 
-On a real Web page, you probably don't want every widget to look the same. You
+On a real web page, you probably don't want every widget to look the same. You
 might want a larger input element for the comment, and you might want the
 'name' widget to have some special CSS class. It is also possible to specify
 the 'type' attribute to take advantage of the new HTML5 input types.  To do
diff --git a/docs/ref/logging.txt b/docs/ref/logging.txt
index 7fdb7791f5..6b8e12ef46 100644
--- a/docs/ref/logging.txt
+++ b/docs/ref/logging.txt
@@ -275,7 +275,7 @@ Python logging module <python:logging.handlers>`.
 
     The ``include_html`` argument of ``AdminEmailHandler`` is used to
     control whether the traceback email includes an HTML attachment
-    containing the full content of the debug Web page that would have been
+    containing the full content of the debug web page that would have been
     produced if :setting:`DEBUG` were ``True``. To set this value in your
     configuration, include it in the handler definition for
     ``django.utils.log.AdminEmailHandler``, like this::
diff --git a/docs/ref/middleware.txt b/docs/ref/middleware.txt
index d8eb889300..412f8a99a4 100644
--- a/docs/ref/middleware.txt
+++ b/docs/ref/middleware.txt
@@ -185,7 +185,7 @@ Security middleware
 
 .. warning::
     If your deployment situation allows, it's usually a good idea to have your
-    front-end Web server perform the functionality provided by the
+    front-end web server perform the functionality provided by the
     ``SecurityMiddleware``. That way, if there are requests that aren't served
     by Django (such as static media or user-uploaded files), they will have
     the same protections as requests to your Django application.
@@ -222,7 +222,7 @@ you set the :setting:`SECURE_HSTS_SECONDS` setting to a non-zero integer value.
 
 When enabling HSTS, it's a good idea to first use a small value for testing,
 for example, :setting:`SECURE_HSTS_SECONDS = 3600<SECURE_HSTS_SECONDS>` for one
-hour. Each time a Web browser sees the HSTS header from your site, it will
+hour. Each time a web browser sees the HSTS header from your site, it will
 refuse to communicate non-securely (using HTTP) with your domain for the given
 period of time. Once you confirm that all assets are served securely on your
 site (i.e. HSTS didn't break anything), it's a good idea to increase this value
@@ -413,10 +413,10 @@ is ``True``.
 
 Note that in most deployment situations where Django isn't involved in serving
 user-uploaded files, this setting won't help you. For example, if your
-:setting:`MEDIA_URL` is served directly by your front-end Web server (nginx,
+:setting:`MEDIA_URL` is served directly by your front-end web server (nginx,
 Apache, etc.) then you'd want to set this header there. On the other hand, if
 you are using Django to do something like require authorization in order to
-download files and you cannot set the header using your Web server, this
+download files and you cannot set the header using your web server, this
 setting will be useful.
 
 __ https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options
@@ -486,17 +486,17 @@ Authentication middleware
 .. class:: AuthenticationMiddleware
 
 Adds the ``user`` attribute, representing the currently-logged-in user, to
-every incoming ``HttpRequest`` object. See :ref:`Authentication in Web requests
+every incoming ``HttpRequest`` object. See :ref:`Authentication in web requests
 <auth-web-requests>`.
 
 .. class:: RemoteUserMiddleware
 
-Middleware for utilizing Web server provided authentication. See
+Middleware for utilizing web server provided authentication. See
 :doc:`/howto/auth-remote-user` for usage details.
 
 .. class:: PersistentRemoteUserMiddleware
 
-Middleware for utilizing Web server provided authentication when enabled only
+Middleware for utilizing web server provided authentication when enabled only
 on the login page. See :ref:`persistent-remote-user-middleware-howto` for usage
 details.
 
diff --git a/docs/ref/models/fields.txt b/docs/ref/models/fields.txt
index 9847560504..d7336d7001 100644
--- a/docs/ref/models/fields.txt
+++ b/docs/ref/models/fields.txt
@@ -857,7 +857,7 @@ takes a few steps:
    full path to a directory where you'd like Django to store uploaded files.
    (For performance, these files are not stored in the database.) Define
    :setting:`MEDIA_URL` as the base public URL of that directory. Make sure
-   that this directory is writable by the Web server's user account.
+   that this directory is writable by the web server's user account.
 
 #. Add the :class:`FileField` or :class:`ImageField` to your model, defining
    the :attr:`~FileField.upload_to` option to specify a subdirectory of
@@ -900,7 +900,7 @@ Note that whenever you deal with uploaded files, you should pay close attention
 to where you're uploading them and what type of files they are, to avoid
 security holes. *Validate all uploaded files* so that you're sure the files are
 what you think they are. For example, if you blindly let somebody upload files,
-without validation, to a directory that's within your Web server's document
+without validation, to a directory that's within your web server's document
 root, then somebody could upload a CGI or PHP script and execute that script by
 visiting its URL on your site. Don't allow that.
 
diff --git a/docs/ref/models/instances.txt b/docs/ref/models/instances.txt
index 6cf861638b..ea503b6c26 100644
--- a/docs/ref/models/instances.txt
+++ b/docs/ref/models/instances.txt
@@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
 query </topics/db/queries>` guides, so you'll probably want to read and
 understand those documents before reading this one.
 
-Throughout this reference we'll use the :ref:`example Weblog models
+Throughout this reference we'll use the :ref:`example blog models
 <queryset-model-example>` presented in the :doc:`database query guide
 </topics/db/queries>`.
 
diff --git a/docs/ref/models/querysets.txt b/docs/ref/models/querysets.txt
index efa28ee145..4dafa7b3bf 100644
--- a/docs/ref/models/querysets.txt
+++ b/docs/ref/models/querysets.txt
@@ -9,7 +9,7 @@ material presented in the :doc:`model </topics/db/models>` and :doc:`database
 query </topics/db/queries>` guides, so you'll probably want to read and
 understand those documents before reading this one.
 
-Throughout this reference we'll use the :ref:`example Weblog models
+Throughout this reference we'll use the :ref:`example blog models
 <queryset-model-example>` presented in the :doc:`database query guide
 </topics/db/queries>`.
 
@@ -2685,7 +2685,7 @@ For example, to delete all the entries in a particular blog::
 
     # Delete all the entries belonging to this Blog.
     >>> Entry.objects.filter(blog=b).delete()
-    (4, {'weblog.Entry': 2, 'weblog.Entry_authors': 2})
+    (4, {'blog.Entry': 2, 'blog.Entry_authors': 2})
 
 By default, Django's :class:`~django.db.models.ForeignKey` emulates the SQL
 constraint ``ON DELETE CASCADE`` — in other words, any objects with foreign
@@ -2696,7 +2696,7 @@ For example::
 
     # This will delete all Blogs and all of their Entry objects.
     >>> blogs.delete()
-    (5, {'weblog.Blog': 1, 'weblog.Entry': 2, 'weblog.Entry_authors': 2})
+    (5, {'blog.Blog': 1, 'blog.Entry': 2, 'blog.Entry_authors': 2})
 
 This cascade behavior is customizable via the
 :attr:`~django.db.models.ForeignKey.on_delete` argument to the
diff --git a/docs/ref/request-response.txt b/docs/ref/request-response.txt
index 747cb0ea6b..5da858720b 100644
--- a/docs/ref/request-response.txt
+++ b/docs/ref/request-response.txt
@@ -57,10 +57,10 @@ All attributes should be considered read-only, unless stated otherwise.
 
 .. attribute:: HttpRequest.path_info
 
-    Under some Web server configurations, the portion of the URL after the
+    Under some web server configurations, the portion of the URL after the
     host name is split up into a script prefix portion and a path info
     portion. The ``path_info`` attribute always contains the path info portion
-    of the path, no matter what Web server is being used. Using this instead
+    of the path, no matter what web server is being used. Using this instead
     of :attr:`~HttpRequest.path` can make your code easier to move between
     test and deployment servers.
 
@@ -151,7 +151,7 @@ All attributes should be considered read-only, unless stated otherwise.
     * ``QUERY_STRING`` -- The query string, as a single (unparsed) string.
     * ``REMOTE_ADDR`` -- The IP address of the client.
     * ``REMOTE_HOST`` -- The hostname of the client.
-    * ``REMOTE_USER`` -- The user authenticated by the Web server, if any.
+    * ``REMOTE_USER`` -- The user authenticated by the web server, if any.
     * ``REQUEST_METHOD`` -- A string such as ``"GET"`` or ``"POST"``.
     * ``SERVER_NAME`` -- The hostname of the server.
     * ``SERVER_PORT`` -- The port of the server (as a string).
@@ -167,7 +167,7 @@ All attributes should be considered read-only, unless stated otherwise.
     name, so you won't see them in ``META``. This prevents header-spoofing
     based on ambiguity between underscores and dashes both being normalizing to
     underscores in WSGI environment variables. It matches the behavior of
-    Web servers like Nginx and Apache 2.4+.
+    web servers like Nginx and Apache 2.4+.
 
     :attr:`HttpRequest.headers` is a simpler way to access all HTTP-prefixed
     headers, plus ``CONTENT_LENGTH`` and ``CONTENT_TYPE``.
@@ -365,7 +365,7 @@ Methods
         Mixing HTTP and HTTPS on the same site is discouraged, therefore
         :meth:`~HttpRequest.build_absolute_uri()` will always generate an
         absolute URI with the same scheme the current request has. If you need
-        to redirect users to HTTPS, it's best to let your Web server redirect
+        to redirect users to HTTPS, it's best to let your web server redirect
         all HTTP traffic to HTTPS.
 
 .. method:: HttpRequest.get_signed_cookie(key, default=RAISE_ERROR, salt='', max_age=None)
@@ -662,7 +662,7 @@ Typical usage is to pass the contents of the page, as a string, bytestring,
 or :class:`memoryview`, to the :class:`HttpResponse` constructor::
 
     >>> from django.http import HttpResponse
-    >>> response = HttpResponse("Here's the text of the Web page.")
+    >>> response = HttpResponse("Here's the text of the web page.")
     >>> response = HttpResponse("Text only, please.", content_type="text/plain")
     >>> response = HttpResponse(b'Bytestrings are also accepted.')
     >>> response = HttpResponse(memoryview(b'Memoryview as well.'))
@@ -671,7 +671,7 @@ But if you want to add content incrementally, you can use ``response`` as a
 file-like object::
 
     >>> response = HttpResponse()
-    >>> response.write("<p>Here's the text of the Web page.</p>")
+    >>> response.write("<p>Here's the text of the web page.</p>")
     >>> response.write("<p>Here's another paragraph.</p>")
 
 Passing iterators
diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index ba2a787b53..47718a6838 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -33,7 +33,7 @@ a model object and return its URL. This is a way of inserting or overriding
 ``get_absolute_url()`` methods on a per-installation basis. Example::
 
     ABSOLUTE_URL_OVERRIDES = {
-        'blogs.weblog': lambda o: "/blogs/%s/" % o.slug,
+        'blogs.blog': lambda o: "/blogs/%s/" % o.slug,
         'news.story': lambda o: "/stories/%s/%s/" % (o.pub_year, o.slug),
     }
 
diff --git a/docs/ref/templates/api.txt b/docs/ref/templates/api.txt
index 01748715b7..7e9812fffb 100644
--- a/docs/ref/templates/api.txt
+++ b/docs/ref/templates/api.txt
@@ -805,7 +805,7 @@ directories::
     ]
 
 Your templates can go anywhere you want, as long as the directories and
-templates are readable by the Web server. They can have any extension you want,
+templates are readable by the web server. They can have any extension you want,
 such as ``.html`` or ``.txt``, or they can have no extension at all.
 
 Note that these paths should use Unix-style forward slashes, even on Windows.
diff --git a/docs/ref/templates/language.txt b/docs/ref/templates/language.txt
index 04b363c0cf..ffddd7435a 100644
--- a/docs/ref/templates/language.txt
+++ b/docs/ref/templates/language.txt
@@ -471,10 +471,10 @@ That would result in a rendered template like this::
 
     Hello, <b>username
 
-...which, in turn, would result in the remainder of the Web page being bolded!
+...which, in turn, would result in the remainder of the web page being bolded!
 
 Clearly, user-submitted data shouldn't be trusted blindly and inserted directly
-into your Web pages, because a malicious user could use this kind of hole to
+into your web pages, because a malicious user could use this kind of hole to
 do potentially bad things. This type of security exploit is called a
 `Cross Site Scripting`_ (XSS) attack.
 
diff --git a/docs/ref/urlresolvers.txt b/docs/ref/urlresolvers.txt
index b9af97f790..891142df7f 100644
--- a/docs/ref/urlresolvers.txt
+++ b/docs/ref/urlresolvers.txt
@@ -216,7 +216,7 @@ Normally, you should always use :func:`~django.urls.reverse` to define URLs
 within your application. However, if your application constructs part of the
 URL hierarchy itself, you may occasionally need to generate URLs. In that
 case, you need to be able to find the base URL of the Django project within
-its Web server (normally, :func:`~django.urls.reverse` takes care of this for
+its web server (normally, :func:`~django.urls.reverse` takes care of this for
 you). In that case, you can call ``get_script_prefix()``, which will return
 the script prefix portion of the URL for your Django project. If your Django
 project is at the root of its web server, this is always ``"/"``.
diff --git a/docs/ref/urls.txt b/docs/ref/urls.txt
index 6d0110af76..2bfb80c714 100644
--- a/docs/ref/urls.txt
+++ b/docs/ref/urls.txt
@@ -21,7 +21,7 @@ Returns an element for inclusion in ``urlpatterns``. For example::
         path('bio/<username>/', views.bio, name='bio'),
         path('articles/<slug:title>/', views.article, name='article-detail'),
         path('articles/<slug:title>/<int:section>/', views.section, name='article-section'),
-        path('weblog/', include('blog.urls')),
+        path('blog/', include('blog.urls')),
         ...
     ]
 
@@ -58,7 +58,7 @@ Returns an element for inclusion in ``urlpatterns``. For example::
     urlpatterns = [
         re_path(r'^index/$', views.index, name='index'),
         re_path(r'^bio/(?P<username>\w+)/$', views.bio, name='bio'),
-        re_path(r'^weblog/', include('blog.urls')),
+        re_path(r'^blog/', include('blog.urls')),
         ...
     ]
 
diff --git a/docs/ref/utils.txt b/docs/ref/utils.txt
index 485009bde6..3a7f58c5f7 100644
--- a/docs/ref/utils.txt
+++ b/docs/ref/utils.txt
@@ -300,7 +300,7 @@ Sample usage::
     >>> feed = feedgenerator.Rss201rev2Feed(
     ...     title="Poynter E-Media Tidbits",
     ...     link="http://www.poynter.org/column.asp?id=31",
-    ...     description="A group Weblog by the sharpest minds in online media/journalism/publishing.",
+    ...     description="A group blog by the sharpest minds in online media/journalism/publishing.",
     ...     language="en",
     ... )
     >>> feed.add_item(