Apply suggestions from code review

CONTRIBUTING.md

@@ -50,19 +50,19 @@ Or they may take [other actions](https://github.com/ros-infrastructure/ros_build
 
 In general you should not override or replace system dependencies from the system distribution with a package in the ROS distribution.
 This is part of the software engineering process of maintaining the distribution that all developers can rely on specific versions of software to be available and remain consistent within the distribution.
-If you truly need a newer versions of underlying libraries the you can consider targeting a newer rosdistro with which will target newer platforms which hopefully will have a higher version of your necessary dependency.
-If the necessary version of your dependency isn't available even on the latest platforms, please reach out  and encourage the upstream platforms to move forward to at least your minimum version for the next release of the upstream distributions.
+If you truly need a newer versions of underlying libraries then you can consider targeting a newer ROS distributionthat targets a newer platform which hopefully will have a higher version of your necessary dependency.
+If the necessary version of your dependency isn't available even on the latest platforms, please reach out and encourage the upstream operating systems to move forward to at least your minimum version for the next release of the upstream distributions.
 By doing this you will make sure that it's available for everyone in the future.
 
 Obviously this is a slow process and doesn’t fix things immediately.
 There are workarounds such as embedding copies of the libraries into your package or making another package with the newer library version.
 This usually can be made to work well in your local development environment.
-However if you want to release this style of workarounds into a ROS distribution you must make sure not to break other users who are expecting the system version either in downstream packages or elsewhere on the system.
+However if you want to release this style of workaround into a ROS distribution you must make sure not to break other users who are expecting the system version either in downstream packages or elsewhere on the system.
 
 To release a ROS package which will overlay a system dependency it must:
 
 * Install side by side with the system one, with a different name.
-* Not cause compile errors for any packages including downstream ones
+* Not cause compile errors for any packages including downstream ones.
 * Not cause linking errors or crashes at runtime for yours or any downstream packages, including ones that use the system version on any of our target platforms.
 
 The release pipeline will only catch the first issue automatically.
@@ -72,7 +72,7 @@ But in general if you want to do this without being disruptive you need to:
 2. Change all namespaces to avoid symbol collisions
 3. Change header paths to not collide with the system ones if you export the include directories
 
-Embedding a copy inside your package, potentially statically linking a version into your executables is also a potential way to do it as well.
+Embedding a copy inside your package, potentially statically linking a version into your executables is another way to do it as well.
 It’s going to require a non-trivial amount of engineering and modifications to make this possible and most people decide it’s not worth it.
 
 In many situations a common approach for this is to not actually release it onto the public distro and distribute it separately through a side channel.