[automake-commit] branch master updated: contrib/README: fix and clarify the English

[Karl Berry]

This is an automated email from the git hooks/post-receive script.

karl pushed a commit to branch master
in repository automake.

View the commit online:
https://git.savannah.gnu.org/gitweb/?p=automake.git;a=commitdiff;h=e30c0962414a56bd03c13db496f5f2e8735097cf

The following commit(s) were added to refs/heads/master by this push:
     new e30c096  contrib/README: fix and clarify the English
e30c096 is described below

commit e30c0962414a56bd03c13db496f5f2e8735097cf
Author: Reuben Thomas <rrt@sc3d.org>
AuthorDate: Thu Oct 15 13:11:11 2020 +0100

    contrib/README: fix and clarify the English
---
 contrib/README | 35 ++++++++++++++++-------------------
 1 file changed, 16 insertions(+), 19 deletions(-)

diff --git a/contrib/README b/contrib/README
index a4d7eeb..f43e1da 100644
--- a/contrib/README
+++ b/contrib/README
@@ -1,26 +1,23 @@
 This is the 'contrib' directory of the GNU Automake distribution.
 
-Here you'll find additions to the Automake base distribution, in form of
-makefile fragments, m4 macros, scripts, documentation, et cetera.  Such
-addition that might be useful for a significant percentage of its general
-audience, but (for one reason or another) are not deemed appropriate for
-inclusion into the Automake core.
+Here you'll find additions to the Automake base distribution, in the form of
+makefile fragments, m4 macros, scripts, documentation, et cetera: additions
+that might be handy to many users, but (for one reason or another) are not
+deemed appropriate for inclusion into the Automake core.
 
-There are several reasons for which a feature can be kept in contrib:
+There are several reasons that a feature might be kept in contrib:
 
   1. The long-term usefulness of the feature is debatable and uncertain;
-     on-field and real-word testing are necessary to prove or disprove
-     its usefulness, before the feature can be committed into the Automake
-     core (as doing so too early would later force us to continue the
-     support for backward-compatibility, even if the features proves
-     flawed or fails to attract widespread use).
+     real-world testing is necessary to prove or disprove its usefulness,
+     before the feature can be committed into the Automake core (as doing so
+     too early would later force us to continue support for
+     backward-compatibility, even if the feature proved flawed or fails to
+     attract widespread use).
 
-  2. The APIs or overall design of the feature are still unstable, and
-     need on-field testing to iron warts and usability bugs, or uncover
-     potential flaws.
+  2. The APIs or overall design of the feature are still unstable, and need
+     testing to iron out warts and usability bugs, or uncover potential flaws.
 
-  3. The feature was an historical one, mostly obsoleted but still used
-     "here and there" in the wild; so we want to to deprecate it and
-     remove it from the Automake core, but cannot remove it altogether,
-     for the sake of those still-existing usage.  So it gets moved in
-     contrib.
+  3. The feature was an historical one, mostly obsolete but still used in the
+     wild.  We want to deprecate it and remove it from the Automake core, but
+     cannot remove it altogether, for the sake of the existing usage, so it
+     gets moved in contrib.