Merge pull request #201 from Ludmila-N/Style-benefits

Benefits of contributing article - style review and minor updates

Author: Ludmila-N

contributor/05-benefits-of-contribution-article.asciidoc

@@ -14,73 +14,73 @@ their purview?
 === Individual motivation
 
 The most obvious motivation is what typically draws early contributors into open
-source as well:
+source as well.
 
 Rememember that annoying bug you've been working around for so long? The time
 and energy that maintainting those workarounds costs? What if instead of waiting for
 the upstream team to fix that issue sometime in the future, you could go ahead
-and fix it yourself? Often in a "scratch your own itch" kind of approach first-time
-contributors start with fixing issues in projects they depend on for their
+and fix it yourself? In this "scratch your own itch" situation first-time contributors 
+often start with fixing issues in projects they depend on for their
 daily work to reduce the number of workarounds in their own codebase.
 
 When deciding whether to create and contribute a fix instead of maintaining your
 own workaround, think about the benefit that the contribution will bring to
-your own changes.  Instead of working in isolation, those working on the upstream
+the quality of your own changes. Instead of working in isolation, those working on the upstream
 project will be able to not only review but also improve your solution. You get
 support and mentoring which greatly speeds up your own development effort.
 
 Spending more time with others means that over time you will learn how the team
 works, how it organises itself, which tooling it uses in which way to build
 their project. Oftentimes your own projects will benefit from that experience:
-instead of only reading about some new library or build system you'll be able to
-gain practical experience with it before going ahead and introducing that in
+instead of only reading about some new library or build system, you'll be able to
+gain practical experience with it before going ahead and introducing it in
 your own projects. Working on more than one core project means that you will be
 exposed to a larger ecosystem from which to draw best practices and solutions to
 challenges.
 
 A nice side effect of being able to spend some of your time in other teams is
 that your reputation and impact expand the boundaries of your own team. So in
-addition to yourself learning and growing from others you get to influence
-projects.  You influence directly via your own contributions but also by
-sharing your experience and knowledge on project tooling and setup.  This sharing might
+addition to learning from others and growing yourself, you get to influence
+projects. You influence directly via your own contributions and by
+sharing your experience and knowledge on project tooling and setup. This sharing might
 help the upstream project improve and accelerate development cycles.
 
 Aside from all of these objective criteria there is a component that is very
-hard to meassure but has been reported both in InnerSource and in Open Source
+hard to meassure, but has been reported both in InnerSource and in Open Source
 projects alike: people participate because they find work on those projects
-personally fullfilling and fun. Most likely, the aspect of being in a position
+personally fulfilling and fun. Most likely, the aspect of being in a position
 to truly self select tasks to work on does play an important role.
 This self selection typically also leads to host projects being very welcoming
-and supportive as those are key to keeping motivation in contributors up.
+and supportive in their effort to keep contributors motivated.
 
 === Team level motivation
 
-Remember that annoying bug that's suddenly fixed upstream? Why should your
-team spend the extra effort to contribute that fix to the upstream project?
+Remember that annoying bug that's been finally fixed upstream? Why should your
+team spend an extra effort to contribute that fix to the upstream project?
 
-For one it means that maintenance cost and time is now with the upstream
+For one, it means that maintenance cost and time is now with the upstream
 project. For every new release it's on them instead of on your team to make sure it
 keeps working with your modifications and requirements.
 
 Having team members work as active contributors in projects your team depends on
-means that likely they will get to have a say in project direction and timelines,
+means that they may get to have a say in the project direction and timelines,
 which can be beneficial for your team.
 
 By using InnerSource teams can establish a middle path between "be independent
 and build your own" (including any number of new bugs that you own) and "save
 time and money by relying on existing implementations" (at the cost of creating
-long term dependencies that can only be influenced in a limited way). That way
-balancing reimplementing versus reusing becomes easier.
+long term dependencies which can only be influenced in a limited way). That way
+balancing reimplementing versus reuse becomes easier.
 
 === Company motivation
 
 Remember that functionality that's specific to your company domain - but that
 is maintained in mutiple implementations across the entire company? What if
 there were a way to avoid a dozen buggy implementations and merge them into a
-shared asset with a development process attached that avoids the usual
+shared asset? What if the development process for this shared asset ran without the usual
 drain of energy that central dependencies bring to the table? Many open source
-projects are being used by a huge number of players - some of which participate
-in their design and development. Encouraging cross team collarboration in InnerSource
+projects are being used by a huge number of players - some of who participate
+in their design and development. Encouraging cross team collaboration in InnerSource
 projects at the corporate level means that you can drive central
 innovation from the edges of your organisation.
 
@@ -92,25 +92,25 @@ projects transparent, but also provides tools to improve that situation by
 putting focus on mentoring and expanding the contributor base.
 
 While cross team collaboration makes assessing individual contributions hard,
-it also enables learning and knowledge sharing withing an organisation. As a
+it also enables learning and knowledge sharing within the organisation. As a
 result, the impact of individuals will improve. Best practices and positive
 innovation will spread more easily across the entire organisation. As a side
 effect, improvements to the work environment will more easily spread across the
 organization - helping retain employees.
 
-On the technological side more eyes with a more diverse background implies that
+On the technological side having more eyes with a more diverse background implies that
 code changes will be put under much more scrutiny, leading to better overall
 quality and security.
 
-Finally, a focus on enabling project users and customers to participate in
-development means that there is a very clear incentive to make these projects
-easy to get started with: Based on standard tooling, easy to understand, easy to
+Finally, the focus on enabling project users and customers to participate in
+development provides a very clear incentive to make these projects
+easy to get started with: based on standard tooling, easy to understand, easy to
 re-use and as a result more modular and replaceable.
 
 === Conclusion
 
 As we've seen in this article, many of the reasons for individuals and
 corporations to get active in Open Source also apply to InnerSource projects.
-What we've seen as well is that it's not only altruistic reasons that drive
+We have also seen that it's not only altruistic reasons that drive
 people to collaborate in InnerSource projects - often it's easy to identify
 business reasons for when collaboration like this makes a lot of sense.