Porting spelling fixes by AlexAndradeSan into main (#327)

* Contracted contributor.md (#313)
* Crossteam project valuation.md (#314)
* Praise participants.md (#316)
* Communication tooling.md (#317)
* Issue tracker.md (#318)

Co-authored-by: Alexander Andrade <[email protected]>
Co-authored-by: Sebastian Spier <[email protected]>

Author: spier

patterns/2-structured/contracted-contributor.md

@@ -10,10 +10,10 @@ Associates wanting to contribute to InnerSource are discouraged from doing so by
 
 Without support by middle management, the total number of contributors and, as
 a result, the amount of contributions made and value generated by the
-InnerSource initiative will likely fall below expectation of top level
+InnerSource initiative will likely fall below expectation of top-level
 management. This will likely be amplified if there is no adequate funding for
 and empowerment of [Dedicated Community Leaders](dedicated-community-leader.md).
-This runs the risk of top level management abandoning the InnerSource idea.
+This runs the risk of top-level management abandoning the InnerSource idea.
 
 ## Context
 
@@ -27,11 +27,11 @@ them, the InnerSource initiative is just one of many initiatives to foster
 innovation and efficiency, though. They are funding InnerSource with money and
 capacity for community leaders and are largely giving autonomy as for how the
 budget is spent. They are also limiting the breadth and duration of the
-initiative and partake in periodic reviews until there is proof that it yields
+initiative and partake in periodic reviews until there is proof it yields
 the expected results (see [Review Committee](review-committee.md)).  Top level
 management has announced their support for InnerSource on various company-internal meetings.
 
-However, top level management has not yet empowered or incentivised mid-level
+However, top-level management has not yet empowered or incentivised mid-level
 managers to allow or even motivate their employees to participate in
 cross-divisional InnerSource activities. In addition to that, the capacity of
 every associate is usually allocated to non InnerSource projects for 100 % of

patterns/2-structured/crossteam-project-valuation.md

@@ -31,7 +31,7 @@ Such models give us the tool that we need to focus and amplify high-value collab
 The core of all cross-team project value is the idea that we can get more done together than apart.
 Ascribing value to a cross-team effort is an exercise in quantifying _how much more_ is getting done together.
 The exact delta in productivity will vary by domain and project.
-There is a common process, though, by which you can create a model to calculate it.
+There is a common process, by which you can create a model to calculate it.
 
 ### Explanation
 
@@ -66,12 +66,12 @@ Once you have your worst-case bounds you can value your cross-team project outpu
 ### Commentary
 
 Despite the trappings of rigor, this process does not yield an exact way to measure cross-team project output.
-In-practice, though, it does give a framework by which you can make a sound decision at how to fund this work.
+In-practice, however, it does give a framework by which you can make a sound decision at how to fund this work.
 After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to _**at least**_ of the lesser of the following three levels:
 
 1. The raw hours saved by the formula above.  Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
 1. The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to facilitate their work going into a shared location.
-1. Whatever feels good to you.  One intentional side-effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
+1. Whatever feels good to you.  One intentional side effect of having a valuation formula is that it naturally forces measurement of the key points of usage that provide value to consumers.
 
 Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.
 

patterns/2-structured/praise-participants.md

@@ -5,7 +5,7 @@ Praise Participants
 ## Patlet
 
 After an inner source contribution, it's important to thank the contributor for their time and effort.
-This pattern gives guidance that not only effectively acknowledges the contribution but also endgenders further engagement from the contributor and others.
+This pattern gives guidance that not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others.
 
 ## Problem
 
@@ -21,7 +21,7 @@ A pattern in this area makes it easy to do and ensures that the message comes ac
 
 ## Forces
 
-* You are busy, which makes it easy to forget some of the soft touches like praise and thanks.
+* You are busy, which makes it easy to forget some soft touches like praise and thanks.
 * You may not be someone that is comfortable in social situations or good with words.
 * Peer recognition is very important to job satisfaction and career development.
 
@@ -31,7 +31,7 @@ It feels good to anyone to be recognized by others.
 In a professional setting, increased recognition is also an avenue to increased influence and growth.
 Any time someone gives to your inner source project, recognize them with a sincere and qualified "thank you".
 
-For non-trivial contributions (all code contributions and also significant time contributions), say thank you via the following mechanisms:
+For non-trivial contributions (all code contributions and significant time contributions), say thank you via the following mechanisms:
 
 (1) Call out the person by name in any chat location (e.g. _Slack_) where you organize your project activity.  Let everyone know what they did and thank them publicly.  
 
@@ -40,8 +40,8 @@ Example:
 > Everyone @here give a high-five to @andrew.clegg for updating the _rcs-viewer_ to the latest version of the _hebo-client_ (https://github.com/rcs/rcs-viewer/pull/81).
 Thanks for helping keep this library up-to-date, Andy!
 
-(2) Send an email to them and their manager (cc'd) privately thanking them for the contribution.
-For code contributions often-times you can just forward the merge notification mail.  
+(2) Email them and their manager (cc'd) privately thanking them for the contribution.
+For code contributions often-times you can just forward the merge notification mail.
 
 Example:
 

patterns/2-structured/project-setup/communication-tooling.md

@@ -6,7 +6,7 @@ Communication Tooling
 
 An InnerSource project is being used outside the original development team but
 users are having trouble getting help and getting in touch with the project
-team. The idea is to setup and document standard communication tooling that
+team. The idea is to set up and document standard communication tooling that
 allows for discussions to become visible, archived and searchable.
 
 ## Context
@@ -39,9 +39,9 @@ The goal when streamlining communication channels for InnerSource projects
 should be to align communication around topics, not around certain sets of
 people:
 
-- The project should have it's own issue tracker where structured communication, decision making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow.
-- The project should have one or more discussion channels that come with less rigid a structure. Typically this will be mailing lists, online forums or even archived chat channels. Usually it is enough to start with just one channel for the project, if traffic increases too much it's helpful to split discussions around project usage from discussions around project development.
-- In addition the project should have one private channel where sensitive communication can happen between [Trusted Committers](../trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
+- The project should have its own issue tracker where structured communication, decision-making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow.
+- The project should have one or more discussion channels that come with less rigid a structure. Typically, this will be mailing lists, online forums or even archived chat channels. Usually it is enough to start with just one channel for the project, if traffic increases too much it's helpful to split discussions about project usage from discussions about project development.
+- In addition, the project should have one private channel where sensitive communication can happen between [Trusted Committers](../trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
 
 While communication can happen outside of written channels, as much information
 as possible should be brought back to the asynchronous channels.
@@ -71,7 +71,7 @@ the project.
 
 Answering questions in those channels means that not only other team members
 can listen in and provide additional information, it also means that other
-users with the same question see (or later on find) the previous answer leading
+users with the same question see (or later find) the previous answer leading
 to a lower need to repeat explanations.
 
 ## Known Instances

patterns/2-structured/project-setup/issue-tracker.md

@@ -10,13 +10,13 @@ The InnerSource host team fails to make not only plans and progress but also con
 
 A team develops a component that many teams in the organization depend on. It
 uses a standard issue tracker for tracking open bugs and feature requests.
-However the context in each entry is very limited. As a result potential
+However, the context in each entry is very limited. As a result potential
 contributors have no way of knowing what change exactly each issue is talking
 about.
 
 ## Context
 
-The InnerSource project tooling is all setup. However the project issue tracker
+The InnerSource project tooling is all setup. However, the project issue tracker
 is mainly used for sharing progress. In InnerSource projects there are many more
 use cases that an issue tracker can be used for that make remote, asynchronous
 communication easier.
@@ -25,7 +25,7 @@ communication easier.
 
 - Contributors would like to understand whether the feature that they are missing is already on the roadmap. With a lot of context missing in issues though it is impossible to decide whether existing issues match the contributing team's needs.
 - As a result a lot of duplicate issues are being opened that the host team has to deal with.
-- As context in open issues is so limited contributors are unable to help the host team by implementing some of the easier issues that are open already. As a result a lot of work remains in the hands of the host team.
+- As context in open issues is so limited contributors are unable to help the host team by implementing some easier issues that are open already. As a result a lot of work remains in the hands of the host team.
 - With a strong focus on verbal communication it is impossible to discern after a couple months or years why a certain feature was being chosen for implementation. As a result refactorings, in particular simplifying the component becomes an exercise in project archaeology and brain picking of people who remember what was discussed.
 
 ## Solution
@@ -36,14 +36,14 @@ development but also during the planning phase of new features:
 - For bugs, planned features and feature ideas create separate issues. In each of those include as much information as possible so that potential external contributors are able to understand the context. Ideally, in particular for easier changes, include enough information for external contributors to support the host team by implementing the functionality in question.
 - Potentially use the issue tracker as a channel to ask questions. This is in particular helpful if you are lacking other communication sources to tackle user questions.
 - Make use of tags and categories in order to distinguish issues used for different purposes.
-- For starting a brain storming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
+- For starting a brainstorming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
 - Most issue tracker implementations allow for issue templates. Make use of those not only to collect commonly needed information for bug reports but also include hints about what kind of information is needed for the other usage types.
 
 ## Resulting Context
 
 - Making more use of the project's issue tracker for communication enables external contributors to follow along and make better decisions on what to contribute.
 - A focus on structured written communication enables host team members to participate remotely.
-- Consistently communicating in writing means that passive documentation on project decisions accumulates as a by product instead of needing added attention.
+- Consistently communicating in writing means that passive documentation on project decisions accumulates as a by-product instead of needing added attention.
 - Consistently using public communication channels leads to more humans following a discussion. This means that there are more knowledgeable humans that can answer questions, chime in on open issues, or point out flaws in planned features that would otherwise be found only much later.
 - Moving discussions to a public discussion medium creates an opportunity for potential future contributors to lurk, follow along, get comfortable and learn the ways of the project long before they have the first need to get involved.