Merge branch 'main' into governance-based-project-setup

Author: spier

README.md

@@ -72,6 +72,7 @@ Our mission
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
 * [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
+* [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.*
 * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.*
 * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*
 * [InnerSource Guidance Group](patterns/1-initial/innersource-guidance-group.md) - *A highly divergent set of development standards in different teams can slow down collaboration between these teams. A InnerSource Guidance Group that establishes broad governance and behavioral guidelines can help to reduce these frictions.*
@@ -87,7 +88,8 @@ Our mission
 * [Code of Conduct](/patterns/1-initial/code-of-conduct.md) - *Communications and interactions between collaborators are rude, not inclusive or offensive, harming and increasing the discussions without any value added. A Code of Conduct provides guidelines for establishing rules and expectations regarding behavior and interactions within the community to build stronger levels of collaboration.*
 * [Trusted Committer and Contributor Retrospectives](/patterns/1-initial/cross-team-retrospectives.md) - *A host team working with contributors outside of their own line of management constantly runs into misunderstandings. As a result collaboration becomes brittle and frustrating. Setting aside time for regular retrospectives for the InnerSource team consisting of trusted committers and contributors can help make communication smooth.*
 * [InnerSource Hackathon](/patterns/1-initial/innersource-hackathon.md) - *In a company, initially only InnerSource enthusiasts are interested and practicing InnerSource during the early stages of InnerSource adoption; not all engineering teams are willing or have enough time and resources to adopt InnerSource. In this scenario, it is good to provide a safe space to try and adopt InnerSource through an InnerSource Hackathon event within the company.*
-* [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.*
+* [Managing Capacity for Reviewing Contributions](/patterns/1-initial/capacity-for-contributions.md) - *Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and, if accepted, released.*
+* [InnerSource Ambassadors](/patterns/1-initial/innersource-ambassador.md) - *When driving InnerSource adoption through a large, decentralized organization it is hard to understand and address the local challenges that come up in different departments and regions. Local volunteers, called InnerSource Ambassadors, provide localized support by promoting InnerSource principles and acting as a communication bridge between their teams and the ISPO.*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

patterns/1-initial/capacity-for-contributions.md

@@ -0,0 +1,76 @@
+## Title
+
+Managing Capacity for Reviewing Contributions
+
+## Patlet
+
+Reviewing InnerSource contributions takes time and effort. This should be reflected in capacity planning, especially for larger contributions. Expectations and available capacity should be transparent so that contributors understand when their contributions will be reviewed and, if accepted, released.
+
+## Problem
+
+Large InnerSource contributions are causing delays to other work in the team and/or contributions are taking longer to be released than expected. Reviewing contributions may be significant invisible work, not tracked in a team's Agile development process.
+
+## Story
+
+An application is built by a number of teams, each with different areas of responsibility. They work on each other's areas of the codebase via InnerSource on a regular basis.
+
+The team responsible for the build process for the JavaScript bundles received a major pull request, changing how dependencies were bundled. This PR introduced a new build time dependency, a new structure to the deployed JavaScript bundles, and touched 503 files, with 6,699 lines of code added and 2,828 lines of code deleted. A contribution of this size required significant time to code review, test, and ensure the team understood the new tooling and structure introduced.
+
+Normally, InnerSource contributions would be reviewed ad-hoc, but the team estimated that this review process would take days rather than hours. Reviewing this PR would have delayed the team's other work, so the team raised this with the team lead, project manager, and product manager, to prioritize this work against other work. Time was set aside to review this contribution at a future date.
+
+This process was formalized in the team:
+
+* Larger contributions have a ticket created on the team's backlog and included in prioritization discussion alongside other tickets.
+* The contributor will be informed of the priority call and given an estimate as to when it will be reviewed and released.
+* Smaller contributions can still be reviewed ad-hoc.
+
+## Context
+
+* Host team of a successful InnerSource project are finding it difficult to review contributions, especially large contributions.
+* They do not want to disrupt their team's other work, but also want to support contributions by reviewing/releasing them in a timely fashion.
+
+## Forces
+
+* Contributors expect timely feedback on their contributions
+* Host team are expected to deliver other work alongside reviewing contributions
+* Missing communication between contributors and host team on expectations/lead time for contributions to be reviewed/released
+* Tension in prioritizing InnerSource contributions against other work
+* Contributors already strive to make small PRs in line with Agile, InnerSource, and Continuous Delivery principles, but find instances where larger PRs are unavoidable
+
+## Solutions
+
+* Contributors are encouraged to give the host team early visibility of larger contributions (e.g. via GitHub Issues, draft PRs, [RFCs](../2-structured/transparent-cross-team-decision-making-using-rfcs.md), or informal discussions) and are made aware that not doing so could delay review of their contribution
+* Reviewing larger contributions is tracked in the team's ticketing system/bug tracker (e.g. Jira, GitHub issues)
+* Host team is given time to review larger contributions in team capacity planning
+* Reviewing contributions is prioritized against other work (e.g. in sprint planning)
+* Host team communicate their capacity for reviewing contributions, the priority of contributions, and an estimate of when a contribution will be reviewed/released
+* Host team has a service level objective (SLO) (e.g. 2 working days) for providing initial feedback to new contributions
+* Smaller contributions are still reviewed ad-hoc; the team may have guidelines on what they consider to be a smaller contribution (e.g. review should take less than an hour)
+
+## Resulting Context
+
+Host team understands the overhead of reviewing large contributions and is given capacity to do so. Project manager and product managers are better able to plan, estimate, and track other work in the team by accounting for the time taken to review InnerSource contributions. Contributors understand when their contribution will be reviewed and released, and how long before the host team will provide initial feedback.
+
+Smaller PRs are still reviewed ad-hoc, minimising overhead and unnecessary additional process.
+
+There may still be conflict in prioritising contribution reviews, especially if the host team is overburdened with other work. This only works if contributions are valued by the decision makers in the team's planning process.
+
+## Known Instances
+
+- BBC iPlayer & Sounds
+
+## Status
+
+Initial
+
+## Author(s)
+
+Tom Sadler
+
+## Acknowledgments
+
+Clare Dillon
+Sebastian Spier
+Guilherme Dellagustin
+Michael Basil
+Bill Westfall

patterns/1-initial/innersource-ambassador.md

@@ -0,0 +1,75 @@
+## Title
+
+InnerSource Ambassadors
+
+## Patlet
+
+When driving InnerSource adoption through a large, decentralized organization it is hard to understand and address the local challenges that come up in different departments and regions.
+Local volunteers, called InnerSource Ambassadors, provide localized support by promoting InnerSource principles and acting as a communication bridge between their teams and the ISPO.
+
+## Problem
+
+The InnerSource Program Office (ISPO) cannot be everywhere at once within a large, decentralized organization. Without localized support, the ISPO struggles to understand the unique challenges and needs of different departments or regions and cannot effectively promote InnerSource practices across the organization.
+
+## Story
+
+In a multinational organization, the ISPO implemented InnerSource initiatives but noticed uneven adoption across departments. After appointing a local ambassador in one department, adoption rates improved as the ambassador tailored practices to the department's context and provided valuable feedback to the ISPO.
+
+## Context
+
+- The organization is large and has multiple independent departments.
+- An ISPO has been established to drive InnerSource adoption.
+- There is a need for consistent and tailored InnerSource implementation across diverse teams.
+- Employees with a passion for collaboration and InnerSource principles are present within the organization.
+
+## Forces
+
+- **Geographical and organizational scale:** The ISPO cannot physically or logistically engage with every department.
+- **Communication barriers:** Departments may have unique cultures and needs that are not immediately visible to the ISPO.
+- **Workload balance:** Ambassadors must fulfill this role alongside their primary responsibilities.
+- **Trust and credibility:** Ambassadors must be trusted by their teams and the ISPO.
+
+## Sketch (optional)
+
+*A diagram showing the ISPO at the center, with ambassadors positioned in various departments acting as bidirectional conduits of information and influence.*
+
+## Solutions
+
+- Identify and recruit volunteer ambassadors from across the organization who are enthusiastic about InnerSource. They support InnerSource goals while maintaining their primary organizational roles.
+- Train ambassadors on InnerSource principles, tools, and the goals of the ISPO.
+- Establish clear expectations for ambassadors, including acting as a liaison, promoting InnerSource practices, and providing feedback to the ISPO.
+- Create a support network among ambassadors to share best practices and foster a sense of community.
+- Schedule regular check-ins between ambassadors and the ISPO to gather insights and provide guidance.
+
+## Resulting Context
+
+- Localized InnerSource support increases adoption and effectiveness.
+- The ISPO gains valuable, real-time feedback on challenges, successes, and opportunities within different departments.
+- Ambassadors become advocates for InnerSource, fostering a culture of collaboration.
+- Workload balancing remains a challenge, but most ambassadors find the role rewarding and career-enhancing.
+
+## Rationale
+
+InnerSource Ambassadors leverage their existing knowledge of their departments and relationships within the organization to address challenges the ISPO cannot solve alone. This decentralization of responsibility enhances the ISPO's reach while maintaining centralized oversight.
+
+## Known Instances
+
+- *SAP* has a concept called [Open Source Champions](https://community.sap.com/t5/open-source-blogs/sap-open-source-champions/ba-p/13539587) that seems related
+
+## Status
+
+- Initial
+
+## Authors
+
+- Sebastian Spier
+
+## Acknowledgments
+
+- [Russell R. Rutledge](https://github.com/rrrutledge) for sharing the idea and providing feedback
+- [Guilherme Dellagustin](https://github.com/dellagustin-sap) for sharing a similar concept used for open source adoption
+
+## Alias
+
+- Departmental InnerSource Representatives/Champion/Ambassador
+- Local InnerSource Representatives/Champion/Ambassador