Apply suggestions from code review

Co-authored-by: Francisco Ramírez <[email protected]>
Co-authored-by: SSE4 <[email protected]>

docs/adding_packages/build_and_package.md

@@ -1,7 +1,7 @@
 # Build and Package
 
 This document gathers all the relevant information regarding the general lines to follow while writing either the `build()` or the `package()` methods.
-Both of these methods often take advantage of build helpers build binaries and install to the `package_folder`.
+Both methods often use build helpers to build binaries and install them into the `package_folder`.
 
 <!-- toc -->
 ## Contents
@@ -13,9 +13,9 @@ Both of these methods often take advantage of build helpers build binaries and i
 
 * `build()` method should focus on build only, not installation. During the build, nothing should be written in `package` folder. Installation step should only occur in `package()` method.
 
-* The build itself should only rely on local files. Nothing should be downloaded from internet during this step. If external files are required, they should come from `requirements` or `build_requirements`, in addition to source files downloaded in `source()` or coming from recipe itself.
+* The build itself should only rely on local files. Nothing should be downloaded from the internet during this step. If external files are required, they should come from `requirements` or `build_requirements` in addition to source files downloaded in `source()` or coming from the recipe itself.
 
-* Except CMake and a working build toolchain (compiler, linker, archiver etc), the recipe should not assume that any other build tool is installed on user build machine (like Meson, autotools or pkg-config). On Windows, recipe should not assume that a shell is available (like MSYS2). Therefore, if the build requires additional tools, they should be added to `build_requirements()`.
+* Except for CMake and a working build toolchain (compiler, linker, archiver, etc.), the recipe should not assume that any other build tool is installed on the user-build machine (like Meson, autotools, or pkg-config). On Windows, the recipe should not assume that a shell is available (like MSYS2). Therefore, if the build method requires additional tools, they should be added to `build_requirements()`.
 
 * It is forbidden to run other conan client commands during build. In other words, if upstream build files call conan under the hood (through `cmake-conan` for example or any other logic), this logic must be removed.
 
@@ -25,9 +25,9 @@ Both of these methods often take advantage of build helpers build binaries and i
 
 ## Package
 
-* CMake config files must be removed (they will be generated for consumers by `cmake_find_package`, `cmake_find_package_multi` or `CMakeDeps` generators). use `rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))` or `rm(self, "*.cmake", os.path.join(self.package_folder, "lib"))`.
+* CMake config files must be removed (they will be generated for consumers by `cmake_find_package`, `cmake_find_package_multi`, or `CMakeDeps` generators). Use `rmdir(self, os.path.join(self.package_folder, "lib", "cmake"))` or `rm(self, "*.cmake", os.path.join(self.package_folder, "lib"))`.
 
-* pkg-config files must be removed (they will be generated for consumers by `pkg_config` or `PkgConfigDeps` generators). use `rmdir(self, os.path.join(self.package_folder, "lib", "pkgconfig"))` or `rm(self, "*.pc", os.path.join(self.package_folder, "lib"))`
+* pkg-config files must be removed (they will be generated for consumers by `pkg_config` or `PkgConfigDeps` generators). Use `rmdir(self, os.path.join(self.package_folder, "lib", "pkgconfig"))` or `rm(self, "*.pc", os.path.join(self.package_folder, "lib"))`.
 
 * On *nix systems, executables and shared libraries should have empty `RPATH`/`RUNPATH`/`LC_RPATH`.
 

docs/adding_packages/dependencies.md

@@ -1,7 +1,7 @@
 # Dependencies
 
-This section outlines all the practices and guidelines for `requirements()` and `build_requirements()` methods. This includes everything for "vendored" dependencies to
-when and how the versions could be changes.
+This section outlines all the practices and guidelines for the `requirements()` and `build_requirements()` methods. This includes everything from "vendored" dependencies to
+when and how the versions could be changed.
 
 <!-- toc -->
 ## Contents
@@ -11,10 +11,10 @@ when and how the versions could be changes.
 ## Rules
 
 * [Version range](https://docs.conan.io/en/latest/versioning/version_ranges.html) is not allowed.
-* Specify explicit RREV (recipe revision) of dependencies is not allowed.
+* Specify explicit [RREV](https://docs.conan.io/en/latest/versioning/revisions.html) (recipe revision) of dependencies is not allowed.
 * Vendoring in library source code should be removed (best effort) to avoid potential ODR violations. If upstream takes care to rename
   symbols, it may be acceptable.
-* Only other ConanCenter recipes are allowed in `requires`/`requirements()` and `build_requires`/`build_requirements()`.
+* Only ConanCenter recipes are allowed in `requires`/`requirements()` and `build_requires`/`build_requirements()`.
 * If a requirement is conditional, this condition must not depend on [build context](https://docs.conan.io/en/1.35/devtools/build_requires.html#build-and-host-contexts). Build requirements don't have this constraint.
 * Forcing options of dependencies inside a recipe should be avoided, except if it is mandatory for the library - in which case it must
   be enforced through the `validate()` methods.