couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From kxe...@apache.org
Subject [2/4] documentation commit: updated refs/heads/master to ddf2481
Date Sat, 22 Aug 2015 11:43:18 GMT
Fix typos, spelling and grammatical errors.


Project: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/commit/87b56da6
Tree: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/tree/87b56da6
Diff: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/diff/87b56da6

Branch: refs/heads/master
Commit: 87b56da6043340eb0736bdaff9d879c454cd6fb6
Parents: 18cc926
Author: Jonathan Hall <jhall@efolder.net>
Authored: Mon Aug 17 17:11:53 2015 -0500
Committer: Jonathan Hall <jhall@efolder.net>
Committed: Tue Aug 18 12:28:24 2015 -0500

----------------------------------------------------------------------
 src/api/server/authn.rst     | 10 +++----
 src/config/http-handlers.rst |  4 +--
 src/config/http.rst          |  6 ++--
 src/config/intro.rst         |  2 +-
 src/config/query-servers.rst |  2 +-
 src/couchapp/ddocs.rst       | 59 +++++++++++++++++++--------------------
 src/couchapp/views/intro.rst | 16 +++++------
 src/couchapp/views/joins.rst | 20 ++++++-------
 src/couchapp/views/nosql.rst |  9 +++---
 src/fauxton/install.rst      |  2 +-
 src/intro/futon.rst          |  2 +-
 src/intro/overview.rst       |  7 +++--
 src/intro/security.rst       | 50 ++++++++++++++++-----------------
 src/intro/tour.rst           |  2 +-
 src/whatsnew/0.11.rst        |  2 +-
 15 files changed, 97 insertions(+), 96 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/api/server/authn.rst
----------------------------------------------------------------------
diff --git a/src/api/server/authn.rst b/src/api/server/authn.rst
index 26e2657..09567da 100644
--- a/src/api/server/authn.rst
+++ b/src/api/server/authn.rst
@@ -19,8 +19,8 @@ Authentication
 Interfaces for obtaining session and authorization data.
 
 .. note::
-    We're also strongly recommend you to :ref:`setup SSL <config/ssl>` to
-    improve all authentication methods security.
+    We also strongly recommend you :ref:`set up SSL <config/ssl>` to
+    improve all authentication methods' security.
 
 .. _api/auth/basic:
 
@@ -30,7 +30,7 @@ Basic Authentication
 `Basic authentication`_ (:rfc:`2617`) is a quick and simple way to authenticate
 with CouchDB. The main drawback is the need to send user credentials with each
 request which may be insecure and could hurt operation performance (since
-CouchDB must compute password hash with every request):
+CouchDB must compute the password hash with every request):
 
 **Request**:
 
@@ -72,10 +72,10 @@ Cookie Authentication
 For cookie authentication (:rfc:`2109`) CouchDB generates a token that the
 client can use for the next few requests to CouchDB. Tokens are valid until
 a timeout. When CouchDB sees a valid token in a subsequent request, it will
-authenticate user by this token without requesting the password again. By
+authenticate the user by this token without requesting the password again. By
 default, cookies are valid for 10 minutes, but it's :config:option:`adjustable
 <couch_httpd_auth/timeout>`. Also it's possible to make cookies
-:config:option:`persistent <couch_httpd_auth/allow_persistent_cookies>`
+:config:option:`persistent <couch_httpd_auth/allow_persistent_cookies>`.
 
 To obtain the first token and thus authenticate a user for the first time, the
 `username` and `password` must be sent to the :ref:`_session API

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/config/http-handlers.rst
----------------------------------------------------------------------
diff --git a/src/config/http-handlers.rst b/src/config/http-handlers.rst
index 9dbfcf4..e982a2a 100644
--- a/src/config/http-handlers.rst
+++ b/src/config/http-handlers.rst
@@ -56,7 +56,7 @@ Global HTTP Handlers
 
         .. note::
             Sometimes you don't want to disclose database names for everyone,
