Atlas tc edits

trusted-committer/01-introduction.asciidoc

@@ -1,81 +1,79 @@
-== Introducing the Trusted Committer role
+[role="pagenumrestart"]
+== Introducing the Trusted Committer Role
 
-The Trusted Committer (TC) role is one of the key roles in an InnerSource
-community. Think of Trusted Committers as the people in a community that you trust with
-important technical decisions and with mentoring contributors in order to get
-their contribution over the finish line. The Trusted Committer role is both a demanding and a
-rewarding role to fulfill. It goes far beyond being an opinionated gatekeeper
-and it is instrumental for the success of any InnerSource community.
+The Trusted Committer (TC) role is one of the key roles in an
+InnerSource community. Think of TCs as the people in a community that
+you trust with important technical decisions and with mentoring
+contributors to ultimately get contributions over the finish line.
+The TC role is both demanding and rewarding. It is more than just being an opinionated gatekeeper and is instrumental for
+the success of any InnerSource community.
 
-Generally speaking, the Trusted Committer role is defined by its responsibilities, rather than
-by its privileges. On a very high level, Trusted Committers represent the interests of both
-their InnerSource community and the products the community is building. They
-are concerned with the health of both the community and the product. So as a
-Trusted Committer, you'll have both tech oriented and community oriented responsibilities.  We'll
-explore both of these dimensions in the following sections.
+Generally speaking, the TC role is defined by its responsibilities,
+rather than by its privileges. On a very high level, TCs represent the
+interests of both their InnerSource community and the products the
+community is building. They are concerned with the health of both the
+community and the product. So as a TC, you’ll have both tech- and community-oriented responsibilities. We’ll explore both of these
+dimensions in the following sections.
 
-Before we go into the details of what a Trusted Committer actually does, let's spend some time
-contrasting the Trusted Committer role to other roles in InnerSource on a high level of abstraction and
-explain why we think the name is both apt and important.  Let's
-start with the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributor_] role. A _Contributor_ - as the name implies -
-makes contributions to an InnerSource community.  These contributions could be code or non-code
-artifacts, such as bug reports, feature requests or documentation.
+Before we go into the details of what a TC actually does, let’s spend
+some time contrasting the TC role with other roles in InnerSource at a
+high level of abstraction and explain why we think the name is both apt
+and important. Let’s start with the _Contributor_ role. A
+_Contributor_—as the name implies—makes contributions to an InnerSource
+community. These contributions could be code or non-code artifacts, such
+as bug reports, feature requests, or documentation.
 
-_Contributors_ might or might not be part of the community. They might be sent by
-another team to develop a feature that their team needs. This is why we
-sometimes also refer to _Contributors_ as _Guests_ or being part of a _Guest
-Team_. The _Contributor_ is responsible for "fitting in" and for conforming to the
-community's expectations and processes.
+_Contributors_ may or may not be part of the community. They might
+be sent by another team to develop a feature the team needs. This
+is why we sometimes also refer to _Contributors_ as _Guests_ or as
+part of a _Guest Team_. The _Contributor_ is responsible for "fitting
+in" and for conforming to the community’s expectations and processes.
 
-The _Trusted Committer_ is always a member of the InnerSource community, which is
-also sometimes referred to as the _Host Team_. In this analogy, the Trusted Committer is
-responsible for both building the house and setting the house rules, to make
-sure their guests are comfortable and can work together effectively. Compared
-to contributors, Trusted Committers have earned the responsibility to push code closer to
-production, and are generally allowed to perform tasks that have a higher level
-of risk associated with them.
+The _Trusted Committer_ is always a member of the InnerSource community,
+which is also sometimes referred to as the _Host Team_. In this analogy,
+the TC is responsible for both building the house and setting the house
+rules to ensure their guests are comfortable and can work together
+effectively. Compared to contributors, TCs have earned the
+responsibility to push code closer to production and are generally
+allowed to perform tasks that have a higher level of risk associated
+with them.
 
-The https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_ (PO)] is the third role in InnerSource.  Similar to agile
-processes, the PO is responsible for defining and prioritizing requirements and
-stories for the community to implement. The PO interacts often with the
-Trusted Committer, e.g. in making sure that a requested or contributed feature actually
-belongs to the product. Especially in smaller, grass-roots type InnerSource
-communities, the Trusted Committer usually also acts as a PO. Please check out our https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[Product
-Owner Learning Path segment] for more detailed information.
+The _Product Owner_ (PO) is the third role in InnerSource. Similar to
+agile processes, the PO is responsible for defining and prioritizing
+requirements and stories for the community to implement. The PO
+interacts often with the TC, (e.g., in making sure that a requested or
+contributed feature actually belongs to the product). Especially in
+smaller, grassroots InnerSource communities, the TC usually also
+acts as a PO. Check out our https://learning.oreilly.com/videos/innersource-product-owners/9781492046707[Product Owner Learning Path segment]
+for more detailed information.
 
