From 8fb684668cace42872f30588c725102b3bb5213e Mon Sep 17 00:00:00 2001 From: Jason Krause Date: Thu, 11 May 2023 09:17:38 -0600 Subject: [PATCH 01/11] Removed unneeded line breaks --- patterns/2-structured/maturity-model.md | 29 +++++-------------------- 1 file changed, 6 insertions(+), 23 deletions(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index e9ce8c070..49c78fd4f 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -4,40 +4,23 @@ Maturity Model ## Patlet -Teams have started adopting InnerSource. The practice is spreading to multiple -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. +Teams have started adopting InnerSource. The practice is spreading to multiple 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 -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 -proven patterns that would help them move to the next level and solve issues and -pain points that they are dealing with. +When InnerSource adoption in an enterprise starts to increase, individual 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 proven patterns that would help them move to the next level and solve issues and pain points that they are dealing with. ## Context -Several teams have started adopting InnerSource practices. The exact level of -understanding of the practice diverges between teams. The exact problems teams -run into diverge depending on the context and working environment of each team. -As a result the definition of what are important best practices in an -InnerSource project differs depending on each team. +Several teams have started adopting InnerSource practices. The exact level of understanding of the practice diverges between teams. The exact problems teams run into diverge depending on the context and working environment of each team. As a result the definition of what are important best practices in an InnerSource project differs depending on each team. ## Forces -Teams sharing InnerSource learnings run into misunderstandings as they are not -aware of their respective level of InnerSource adoption. +Teams sharing InnerSource learnings run into misunderstandings as they are not aware of their respective level of InnerSource adoption. -Teams believe that "it's all about migrating to a shared software development -[forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges). +Teams believe that "it's all about migrating to a shared software development [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges). -Teams are not aware of best practices that would help them solve issues that -they run into in their daily doing. +Teams are not aware of best practices that would help them solve issues that they run into in their daily doing. ## Solution From 077950598a4560abda7ca574148895c999b64544 Mon Sep 17 00:00:00 2001 From: Jason Krause Date: Thu, 11 May 2023 09:54:59 -0600 Subject: [PATCH 02/11] Grammar and formatting --- .vscode/settings.json | 8 ++ patterns/2-structured/maturity-model.md | 101 +++++++++++------------- 2 files changed, 52 insertions(+), 57 deletions(-) create mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 000000000..e04a1e91e --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,8 @@ +{ + "grammarly.selectors": [ + { + "language": "markdown", + "scheme": "file" + } + ] +} \ No newline at end of file diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 49c78fd4f..28e814ddf 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -4,69 +4,67 @@ Maturity Model ## Patlet -Teams have started adopting InnerSource. The practice is spreading to multiple 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. +Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow 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 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 proven patterns that would help them move to the next level and solve issues and pain points that they are dealing with. +When InnerSource adoption in an enterprise starts to increase, individual 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 on an InnerSource project. Looking at all InnerSource projects though the depth of understanding of the concept will diverge. Teams may not be aware of proven patterns that would help them move to the next level and solve issues and pain points that they are dealing with. ## Context -Several teams have started adopting InnerSource practices. The exact level of understanding of the practice diverges between teams. The exact problems teams run into diverge depending on the context and working environment of each team. As a result the definition of what are important best practices in an InnerSource project differs depending on each team. +Several teams have started adopting InnerSource practices. The exact level of understanding of the practice diverges between teams. The exact problems teams run into diverge depending on the context and working environment of each team. As a result, the definition of what are important best practices in an InnerSource project differs depending on each team. ## Forces Teams sharing InnerSource learnings run into misunderstandings as they are not aware of their respective level of InnerSource adoption. -Teams believe that "it's all about migrating to a shared software development [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well known examples of such forges). +Teams believe that "it's all about migrating to a shared software development [forge](https://en.wikipedia.org/wiki/Forge_%28software%29)" (GitLab, GitHub, or Bitbucket being well-known examples of such forges). Teams are not aware of best practices that would help them solve issues that they run into in their daily doing. ## Solution -Ask teams to self assess against the proposed maturity model. +Ask teams to self-assess against the proposed maturity model. ### Transparency -**Plans & Products** +**Plans & Products* -InnerSource project benefit from planning being transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others. +InnerSource project benefits from planning to be transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others. -* PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exists at the organization. +* PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exist in 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-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. +* 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 to and influence the roadmap. **Development Process & Tools** -InnerSource projects thrive when contributors become active and participate. As a result, making contribution easier should be balanced with pure technical goals. +InnerSource projects thrive when contributors become active and participate. As a result, making contributions easier should be balanced with pure technical goals. -* 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. Sometimes code review is done by outside team members. +* DP-0: Each team follows its development process and tools. They are not defined to share knowledge and artifacts outside the 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 project 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. The code review process is 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** +**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. +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-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. +* DC-3: People feel like they are 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** - -In order to attract contributors helpful supporting material needs to be easily accessible. +**Helpful Resources*To attract contributors helpful supporting material needs to be easily accessible. * RS-0: Individuals and teams neither contribute to nor draw upon a shared repository of knowledge. -* RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources, but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether information is sensitive or not. Do not "share thinking on others". -* RS-2: Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols. Individuals and teams withhold sensitive data and resources, provide limited details, context, and scope. +* RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether the information is sensitive or not. Do not "share thinking with others". +* RS-2: Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols. Individuals and teams withhold sensitive data and resources and provide limited details, context, and scope. * RS-3: Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols. Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them. **Stories** -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. +When working in host teams mistakes will automatically be widely visible. To keep contribution levels up, corporate culture needs to celebrate failure as an opportunity for growth and learning. * 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. @@ -77,15 +75,13 @@ When working in host teams mistakes will automatically be widely visible. In ord **Channels for Providing Feedback** -For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies. - -Ideally you will end up with proper communication channels that are known by anyone in the organization - with channels focussed on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, opening a proven set of standard channels (which are being archived, publicly accessible, searchable) for each new InnerSource project. +For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies. Ideally, you will end up with proper communication channels that are known by anyone in the organization - with channels focusing on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, and opening a proven set of standard channels (which are archived, publicly accessible, searchable) for each new InnerSource project. -* CF-0: There are no processes nor established channels. Some members of the organization share materials via private channels or discussions. -* CF-1: The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them. Some members of the organization share decision-making materials informally using unofficial platforms. Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work. +* CF-0: There are no processes or established channels. Some members of the organization share materials via private channels or discussions. +* CF-1: The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions so that anyone belonging to the organization can use them. Some members of the organization share decision-making materials informally using unofficial platforms. Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work. * CF-2: The organization has established internal guidelines and channels, and provides specific resources (training programs, access to content, etc.), for encouraging and soliciting diverse points of view on team or decisions. * CF-3: Members of the organization share decision-making materials on officially sanctioned platforms Members of the organization share materials openly via multiple channels and methods for feedback. -Leaders use those channels themselves, openly encourage others to use them, and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback. +Leaders use those channels themselves, openly encourage others to use them and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback. **Leadership** @@ -93,7 +89,7 @@ InnerSource projects encourage employees to contribute to projects outside of th * LS-0: Command & control culture, within a highly hierarchical organization. * LS-1: Some leaders are open to receiving feedback and creating an environment where people feel safe providing it. -* LS-2: Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it. Leaders show passivity about understanding whether all members feel empowered and enabled to share. Organization encourages leaders to actively seek voices not present in dialog out for inclusion. +* LS-2: Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it. Leaders show passivity about understanding whether all members feel empowered and enabled to share. The organization encourages leaders to actively seek voices not present in dialog out for inclusion. * LS-3: Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate. **Organizational and Functional Structure** @@ -105,14 +101,12 @@ When InnerSource leaves the pure coding level and enters the community and worki * OF-2: Cross-functional teams are common, and teams post their roles and goals publicly. * OF-3: Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together. -**Contribution** - -The goal with designing contributions patterns needs to keep collaboration in mind if it's to reduce silos. +**Contribution*The goal of designing contribution patterns needs to keep collaboration in mind if it's to reduce silos. * CB-0: Completely siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams. * CB-1: Members of the organization and teams collaborate but frequently say it's "too difficult". Teams infrequently revisit the outcomes of their collaborations. * CB-2: Members of the organization and teams actively seek opportunities to collaborate. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and make these outcomes available by default. -* CB-3: Members of the organization collaborate both internally and externally in ways that benefit all involved. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, and share their learnings outside the organization, and make these outcomes externally available by default. +* CB-3: Members of the organization collaborate both internally and externally in ways that benefit all involved. Teams routinely discuss, revisit and debate the outcomes of their collaborative efforts, share their learnings outside the organization, and make these outcomes externally available by default. ### Community @@ -121,13 +115,13 @@ The goal with designing contributions patterns needs to keep collaboration in mi Having a baseline of shared values makes it easier to work across team boundaries. Crossing boundaries becomes easier if a limited set of baseline rules and guidelines apply everywhere and can easily be referenced. * SP-0: No sharing culture nor written policies. -* SP-1: Some members of the organization unite to define values and principles, but are not clearly supported when they do. +* SP-1: Some members of the organization unite to define values and principles, but are not supported when they do. * SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions. * SP-3: Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats. **Feel part of the Organization** -One of the possible reasons for introducing InnerSource into organisations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource. +One of the possible reasons for introducing InnerSource into organizations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource. * PA-0: Low engagement, no collaboration and people do not feel comfortable sharing with others. * PA-1: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains. People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment. @@ -136,36 +130,32 @@ One of the possible reasons for introducing InnerSource into organisations can b ### Governance -**Rewards** - -In order to drive adoption, extrinsic motivators can be used to increase cross team collaboration. +**Rewards*To drive adoption, extrinsic motivators can be used to increase cross-team collaboration. * RW-0: No rewards. * RW-1: Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established. * RW-2: Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded. -* RW-3: Rewards are not only proposed by the organization, but the communities are able to define their more valuable rewards. The community is responsible to decide who has to be rewarded. +* RW-3: Rewards are not only proposed by the organization, but the communities can define their more valuable rewards. The community is responsible to decide who has to be rewarded. **Monitoring Policies** -InnerSource projects need a means for self assessment. Metrics can be one aspect to facilitate this assessment. Also, in organisations with a mature InnerSource adoption level we expect adoption of the method to be tracked based on clear, agreed upon metrics. +InnerSource projects need a means for self-assessment. Metrics can be one aspect to facilitate this assessment. Also, in organizations with a mature InnerSource adoption level, we expect the adoption of the method to be tracked based on clear, agreed-upon metrics. * 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 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. +* MP-2: There is a strategy at the organizational level concerning 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 training about the use of metrics with certain infrastructures 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** -Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks. +Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the team's core tasks. -* SM-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team. +* SM-0: Support given by the core dev or support team. A business contract guarantees support. There is no knowledge about the product outside the team. * SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. -* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). -* SM-3: There are rules and regulations to formalize the support on the product, given by a mature community. - -**Culture** +* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like 30-Day[Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). +* SM-3: There are rules and regulations to formalize the support for the product, given by a mature community. -There are multiple levels moving towards a collaborative culture. +**Culture*Multiple levels are moving towards a collaborative culture. * CL-0: Silos - teams work independently but also in isolation. * CL-1: Reactive - teams work independently, but know how to react to flaws in dependencies. @@ -174,12 +164,11 @@ There are multiple levels moving towards a collaborative culture. **InnerSource Roles** -InnerSource comes with explicit roles. While in early stages some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier. +InnerSource comes with explicit roles. While in the early stages, some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier.RO-0: No specific roles are helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. -* 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 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. +* 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 is 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 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. The Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. The 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 the 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 @@ -187,9 +176,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 and in the -long term. +Before adopting InnerSource as a working model, teams are aware of the practices that are expected of them - both in the short term and in the long term. ## Known Instances From 9980534abead3b5622ad97d4e9e32c05f4b586a7 Mon Sep 17 00:00:00 2001 From: Jason Krause Date: Thu, 11 May 2023 09:59:59 -0600 Subject: [PATCH 03/11] Adding Level 4 headings --- patterns/2-structured/maturity-model.md | 38 ++++++++++++++----------- 1 file changed, 22 insertions(+), 16 deletions(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 28e814ddf..b2344c33f 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -28,7 +28,7 @@ Ask teams to self-assess against the proposed maturity model. ### Transparency -**Plans & Products* +#### Plans & Products InnerSource project benefits from planning to be transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others. @@ -37,7 +37,7 @@ InnerSource project benefits from planning to be transparent across the organiza * 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 to and influence the roadmap. -**Development Process & Tools** +#### Development Process & Tools InnerSource projects thrive when contributors become active and participate. As a result, making contributions easier should be balanced with pure technical goals. @@ -46,7 +46,7 @@ InnerSource projects thrive when contributors become active and participate. As * 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. The code review process is 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* +#### Decisions 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. @@ -55,14 +55,16 @@ To motivate colleagues to contribute work outside of their core team they need v * 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 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*To attract contributors helpful supporting material needs to be easily accessible. +#### Helpful Resources + +To attract contributors helpful supporting material needs to be easily accessible. * RS-0: Individuals and teams neither contribute to nor draw upon a shared repository of knowledge. * RS-1: Individuals and teams release project materials for review internally, after they've finished their work. Individuals and teams share resources but in disconnected, fragmented, or individualized/siloed systems or repositories. Individuals and teams share resources, but there is no commonly expressed or shared understanding of the criteria used to determine whether the information is sensitive or not. Do not "share thinking with others". * RS-2: Individuals and teams make project-related materials accessible to some members of project teams according to clearly defined and shared formats and/or protocols. Individuals and teams withhold sensitive data and resources and provide limited details, context, and scope. * RS-3: Individuals and teams make project-related materials broadly accessible to the organization—and possibly outside the organization as well—according to clearly defined and shared formats and/or protocols. Individuals and teams who must withhold sensitive data and resources are clear about what they're not sharing, and others understand why those materials are not available to them. -**Stories** +#### Stories When working in host teams mistakes will automatically be widely visible. To keep contribution levels up, corporate culture needs to celebrate failure as an opportunity for growth and learning. @@ -73,7 +75,7 @@ When working in host teams mistakes will automatically be widely visible. To kee ### Collaboration -**Channels for Providing Feedback** +#### Channels for Providing Feedback For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies. Ideally, you will end up with proper communication channels that are known by anyone in the organization - with channels focusing on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, and opening a proven set of standard channels (which are archived, publicly accessible, searchable) for each new InnerSource project. @@ -83,7 +85,7 @@ For silos to be reduced colleagues need to be comfortable sharing feedback openl * CF-3: Members of the organization share decision-making materials on officially sanctioned platforms Members of the organization share materials openly via multiple channels and methods for feedback. Leaders use those channels themselves, openly encourage others to use them and maintain team-facing or public-facing records of the feedback they've received and/or the actions they've taken to address this feedback. -**Leadership** +#### Leadership InnerSource projects encourage employees to contribute to projects outside of the direct influence of their direct line manager. This needs a culture of trust. @@ -92,7 +94,7 @@ InnerSource projects encourage employees to contribute to projects outside of th * LS-2: Most leaders in the organization are open to receiving feedback and creating an environment where people feel safe providing it. Leaders show passivity about understanding whether all members feel empowered and enabled to share. The organization encourages leaders to actively seek voices not present in dialog out for inclusion. * LS-3: Members feel empowered and enabled to share opinions constructively on any matter relevant to their work or about which they feel passionate. -**Organizational and Functional Structure** +#### Organizational and Functional Structure When InnerSource leaves the pure coding level and enters the community and working group level, there is potential for reducing silos even where direct code collaboration is not possible. @@ -101,7 +103,9 @@ When InnerSource leaves the pure coding level and enters the community and worki * OF-2: Cross-functional teams are common, and teams post their roles and goals publicly. * OF-3: Cross-functional teams are common and make their activities known broadly to the organization; in turn, the organization promotes best practices for working together. -**Contribution*The goal of designing contribution patterns needs to keep collaboration in mind if it's to reduce silos. +#### Contribution + +The goal of designing contribution patterns needs to keep collaboration in mind if it's to reduce silos. * CB-0: Completely siloed, no collaboration outside the teams. Just some collaborations due to cross-functional teams. * CB-1: Members of the organization and teams collaborate but frequently say it's "too difficult". Teams infrequently revisit the outcomes of their collaborations. @@ -110,7 +114,7 @@ When InnerSource leaves the pure coding level and enters the community and worki ### Community -**Sharing Policies** +#### Sharing Policies Having a baseline of shared values makes it easier to work across team boundaries. Crossing boundaries becomes easier if a limited set of baseline rules and guidelines apply everywhere and can easily be referenced. @@ -119,7 +123,7 @@ Having a baseline of shared values makes it easier to work across team boundarie * SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions. * SP-3: Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats. -**Feel part of the Organization** +#### Feel part of the Organization One of the possible reasons for introducing InnerSource into organizations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource. @@ -130,14 +134,14 @@ One of the possible reasons for introducing InnerSource into organizations can b ### Governance -**Rewards*To drive adoption, extrinsic motivators can be used to increase cross-team collaboration. +### Rewards*To drive adoption, extrinsic motivators can be used to increase cross-team collaboration. * RW-0: No rewards. * RW-1: Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established. * RW-2: Standard processes are established to reward collaborations outside the developers' teams. Team leaders or boards decide who has to be rewarded. * RW-3: Rewards are not only proposed by the organization, but the communities can define their more valuable rewards. The community is responsible to decide who has to be rewarded. -**Monitoring Policies** +#### Monitoring Policies InnerSource projects need a means for self-assessment. Metrics can be one aspect to facilitate this assessment. Also, in organizations with a mature InnerSource adoption level, we expect the adoption of the method to be tracked based on clear, agreed-upon metrics. @@ -146,7 +150,7 @@ InnerSource projects need a means for self-assessment. Metrics can be one aspect * MP-2: There is a strategy at the organizational level concerning 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 training about the use of metrics with certain infrastructures 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** +#### Support and Maintenance Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the team's core tasks. @@ -155,14 +159,16 @@ Not only should feature development be owned by InnerSource teams - support and * SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like 30-Day[Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). * SM-3: There are rules and regulations to formalize the support for the product, given by a mature community. -**Culture*Multiple levels are moving towards a collaborative culture. +#### Culture + +Multiple levels are moving towards a collaborative culture. * CL-0: Silos - teams work independently but also in isolation. * CL-1: Reactive - teams work independently, but know how to react to flaws in dependencies. * CL-2: Contributive - teams actively help improve their dependencies by contributing. * CL-3: Activist - teams actively seek help, mentor and recruit new contributors. -**InnerSource Roles** +#### InnerSource Roles InnerSource comes with explicit roles. While in the early stages, some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier.RO-0: No specific roles are helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. From b40491743297a6df3be66097f627aff7ec84e297 Mon Sep 17 00:00:00 2001 From: Jason Krause Date: Thu, 11 May 2023 10:45:41 -0600 Subject: [PATCH 04/11] removing extra file --- .vscode/settings.json | 8 -------- 1 file changed, 8 deletions(-) delete mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json deleted file mode 100644 index e04a1e91e..000000000 --- a/.vscode/settings.json +++ /dev/null @@ -1,8 +0,0 @@ -{ - "grammarly.selectors": [ - { - "language": "markdown", - "scheme": "file" - } - ] -} \ No newline at end of file From 8f2a1acc67f2fb8fdcdb6739b2a6b68c9b0e37da Mon Sep 17 00:00:00 2001 From: Jason Krause Date: Thu, 11 May 2023 10:46:09 -0600 Subject: [PATCH 05/11] remove extra file --- .vscode/settings.json | 5 +++++ 1 file changed, 5 insertions(+) create mode 100644 .vscode/settings.json diff --git a/.vscode/settings.json b/.vscode/settings.json new file mode 100644 index 000000000..b242572ef --- /dev/null +++ b/.vscode/settings.json @@ -0,0 +1,5 @@ +{ + "githubPullRequests.ignoredPullRequestBranches": [ + "main" + ] +} \ No newline at end of file From e6fda9559370e70083db4c188833581a2b2f1e90 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:20:58 +0200 Subject: [PATCH 06/11] Keep "InnerSource projects" in plural form --- patterns/2-structured/maturity-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index b2344c33f..636249bbc 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -30,7 +30,7 @@ Ask teams to self-assess against the proposed maturity model. #### Plans & Products -InnerSource project benefits from planning to be transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others. +InnerSource projects benefit from planning to be transparent across the organization by enabling stakeholders to better understand decisions and influence them in a way that can be followed by others. * PP-0: Individuals and teams do not regularly disclose their plans or products to multiple stakeholders. No formal actions exist in the organization. * PP-1: Individuals and teams give visibility to their plans or products to multiple stakeholders, before they are started. Shared roadmap. From 2e280f77f5ee81923abbea51bf547b64e6ea3c92 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:21:32 +0200 Subject: [PATCH 07/11] Update patterns/2-structured/maturity-model.md --- patterns/2-structured/maturity-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 636249bbc..5630b155a 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -41,7 +41,7 @@ InnerSource projects benefit from planning to be transparent across the organiza InnerSource projects thrive when contributors become active and participate. As a result, making contributions easier should be balanced with pure technical goals. -* DP-0: Each team follows its development process and tools. They are not defined to share knowledge and artifacts outside the development team. Siloed development teams. +* DP-0: Each team follows its own development process and tools. They are not defined to share knowledge and artifacts outside the 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 project 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. The code review process is 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. From 828d6e94391a236485b20ee5ddf16a5b883dbbb1 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:22:28 +0200 Subject: [PATCH 08/11] Fix start of "Rewards" sub-section --- patterns/2-structured/maturity-model.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 5630b155a..9467bf119 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -134,7 +134,9 @@ One of the possible reasons for introducing InnerSource into organizations can b ### Governance -### Rewards*To drive adoption, extrinsic motivators can be used to increase cross-team collaboration. +#### Rewards + +To drive adoption, extrinsic motivators can be used to increase cross-team collaboration. * RW-0: No rewards. * RW-1: Leaders are encouraged to reward exceptional collaborations, but there are no policies or processes established. From 162d1af3038f3b5eb8df1f5e5622fbdf18713238 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:23:37 +0200 Subject: [PATCH 09/11] Changing to genitive of the "teams" --- patterns/2-structured/maturity-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 9467bf119..5d0c39ed4 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -154,7 +154,7 @@ InnerSource projects need a means for self-assessment. Metrics can be one aspect #### Support and Maintenance -Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the team's core tasks. +Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams' core tasks. * SM-0: Support given by the core dev or support team. A business contract guarantees support. There is no knowledge about the product outside the team. * SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. From bdba6e42f3ac4377b2a9a84afa69dcd416985d70 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:24:10 +0200 Subject: [PATCH 10/11] Keeping original spelling --- patterns/2-structured/maturity-model.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 5d0c39ed4..146366d79 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -158,7 +158,7 @@ Not only should feature development be owned by InnerSource teams - support and * SM-0: Support given by the core dev or support team. A business contract guarantees support. There is no knowledge about the product outside the team. * SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. -* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like 30-Day[Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). +* SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). * SM-3: There are rules and regulations to formalize the support for the product, given by a mature community. #### Culture From 9bd3b2b9378393eaeced723bafcd217c1bb5d908 Mon Sep 17 00:00:00 2001 From: Sebastian Spier Date: Thu, 11 May 2023 20:24:30 +0200 Subject: [PATCH 11/11] Fix list formatting --- patterns/2-structured/maturity-model.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md index 146366d79..145facb62 100644 --- a/patterns/2-structured/maturity-model.md +++ b/patterns/2-structured/maturity-model.md @@ -172,8 +172,9 @@ Multiple levels are moving towards a collaborative culture. #### InnerSource Roles -InnerSource comes with explicit roles. While in the early stages, some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier.RO-0: No specific roles are helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. +InnerSource comes with explicit roles. While in the early stages, some patterns may be useable without adopting those roles, communicating within projects using explicit role titles becomes easier. +* RO-0: No specific roles are 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 is 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 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. The Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. The 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 the 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.