-            but you also don't like/want/able to setup any proxies in front of
+            but you also don't like/want/able to set up any proxies in front of
             CouchDB. Removing this handler disables ``_all_dbs`` resource and
             there will be no way to get list of available databases.
 
@@ -123,7 +123,7 @@ Global HTTP Handlers
             [httpd_global_handlers]
             _utils = {couch_httpd_misc_handlers, handle_utils_dir_req, "/usr/share/couchdb/www"}
 
-        In similar way, you may setup custom handler to let CouchDB serve any
+        In similar way, you may set up custom handler to let CouchDB serve any
         static files.
 
     .. config:option:: _uuids

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/config/http.rst
----------------------------------------------------------------------
diff --git a/src/config/http.rst b/src/config/http.rst
index 6abeea0..f19ed14 100644
--- a/src/config/http.rst
+++ b/src/config/http.rst
@@ -57,7 +57,7 @@ HTTP Server Options
             [httpd]
             bind_address = 127.0.0.1
 
-        To let CouchDB listen any available IP address, just setup ``0.0.0.0``
+        To let CouchDB listen any available IP address, just set up ``0.0.0.0``
         value::
 
             [httpd]
@@ -229,7 +229,7 @@ Secure Socket Level Options
 .. config:section:: ssl :: Secure Socket Level Options
 
     CouchDB supports SSL natively. All your secure connection needs can now be
-    served without needing to setup and maintain a separate proxy server that
+    served without needing to set up and maintain a separate proxy server that
     handles SSL.
 
     SSL setup can be tricky, but the configuration in CouchDB was designed to
@@ -263,7 +263,7 @@ Secure Socket Level Options
         [daemons]
         httpsd = {couch_httpd, start_link, [https]}
 
-    Next, under ``[ssl]`` section setup newly generated certificates::
+    Next, under the ``[ssl]`` section set up the newly generated certificates::
 
         [ssl]
         cert_file = /etc/couchdb/cert/couchdb.pem

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/config/intro.rst
----------------------------------------------------------------------
diff --git a/src/config/intro.rst b/src/config/intro.rst
index ba19bd4..b837644 100644
--- a/src/config/intro.rst
+++ b/src/config/intro.rst
@@ -112,7 +112,7 @@ For example::
 
 Each configuration file line may contains `section` definition, `parameter`
 specification, empty (space and newline characters only) or `commented` line.
-You can setup `inline` commentaries for `sections` or `parameters`.
+You can set up `inline` commentaries for `sections` or `parameters`.
 
 The `section` defines group of parameters that are belongs to some specific
 CouchDB subsystem. For instance, :section:`httpd` section holds not only HTTP

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/config/query-servers.rst
----------------------------------------------------------------------
diff --git a/src/config/query-servers.rst b/src/config/query-servers.rst
index 6eee3e9..88f2344 100644
--- a/src/config/query-servers.rst
+++ b/src/config/query-servers.rst
@@ -43,7 +43,7 @@ Query Servers Definition
       query servers in wild. This value is also used for `ddoc` field
       ``language`` to determine which query server processes the functions.
 
-      Note, that you may setup multiple query servers for the same programming
+      Note, that you may set up multiple query servers for the same programming
       language, but you have to name them different (like `python-dev` etc.).
 
     - ``PATH``: is a system path to the executable binary program that runs the

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/couchapp/ddocs.rst
----------------------------------------------------------------------
diff --git a/src/couchapp/ddocs.rst b/src/couchapp/ddocs.rst
index 7e2828b..24afad3 100644
--- a/src/couchapp/ddocs.rst
+++ b/src/couchapp/ddocs.rst
@@ -66,17 +66,16 @@ of a document with a `type` of "post". Note that :func:`emit` may be called
many
 times for a single document, so the same document may be available by several
 different keys.
 