+=== Why Role Names Matter
 
-=== Why role names matter
+The role of the TC is present in every successful InnerSource community
+but not every community uses that name. Some communities use the term
+Maintainer, but this term conflicts with other technical roles such as the 
+"Maintainer" role defined by GitHub, for instance. Apache uses the term
+_Committer_, too, but they attach fewer and mostly tech-oriented
+responsibilities to that role. With its additional community-oriented responsibilities, the TC role goes beyond that. The ``Trusted'' in TC
+means this person is trusted and thus empowered by both their
+management and their community to do their job. By fostering openness
+and transparency, TCs build trust in the process and also in the product
+being built.
 
-The role of the Trusted Committer is present in every successful InnerSource community, but not
-every community uses that name. Some communities use the term Maintainer, but
-it turns out that it conflicts with the technical role "Maintainer" defined by
-GitHub, for instance.  Apache uses the term _Committer_, too, but they attach
-fewer and mostly tech oriented responsibilities to that role. The Trusted Committer role with
-its additional community oriented responsibilities goes beyond that.  The
-"Trusted" in Trusted Committer conveys that they are trusted and thus empowered by both their
-management and their community to do their job. By fostering openness and
-transparency, Trusted Committers build trust in the process and also in the product being
-built.
+Similar to how naming is important in writing software, choosing the right names for roles and
+doing so consistently ensures that everyone has the same understanding about the roles played in the community.
 
-So similar to how naming is important in writing software, it is important for the
-roles in an InnerSource project as well. Choosing the right names and doing so
-consistently ensures that everyone has the same notion of the role and how it
-serves the community.
-
-Now you should have a basic understanding of the role, why using the term
-_Trusted Committer_ is appropriate, and understand how a Trusted Committer might
-interact with other common roles in a software project.
+Now that you have a basic understanding of the role, why using the
+term TC is appropriate, and know how a TC might interact with other common roles in a software project, let's take a quick look at the responsibilities of a TC.
 
 === Responsibilities
 
-In the following segments, we'll dive into the various responsibilities that
-Trusted Committers have:
+TCs have various responsibilities, including:
 
-* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/02-ensuring-product-quality.asciidoc[ensuring product quality],
-* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/03-keeping-the-community-healthy.asciidoc[keeping the community healthy],
-* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/05-lowering-the-barriers-to-entry.asciidoc[reducing the barrier to making contributions],
-* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/04-uplevelling-community-members.asciidoc[upleveling the community],
-* https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/06-advocating-for-the-communitys-needs.asciidoc[advocating the communities needs].
+* Ensuring product quality
+* Keeping the community healthy
+* Reducing the barriers to making contributions
+* Upleveling the community
+* Advocating the community's needs
 
-In addition, we will also explore the path of https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/07-becoming-a-trusted-committer.asciidoc[becoming a Trusted Committer] in the end
-of this article.
+We will look at these responsibilities in more depth in the following pages and also explore the path of becoming a TC at the end of this article.

trusted-committer/02-ensuring-product-quality.asciidoc

