diff --git a/patterns/2-structured/project-setup/communication-tooling.md b/patterns/2-structured/project-setup/communication-tooling.md
index 245345978..dd64f775c 100644
--- a/patterns/2-structured/project-setup/communication-tooling.md
+++ b/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.
 
 Test
@@ -41,9 +41,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.
@@ -73,7 +73,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