-Also keep in mind that each document is *sealed* to prevent situation when one
-map function changes document state and the other one received a modified
-version.
+Also keep in mind that each document is *sealed* to prevent the situation where
+one map function changes document state and another receives a modified version.
 
 For efficiency reasons, documents are passed to a group of map functions -
 each document is processed by group of map functions from all views of
 related design document. This means that if you trigger index update for one
 view in ddoc, all others will get updated too.
 
-Since `1.1.0` release `map` function supports
-:ref:`CommonJS <commonjs>` modules and access to :func:`require` function.
+Since version `1.1.0`, `map` supports :ref:`CommonJS <commonjs>` modules and
+the :func:`require` function.
 
 .. _reducefun:
 
@@ -85,7 +84,7 @@ Reduce and rereduce functions
 
 .. function:: redfun(keys, values[, rereduce])
 
-    :param keys: Array of pairs docid-key for related map function result.
+    :param keys: Array of pairs of docid-key for related map function results.
                  Always ``null`` if rereduce is running (has ``true`` value).
     :param values: Array of map function result values.
     :param rereduce: Boolean sign of rereduce run.
@@ -93,23 +92,23 @@ Reduce and rereduce functions
     :return: Reduces `values`
 
 Reduce functions takes two required arguments of keys and values lists - the
-result of the related map function - and optional third one which indicates if
-`rereduce` mode is active or not. `Rereduce` is using for additional reduce
+result of the related map function - and an optional third value which indicates
+if `rereduce` mode is active or not. `Rereduce` is used for additional reduce
 values list, so when it is ``true`` there is no information about related `keys`
 (first argument is ``null``).
 
-Note, that if produced result by `reduce` function is longer than initial
+Note that if the result of a `reduce` function is longer than the initial
 values list then a Query Server error will be raised. However, this behavior
-could be disabled by setting ``reduce_limit`` config option to ``false``:
+can be disabled by setting ``reduce_limit`` config option to ``false``:
 
 .. code-block:: ini
 
     [query_server_config]
     reduce_limit = false
 
-While disabling ``reduce_limit`` might be useful for debug proposes, remember,
-that main task of reduce functions is to *reduce* mapped result, not to make it
-even bigger. Generally, your reduce function should converge rapidly to a single
+While disabling ``reduce_limit`` might be useful for debug proposes, remember
+that the main task of reduce functions is to *reduce* mapped result, not to make
+them bigger. Generally, your reduce function should converge rapidly to a single
 value - which could be an array or similar object.
 
 .. _reducefun/builtin:
@@ -118,9 +117,9 @@ Builtin reduce functions
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
 Additionally, CouchDB has three built-in reduce functions. These are implemented
-in Erlang and runs inside CouchDB, so they are much faster than the equivalent
+in Erlang and run inside CouchDB, so they are much faster than the equivalent
 JavaScript functions: ``_sum``, ``_count`` and ``_stats``. Their equivalents in
-JavaScript below:
+JavaScript:
 
 .. code-block:: javascript
 
@@ -171,17 +170,17 @@ JavaScript below:
     **Why don't reduce functions support CommonJS modules?**
 
     While `map` functions have limited access to stored modules through
-    :func:`require` function there is no such feature for `reduce` functions.
-    The reason lies deep inside in the mechanism how `map` and `reduce`
-    functions are processed by the Query Server. Let's take a look on `map`
+    :func:`require`, there is no such feature for `reduce` functions.
+    The reason lies deep inside the way `map` and `reduce`
+    functions are processed by the Query Server. Let's take a look at `map`
     functions first:
 
     #. CouchDB sends all `map` functions for a processed design document to
        Query Server.
     #. Query Server handles them one by one, compiles and puts them onto an
        internal stack.
-    #. After all `map` functions had been processed, CouchDB will send the
-       remaining documents to index one by one.
+    #. After all `map` functions have been processed, CouchDB will send the
+       remaining documents to index, one by one.
     #. Query Server receives the document object and applies it to every
        function from the stack. The emitted results are then joined into a
        single array and sent back to CouchDB.
@@ -189,8 +188,8 @@ JavaScript below:
     Now let's see how `reduce` functions are handled:
 
     #. CouchDB sends *as single command* list of available `reduce` functions