@@ -1,66 +1,63 @@
-== Ensuring product quality
-
-Let's start with the responsibility most often associated with the Trusted Committer role:
-ensuring product quality.
-
-In an InnerSource community, the Trusted Committers _own_ all tech related decisions,
-especially those related to product quality. Ownership implies that Trusted Committers need
-to make sure the decisions in place are followed through.  This includes
-communicating and - if necessary - advocating these decisions, inside and outside
-of the community. Trusted Committers don't necessarily make all the tech related decisions
-themselves or do all the work to implement them.
-
-It is the Trusted Committer's job to communicate and motivate quality standards in their
-community and to formulate them in a way that is understandable and actionable
-by their https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_]. This includes written documentation, of course. But the
-most effective way for Trusted Committers to communicate this is to set an example for the
-expected quality standard themselves. We think it can be a worthwhile goal for
-an InnerSource community to try and distinguish itself from traditional
-software development projects not just in the way they organize development but
-also in the quality of the software they produce, as well. A high software quality is
-essential for building trust in an InnerSource community on part of their users
-and their management and we all know how one bad release can shatter this trust
-in an instant.
-
-The Trusted Committers also make sure that the community has the infrastructure and the tools
-they need to produce quality software. The tool that Trusted Committers will use most
-frequently for ensuring quality is the peer review, usually performed as part
-of pull requests. While everybody can usually start and participate in pull
-requests by pointing out necessary improvements, it is usually only the Trusted Committers who
-can ultimately accept and merge or reject a contribution. That is what we meant
-when we said "Trusted Committers can push code closer to production" earlier.  Trusted Committers should also
-help https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] during a PR to get their contribution over the finish line.
-
-That said, it is ultimately the contributor's job to make that happen. The job
-of a Trusted Committer is not to accept all contributions by default, but to only accept those
-who meet the defined criteria in terms of quality and scope.  And Trusted Committers should
-avoid rewriting contributor's code to make it "`fit`" as much as possible, even
-if it means spend way more time supporting the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] in a PR compared
-to doing it themselves.  Trusted Committers take a long term perspective and understand that
-this kind of support is an investment both in the longevity of the community
-and the speed at which it will move forward.
-
-Coming back to the project scope: sometimes requirements or limitations for
-the software being developed are not elicited up front but rather discovered
-during development. Trusted Committers are also responsible for making sure these findings are
-captured and documented for both the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owners_] and the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_].
-
-The Trusted Committers purview with respect to quality goes beyond pull requests, though. Trusted Committers think
-about quality on a strategic level and ensure the longevity of the software
-being built. That entails code oriented responsibilities from ensuring
-cleanliness of the code to maintaining conceptual integrity of the overall
-software. It also entails more management oriented tasks such as making sure
-that the community is given sufficient time to refactor their software or move
-a release date in favor of quality improvements, if the community deems that
-necessary. The effectiveness of the Trusted Committer is strongly related to code health.
-
-Absent the latter, the Trusted Committer will have to spend much of their valuable time
-validating and documenting workarounds for bugs or a fragile architecture
-and will not have enough time to spend on onboarding and mentoring
-https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_].
-
-
-In conclusion, ensuring product quality is a key responsibility of Trusted Committers. They set
-quality standards and lead by example.  They participate in pull requests and
-help https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributors_] with their contributions to meet the quality standards.  They
-also take responsibility for the long term health of the software.
+== Ensuring Product Quality
+
+Let’s start with the responsibility most often associated with the TC
+role: ensuring product quality.
+
+In an InnerSource community, the TCs _own_ all tech-related decisions,
+especially those related to product quality. Ownership implies the
+need to make sure the decisions in place are followed through. This
+includes communicating and—if necessary—advocating for these decisions,
+inside and outside of the community. But TCs don’t necessarily make all the
+tech-related decisions themselves or do all the work to implement them.
+
+It is the TC's job to communicate and clarify quality standards in their
+community and to formulate them in a way that is understandable and
+actionable by their contributors. This includes written documentation,
+of course, but the most effective way for TCs to communicate these quality standards is by example. We think it
+can be a worthwhile goal for an InnerSource community to try and
+distinguish itself from traditional software development projects not
+just in the way they organize development but also in the quality of the
+software they produce, as well. A high level of software quality is essential for establishing and maintaining the trust of both users in the software the community is building and the management in the way it is being built. We all know how one bad release can shatter this trust in an instant.
+
+TCs also make sure the community has the infrastructure and the
+tools they need to produce quality software. The peer review (PR), usually
+performed as part of pull requests, is most frequently used to ensure quality. While everybody can usually start
+and participate in pull requests by pointing out necessary improvements,
+it is usually only the TC who can ultimately accept and merge or reject
+a contribution. This is what we meant earlier when we said "TCs can push code
+closer to production." TCs should also help contributors during
+a PR to get their contributions over the finish line.
+
+That said, it is ultimately the contributor's job to make that happen.
+The job of a TC is not to accept all contributions by default, but to
+only accept those that meet the defined criteria in terms of quality and
+scope. And TCs should avoid rewriting a contributor's code to make it
+"fit" as much as possible, even if it means spending more time
+supporting contributors in a PR. TCs
+take a long-term perspective and understand that this kind of support is
+an investment both in the longevity of the community, and it will increase the community's development speed in the long run.
+
+Sometimes project requirements or limitations are not known upfront and are instead
+discovered during development. TCs are also responsible for making sure
+these findings are captured and documented for both the POs and the
+contributors.
+
+But the TC's purview with respect to quality goes beyond pull requests. TCs think about quality on a strategic level and ensure the
+longevity of the software being built. This entails code-oriented
+responsibilities from ensuring cleanliness of the code to maintaining
+conceptual integrity of the overall software. It also entails
+management-oriented tasks such as making sure the community is
+given sufficient time to refactor their software or move a release date
+in favor of quality improvements, if needed.
+The effectiveness of the TC is strongly related to code health.
+
+Absent the latter, TCs will have to spend much of their valuable time
+validating and documenting workarounds for bugs or a fragile
+architecture and will not have enough time to spend on onboarding and
+mentoring contributors.
+
+In conclusion, ensuring product quality is a key responsibility of TCs.
+They set quality standards and lead by example. They participate in pull
+requests and help contributors meet
+quality standards. They also take responsibility for the long-term
+health of the software.