Improving maturity-model.md (#334)

Improving maturity-model.md

Author: spier

patterns/2-structured/maturity-model.md

@@ -5,15 +5,15 @@ Maturity Model
 ## Patlet
 
 Teams have started adopting InnerSource. The practice is spreading to multiple
-departments. Understanding of what constitutes an InnerSource project are wide
-spread though. The solution is to provide a maturity model to allow for teams to
-go through a self check and discover patterns and practices that they are not
+departments. However, the understanding of what constitutes an InnerSource
+project varies. The solution is to provide a maturity model to allow for teams
+to go through a self check and discover patterns and practices that they are not
 yet aware of.
 
 ## Problem
 
 When InnerSource adoption in an enterprise starts to increase, individual
-mentoring of each project through one evangelist becomes unfeasible. Also more
+mentoring of each project through one evangelist becomes unfeasible. Also, more
 and more people are gaining at least a basic understanding of what it means to
 work in an InnerSource project. Looking at all InnerSource projects though the
 depth of understanding for the concept will diverge. Teams may not be aware of
@@ -51,7 +51,7 @@ InnerSource project benefit from planning being transparent across the organizat
 
 * PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization.
 * PP-1: Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started. Shared roadmap.
-* PP-2: There are already shared roadmaps with clear guidelines and contribution rules where stakeholders can provide feedback. However this is not standardized across the organization and not all of the projects provide this info.
+* PP-2: There are already shared roadmaps with clear guidelines and contribution rules where stakeholders can provide feedback. However, this is not standardized across the organization and not all of the projects provide this info.
 * PP-3: Roadmaps are shared by default and there is a standard process and homogeneous way to do this across the organization at the level of each InnerSource project. This contains clear rules to contribute and influence in the roadmap.
 
 **Development Process & Tools**
@@ -60,16 +60,16 @@ InnerSource projects thrive when contributors become active and participate. As
 
 * DP-0: Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside development team. Siloed development teams.
 * DP-1: Development teams use shared code repositories, internally. Some teams develop their own CI process, using non corporate or standard CI tools. There is no code review process defined, although some projects teams do it internally.
-* DP-2: The organization sponsors and promotes a shared repository for collective knowledge. Some teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Code review is sometimes done by external team members.
+* DP-2: The organization sponsors and promotes a shared repository for collective knowledge. Some teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used by some projects. Sometimes code review is done by outside team members.
 * DP-3: Most teams develop their own CI process, using corporate CI tools. There are CI environments. Code review process defined, and used. Code review is done by both, internal and external team members.
 
 **Decisions**
 
-In order to motivate colleagues to contribute work outside of their core team they need visibility into the decision making process of the host project - but also feel that their voices are being heard and valued.
+In order to motivate colleagues to contribute work outside of their core team they need visibility into the decision-making process of the host project - but also feel that their voices are being heard and valued.
 
 * DC-0: Decision-makers often intentionally or accidentally withhold data and resources related to project decisions.
 * DC-1: Materials that are part of decision-making practices become available for review after decisions are finalized.
-* DC-2: People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding. Materials that are part of decision-making practices are available at defined project milestones
+* DC-2: People feel like they know about—and are helping to shape—most (but not all) important decisions as those decisions are unfolding. Materials that are part of decision-making practices are available at defined project milestones.
 * DC-3: People feel like they are a part of a shared, standard process for collective decision-making that the organization endorses. Materials that are part of decision-making practices are continuously accessible during work processes.
 
 **Helpful Resources**
@@ -85,7 +85,7 @@ In order to attract contributors helpful supporting material needs to be easily
 
 When working in host teams mistakes will automatically be widely visible. In order keep contribution levels up, corporate culture needs to celebrate failure as an opportunity for growth and learning.
 
-* ST-0: Individuals and teams don't share neither successes nor failures for others to learn from.
+* ST-0: Individuals and teams do not share successes or failures for others to learn.
 * ST-1: Individuals and teams are comfortable sharing stories about successes, but not about failures.
 * ST-2: Individuals and teams are comfortable sharing stories of successes and failures during retrospectives and reviews.
 * ST-3: Individuals and teams are comfortable sharing stories of successes and failures, and learn from failures according to formal protocols.
@@ -168,7 +168,7 @@ InnerSource projects need a means for self assessment. Metrics can be one aspect
 
 * MP-0: No existing monitoring policies at any level in the organization.
 * MP-1: Metrics are important for certain teams, and they start using them in an isolated way.
-* MP-2: There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization. This monitoring policy exists at the level of some of the InnerSource projects.
+* MP-2: There is a strategy at the organizational level with respect to metrics that help to validate specific policies across the organization. This monitoring policy exists at the level of some InnerSource projects.
 * MP-3: There are clear guidelines, recommendations, and trainings about the use of metrics with certain infrastructure provided by the organization. This works at both levels: InnerSource program to understand the general InnerSource adoption within the organization, and at the level of InnerSource projects.
 
 **Support and Maintenance**
@@ -195,7 +195,7 @@ InnerSource comes with explicit roles. While in early stages some patterns may b
 
 * RO-0: There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc.
 * RO-1: Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted committer role.
-* RO-2: An InnerSource Officer role is in charge for governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members).
+* RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members).
 * RO-3: Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear.
 
 ## Resulting Context
@@ -205,7 +205,7 @@ All teams are aware of available best practices.
 Teams understand their level of InnerSource adoption.
 
 Prior to adopting InnerSource as a working model, teams are aware of the
-practices that are expected of them - both in the short term as well as in the
+practices that are expected of them - both in the short term and in the
 long term.
 
 ## Known Instances
@@ -214,18 +214,22 @@ long term.
 * Zylk
 * Bitergia
 
-## Status
-
-* Structured
-* Drafted in September 2019
-
 ## Authors
 
 * Daniel Izquierdo Cortazar
 * Isabel Drost-Fromm
 * Jorge
 * Nerea
 
+## Acknowledgements
+
+* Alexander Andrade (special thanks for the spelling fixes)
+
 ## Alias
 
 Maturity model: Learn about InnerSource best practices
+
+## Status
+
+* Structured
+* Drafted in September 2019