-       with result list of key-value pairs that was previously received as
-       result of `map` functions work.
+       with result list of key-value pairs that was previously received as the
+       result of `map` functions' work.
     #. Query Server compiles reduce functions and applies them to key-value
        lists. Reduced result is sent back to CouchDB.
 
@@ -217,7 +216,7 @@ Show functions
     :rtype: object or string
 
 Show functions are used to represent documents in various formats, commonly as
-HTML page with nicer formatting. They can also be used to run server-side
+HTML pages with nice formatting. They can also be used to run server-side
 functions without requiring a pre-existing document.
 
 Basic example of show function could be:
@@ -397,8 +396,8 @@ Update functions
     :returns: Two-element array: the first element is the (updated or new)
       document, which is committed to the database. If the first element
       is ``null`` no document will be committed to the database.
-      If you are updating an existing, it should already have an ``_id``
-      set, and if you are creating a new document, make sure to set its
+      If you are updating an existing document, it should already have an
+      ``_id`` set, and if you are creating a new document, make sure to set its
       ``_id`` to something, either generated based on the input or the
       ``req.uuid`` provided. The second element is the response that will
       be sent back to the caller.
@@ -491,7 +490,7 @@ about "new mails"::
     ],
     "last_seq":27}
 
-Note that the value of ``last_seq`` is 27, but we'd received only two records.
+Note that the value of ``last_seq`` is 27, but we received only two records.
 Seems like any other changes were for documents that haven't passed our filter.
 
 We probably need to filter the changes feed of our mailbox by more than a single
@@ -501,7 +500,7 @@ mails, and so on. Creating a lot of similar functions that actually do
similar
 work isn't good idea - so we need a dynamic filter.
 
 You may have noticed that filter functions take a second argument named
-:ref:`request <request_object>` - it allows creating dynamic filters
+:ref:`request <request_object>`. This allows the creation of dynamic filters
 based on query parameters, :ref:`user context <userctx_object>` and more.
 
 The dynamic version of our filter looks like this:
@@ -554,8 +553,8 @@ View filters
 
 View filters are the same as above, with one small difference: they use
 views `map` function instead to `filter` one to process the changes feed. Each
-time when a key-value pair could be emitted, a change is returned. This allows
-to avoid creating filter functions that are mostly does same works as views.
+time a key-value pair could be emitted, a change is returned. This allows us
+to avoid creating filter functions that mostly do the same works as views.
 
 To use them just specify `_view` value for ``filter`` parameter and
 `designdoc/viewname` for ``view`` one::
@@ -752,7 +751,7 @@ modified by a user with the ``_admin`` role:
     }
 
 .. note::
-    The ``return`` statement used only for function, it has no impact on
+    The ``return`` statement is used only for function, it has no impact on
     the validation process.
 
 .. seealso::

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/couchapp/views/intro.rst
----------------------------------------------------------------------
diff --git a/src/couchapp/views/intro.rst b/src/couchapp/views/intro.rst
index fd9b326..3ffaa66 100644
--- a/src/couchapp/views/intro.rst
+++ b/src/couchapp/views/intro.rst
@@ -12,9 +12,9 @@
 
 .. _views/intro:
 
-===========================
-Introduction Into The Views
-===========================
+=====================
+Introduction to Views
+=====================
 
 Views are useful for many purposes:
 
@@ -418,8 +418,8 @@ on the ``rereduce`` parameter:
     }
 
 .. note::
-    JavaScript function about could be effectively replaced by builtin
-    ``_count`` one.
+    The JavaScript function above could be effectively replaced by the builtin
+    ``_count``.
 
 .. figure:: ../../../images/views-intro-01.png
     :align: center
@@ -460,7 +460,7 @@ number ``1`` for each key, as there are no exactly duplicated keys.
 Reduce/Rereduce
 ===============
 
