Merge pull request #1379 from PrernaSingh587/patch-6

Minor Fixes in guidelines.rst

Author: viniciusdc

src/orga/guidelines.rst

@@ -7,8 +7,8 @@ Transferring to conda-forge
 This document intends to layout some guidelines on the transfer of
 `conda-recipes <https://github.com/conda/conda-recipes>`__ and
 `anaconda-recipes <https://github.com/ContinuumIO/anaconda-recipes>`__
-to conda-forge. These aren't hard and fast rules, instead are open reasonable
-interpretation and reviewer judgement.
+to conda-forge. These aren't hard and fast rules, instead are open to reasonable
+interpretation and reviewer's judgement.
 
 It is anticipated that almost all recipes from those repos shall be
 proposed for addition here, though it may be decided that a few don't
@@ -19,16 +19,16 @@ to see who had made changes to the recipe in the past. Anyone who has
 touched the recipe should be pinged about it, so that they can be added here. They
 should also be consulted with regards, if the recipe needs any
 tweaks before being added. Also, they should be asked if they would
-like to be added as maintainers. Only if they give express permission,
-to take up the role as a maintainer the only they should be added in the maintainer list.
+like to be added as maintainers. If they give their consent
+to take up the role as a maintainer, only then they should be added in the maintainer list.
 
 In all cases while porting a recipe, you should add yourself as a
 maintainer. Some contributors to these repos might be quite prolific, but may
 not be as actively engaged. If they specify they only want to be contacted
-for certain recipes or none at all, please respect their wishes add them too.
+for certain recipes or none at all, please respect their wishes and add them too.
 Make note of what recipes (if any) they would like to be notified for. If
 they are no longer interested in any conda recipes, make that note here
-as well. Before contacting anyone please consult the list in this
+as well. Before contacting anyone, please consult the list in this
 `issue <https://github.com/conda-forge/staged-recipes/issues/139>`__
 to see if that contributor has restrictions.
 
@@ -38,9 +38,9 @@ The section order should go ``package``, ``source``, ``build``,
 is recommended to add a ``build`` section with the ``number`` set to
 ``0`` explicitly even if the rest is unneeded. If there is no build for
 Windows, make sure to add ``skip: True  # [win]`` to the ``build``
-section. The ``about`` section must have the ``home`` URL (verify the
-URL is still correct), ``license`` (verify the correct license is present),
-and a one sentence (or few word) ``summary``. When specifying the version it
+section. The ``about`` section must have the ``home`` URL (verify if the
+URL is still correct), ``license`` (verify if the correct license is present),
+and a one sentence (or few words) ``summary``. When specifying the version, it
 is strongly recommended that jinja templating be used to set the version
 at the top (e.g. ``{% set version = "0.10.1" %}``) and then replace all
 uses of the version with ``{{ version }}``. Preference should be given to
@@ -49,15 +49,15 @@ all links to compressed source balls allow for easy changing of the version
 (using latest is not acceptable). Also, a checksum should be included with
 all compressed source balls to allow for verification of downloads.
 
-It is required to add tests with all packages. These can include but are
-not limited to checking libraries are installed, python imports, simple
+It is required to add tests with all packages. These can include, but are
+not limited to, checking if libraries are installed, python imports, simple
 code snippet to compile or run a basic test, command line usage (checking
-help or version). It is suggested that compiled code run all tests (e.g.
+help or version). It is suggested to get the compiled code to run all tests (e.g.
 ``make check``) to ensure it was built properly. This normally should
 happen in the build.
 
 It is possible, though not recommended, to include multiple recipes into a
-single pull request on staged-recipes. conda-build-all is used to determine
+single pull request on `staged-recipes <https://github.com/conda-forge/staged-recipes>`__. ``conda-build-all`` is used to determine
 the build order and the necessary build matrix (e.g. which python versions to
 build against). From a practical perspective, there are limitations on the
 continuous integration resources and also on what reviewers are able/willing
@@ -70,7 +70,7 @@ suitable order.
 None of this is to say that one can't add multiple recipes in a single
 pull request. One certainly can do this and it can work, but the
 recommendation is to open a PR with one recipe first, and to ping
-@conda-forge/core to ask for agreement about adding one or two additional
+**@conda-forge/core** to ask for agreement about adding one or two additional
 recipes.