-We briefly talked about the ``rereduce`` parameter to your reduce function.
+We briefly talked about the ``rereduce`` parameter to the reduce function.
 We’ll explain what’s up with it in this section. By now, you should have learned
 that your view result is stored in B-tree index structure for efficiency.
 The existence and use of the ``rereduce`` parameter is tightly coupled to how
@@ -541,7 +541,7 @@ the beginning and the end are the same value). It concludes that it has
to use
 the "chinese" element’s value and the other node’s value and run them through
 the reduce function with the ``rereduce`` parameter set to true.
 
-The reduce function effectively calculates 3 + 1 on query time and returns the
+The reduce function effectively calculates 3 + 1 at query time and returns the
 desired result. The next example shows some pseudocode that shows the last
 invocation of the reduce function with actual values:
 
@@ -591,7 +591,7 @@ This translates to Figure 4, “An overflowing reduce index”.
 
 We hope you get the picture. The way the B-tree storage works means that if you
 don’t actually reduce your data in the reduce function, you end up having
-CouchDB copy huge amounts of data around that grow linearly, if not faster
+CouchDB copy huge amounts of data around that grow linearly, if not faster,
 with the number of rows in your view.
 
 CouchDB will be able to compute the final result, but only for views with a few

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/couchapp/views/joins.rst
----------------------------------------------------------------------
diff --git a/src/couchapp/views/joins.rst b/src/couchapp/views/joins.rst
index 0a9ffb4..d991fc5 100644
--- a/src/couchapp/views/joins.rst
+++ b/src/couchapp/views/joins.rst
@@ -163,11 +163,11 @@ Using View Collation
 :Date: 2007-10-05
 :Source: http://www.cmlenz.net/archives/2007/10/couchdb-joins
 
-Just today, there was a discussion on IRC how you'd go about modeling a simple
-blogging system with “post” and “comment” entities, where any blog post might
-have N comments. If you'd be using an SQL database, you'd obviously have two
-tables with foreign keys and you'd be using joins. (At least until you needed
-to add some `denormalization`_).
+Just today, there was a discussion on IRC on how you'd go about modeling a
+simple blogging system with “post” and “comment” entities, where any blog
+post might have N comments. If you'd be using an SQL database, you'd obviously
+have two tables with foreign keys and you'd be using joins. (At least until you
+needed to add some `denormalization`_).
 
 .. _denormalization: http://en.wikipedia.org/wiki/Denormalization
 
@@ -195,7 +195,7 @@ comments inside that document:
 
 .. note::
     Of course the model of an actual blogging system would be more extensive,
-    you'd have tags, timestamps, etc etc. This is just to demonstrate the basics.
+    you'd have tags, timestamps, etc, etc. This is just to demonstrate the basics.
 
 The obvious advantage of this approach is that the data that belongs together
 is stored in one place. Delete the post, and you automatically delete the
@@ -256,7 +256,7 @@ can tell the difference between posts and comments:
     }
 
 The comments themselves are stored in separate documents, which also have a type
-property (this time with the value “comment”), and in addition feature a post
+property (this time with the value “comment”), and additionally feature a post
 property containing the ID of the post document they belong to:
 
 .. code-block:: javascript
@@ -312,7 +312,7 @@ CouchDB server, namely a ``GET`` request to the document. With this second
 approach, we need two requests: a ``GET`` request to the post document, and a
 ``GET`` request to the view that returns all comments for the post.
 
-That is okay, but not quite satisfactory. Just imagine you wanted to added
+That is okay, but not quite satisfactory. Just imagine you wanted to add
 threaded comments: you'd now need an additional fetch per comment. What we'd
 probably want then would be a way to join the blog post and the various comments
 together to be able to retrieve them with a single HTTP request.
@@ -402,8 +402,8 @@ the following:
     }
 
 .. note::
-    The ``...`` placeholder here would contain the complete JSON encoding of the
-    corresponding document
+    The ``...`` placeholders here would contain the complete JSON encoding of the
+    corresponding documents
 
 Now, to get a specific blog post and all associated comments, we'd invoke that
 view with the query string::

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/couchapp/views/nosql.rst
----------------------------------------------------------------------
diff --git a/src/couchapp/views/nosql.rst b/src/couchapp/views/nosql.rst
index efbe8f3..6dfd4c2 100644
--- a/src/couchapp/views/nosql.rst
+++ b/src/couchapp/views/nosql.rst
@@ -18,9 +18,10 @@ View Cookbook for SQL Jockeys
 
 This is a collection of some common SQL queries and how to get the same result
 in CouchDB. The key to remember here is that CouchDB does not work like an SQL
-database at all and that best practices from the SQL world do not translate well
-or at all to CouchDB. This documents’s “cookbook” assumes that you are familiar
-with the CouchDB basics such as creating and updating databases and documents.
+database at all, and that best practices from the SQL world do not translate
+well or at all to CouchDB. This document’s “cookbook” assumes that you are
+familiar with the CouchDB basics such as creating and updating databases and
+documents.
 
 Using Views
 ===========
@@ -215,7 +216,7 @@ Easy.
 Note that you have to emit a value. The view result includes the associated
 document ID in every row. We can use it to look up more data from the document
 itself. We can also use the ``?include_docs=true`` parameter to have CouchDB
-fetch the documents individually for us.
+fetch the individual documents for us.
 
 Look Up by Prefix
 =================

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/fauxton/install.rst
----------------------------------------------------------------------
diff --git a/src/fauxton/install.rst b/src/fauxton/install.rst
index d9b7fcf..eabe14e 100644
--- a/src/fauxton/install.rst
+++ b/src/fauxton/install.rst
@@ -16,7 +16,7 @@
 Installation
 ============
 
-A recent of `node.js`_ and `npm`_ is required.
+Recent versions of `node.js`_ and `npm`_ are required.
 
 .. _node.js: http://nodejs.org/
 .. _npm: https://npmjs.org/doc/README.html

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/intro/futon.rst
----------------------------------------------------------------------
diff --git a/src/intro/futon.rst b/src/intro/futon.rst
index 8c0c984..2d11ffb 100644
--- a/src/intro/futon.rst
+++ b/src/intro/futon.rst
@@ -143,7 +143,7 @@ Configuring Replication
 
 When you click the Replicator option within the Tools menu you are
 presented with the Replicator screen. This allows you to start
-replication between two databases by filling in or select the
+replication between two databases by filling in or selecting the
 appropriate options within the form provided.
 
 .. figure:: ../../images/futon-replform.png

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/intro/overview.rst
----------------------------------------------------------------------
diff --git a/src/intro/overview.rst b/src/intro/overview.rst
index fc0f909..3c0a1d5 100644
--- a/src/intro/overview.rst
+++ b/src/intro/overview.rst
@@ -223,9 +223,10 @@ special formulas, as well as regular fields and blobs.
 Update Validation
 -----------------
 
-As documents written to disk, they can be validated dynamically by javascript
-functions for both security and data validation. When the document passes
-all the formula validation criteria, the update is allowed to continue.
+
+As documents are written to disk, they can be validated dynamically by
+javascript functions for both security and data validation. When the document
+passes all the formula validation criteria, the update is allowed to continue.
 If the validation fails, the update is aborted and the user client gets an
 error response.
 

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/intro/security.rst
----------------------------------------------------------------------
diff --git a/src/intro/security.rst b/src/intro/security.rst
index 8eb565c..cc8c448 100644
--- a/src/intro/security.rst
+++ b/src/intro/security.rst
@@ -103,7 +103,7 @@ Hashing Passwords
 ^^^^^^^^^^^^^^^^^
 
 Seeing the plain-text password is scary, isn't it? No worries, CouchDB doesn't
-show up the plain-text password anywhere. It gets hashed right away. The hash
+show the plain-text password anywhere. It gets hashed right away. The hash
 is that big, ugly, long string that starts out with ``-hashed-``.
 How does that work?
 
@@ -253,9 +253,9 @@ file and are wondering if regular users are also stored there. No, they
are not.
 CouchDB has a special `authentication database`, named ``_users`` by default,
 that stores all registered users as JSON documents.
 
-This special database is a `system database`, this means that while it shares
+This special database is a `system database`. This means that while it shares
 the common :ref:`database API <api/database>`, there are some
-special security-related constraints applied. Below is listed how the
+special security-related constraints applied. Below is a list of how the
 `authentication database` is different from the other databases.
 
 - Only administrators may browse list of all documents
@@ -272,9 +272,9 @@ special security-related constraints applied. Below is listed how the
   </{db}/{docid}>`) documents that they own
 
 These draconian rules are necessary since CouchDB cares about its users'
-personal information and takes not to disclose it to just anyone. Often, user
+personal information and will not disclose it to just anyone. Often, user
 documents contain system information like `login`, `password hash` and `roles`,
-apart from sensitive personal information like: real name, email, phone, special
+apart from sensitive personal information like real name, email, phone, special
 internal identifications and more. This is not information that you
 want to share with the World.
 
@@ -288,8 +288,8 @@ several *mandatory* fields, that CouchDB needs for authentication:
   :ref:`org.couchdb.user`
 - **derived_key** (*string*): `PBKDF2`_ key
 - **name** (*string*): User's name aka login. **Immutable** e.g. you cannot
-  rename existed user - you have to create new one
-- **roles** (*array* of *string*): List of user roles. CouchDB doesn't provides
+  rename an existing user - you have to create new one
+- **roles** (*array* of *string*): List of user roles. CouchDB doesn't provide
   any builtin roles, so you're free to define your own depending on your needs.
   However, you cannot set system roles like ``_admin`` there. Also, only
   administrators may assign roles to users - by default all users have no roles
@@ -298,7 +298,7 @@ several *mandatory* fields, that CouchDB needs for authentication:
 - **password_scheme** (*string*): Password hashing scheme. May be ``simple`` or
   ``pbkdf2``
 - **salt** (*string*): Hash salt. Used for ``simple`` `password_scheme`
-- **type** (*string*): Document type. Constantly have value ``user``
+- **type** (*string*): Document type. Constantly has the value ``user``
 
 Additionally, you may specify any custom fields that relate to the target
 user. This is a good place to store user's private information because only the
@@ -306,22 +306,22 @@ target user and CouchDB administrators may browse it.
 
 .. _org.couchdb.user:
 
-Why ``org.couchdb.user:`` prefix?
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Why the ``org.couchdb.user:`` prefix?
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 The reason there is a special prefix before a user's login name is to have
 namespaces that users belong to. This prefix is designed to prevent
-replication conflicts when you try merging two `_user` databases or more.
+replication conflicts when you try merging two or more `_user` databases.
 
 For current CouchDB releases, all users belong to the same
 ``org.couchdb.user`` namespace and this cannot be changed. This may be changed
 in future releases.
 
-Creating New User
------------------
+Creating a New User
+-------------------
 
 Creating a new user is a very trivial operation. You just need to do a
-:method:`PUT` request with user's data to CouchDB. Let's create a user with
+:method:`PUT` request with the user's data to CouchDB. Let's create a user with
 login `jan` and password `apple`::
 
     curl -X PUT http://localhost:5984/_users/org.couchdb.user:jan \
@@ -380,8 +380,8 @@ Password Changing
 Let's define what is password changing from the point of view of CouchDB and
 the authentication database. Since "users" are "documents", this operation is
 just updating the document with a special field ``password`` which contains
-the *plain text password*. Scared? No need to be, the authentication database
-has a special internal hook on  document update which looks for this field and
+the *plain text password*. Scared? No need to be. The authentication database
+has a special internal hook on document update which looks for this field and
 replaces it with the *secured hash* depending on the chosen ``password_scheme``.
 
 Summarizing the above process - we need to get the document's content, add
@@ -438,11 +438,11 @@ CouchDB should respond with:
     {"ok":true,"name":"jan","roles":[]}
 
 Hooray! You may wonder why this was so complex - we need to retrieve user's
-document,  add a special field to it, post it back - where is that one big
+document, add a special field to it, and post it back. Where is that one big
 button that changes the password without worrying about the document's content?
 Actually, :ref:`Futon <intro/futon>` has one such thing at the bottom right
-corner if are logged in. Using that will hide all the implementation details
-described above and keep it real simple for you.
+corner if you are logged in. Using that will hide all the implementation details
+described above and keep it really simple for you.
 
 .. note::
     There is no password confirmation for API request: you should implement it
@@ -458,9 +458,9 @@ their contact email to let other users get in touch with them. To solve
this
 problem, but still keep sensitive and private information secured, there is
 a special :ref:`configuration <config>` option :config:option:`public_fields
 <couch_httpd_auth/public_fields>`. In this option you may define
-a comma-separated lis of users document fields that will be publicly available.
+a comma-separated list of users document fields that will be publicly available.
 
-Normally, if you request a user document and you're not an administrator or
+Normally, if you request a user document and you're not an administrator or the
 document's owner, CouchDB will respond with :statuscode:`404`::
 
     curl http://localhost:5984/_users/org.couchdb.user:robert
@@ -472,9 +472,9 @@ document's owner, CouchDB will respond with :statuscode:`404`::
 This response is constant for both cases when user exists or doesn't exist for
 security reasons.
 
-Now let's share the field ``name``. First, setup the ``public_fields``
+Now let's share the field ``name``. First, set up the ``public_fields``
 configuration option. Remember, that this action requires administrator
-privileges. The next command will prompt you for user  `admin`'s password:
+privileges. The next command will prompt you for user `admin`'s password:
 
     curl -X PUT http://localhost:5984/_config/couch_http_auth/public_fields \
        -H "Content-Type: application/json" \
@@ -489,8 +489,8 @@ What has changed? Let's check Robert's document once again::
 
     {"_id":"org.couchdb.user:robert","_rev":"6-869e2d3cbd8b081f9419f190438ecbe7","name":"robert"}
 
-Good news! Now, we may read the field ``name`` in *every user document without
-needing to be an administrator*. Keep in mind though not to publish sensitive
+Good news! Now we may read the field ``name`` in *every user document without
+needing to be an administrator*. Keep in mind, though, not to publish sensitive
 information, especially without user's consent!
 
 Authorization

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/intro/tour.rst
----------------------------------------------------------------------
diff --git a/src/intro/tour.rst b/src/intro/tour.rst
index 2df97fe..ea512c7 100644
--- a/src/intro/tour.rst
+++ b/src/intro/tour.rst
@@ -210,7 +210,7 @@ button in the pop up. Make sure to leave the document ID blank,
 and CouchDB will generate a UUID for you.
 
 For demoing purposes, having CouchDB assign a UUID is fine. When you write
-your first programs, we recommend assigning your own UUIDs. If your rely on
+your first programs, we recommend assigning your own UUIDs. If you rely on
 the server to generate the UUID and you end up making two POST requests
 because the first POST request bombed out, you might generate two docs and
 never find out about the first one because only the second one will be

http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/87b56da6/src/whatsnew/0.11.rst
----------------------------------------------------------------------
diff --git a/src/whatsnew/0.11.rst b/src/whatsnew/0.11.rst
index f15e2d0..ae01dd9 100644
--- a/src/whatsnew/0.11.rst
+++ b/src/whatsnew/0.11.rst
@@ -276,7 +276,7 @@ Build and System Integration
 * Bug fix for building couch.app's module list.
 * ETap tests are now run during make distcheck. This included a number of
   updates to the build system to properly support VPATH builds.
-* Gavin McDonald setup a build-bot instance. More info can be found at
+* Gavin McDonald set up a build-bot instance. More info can be found at
   http://ci.apache.org/buildbot.html
 
 Futon


Mime
View raw message