Merge branch 'InnerSourceCommons:main' into main

Author: caldeirav

README.md

@@ -84,6 +84,9 @@ Our mission
 * [Incubator Pipeline](/patterns/1-initial/incubator-pipeline.md) - *A team maintaining a widely shared code library wants to accept contributions from other teams, without lowering the overall quality of their library. Therefore the shared library team uses an incubator pipeline to set a lower bar for contributions to enter and a higher bar to exit and become a top-level unit in the library.*
 * [InnerSource Customer Interview Questions](/patterns/1-initial/innersource-customer-interview-questions.md) - *An organization has decided to create an InnerSource program but are unsure which issues they should address first. Using a customer interview will help evaluate pain points across the organization, to prioritize the areas where InnerSource will have the biggest positive impact.*
 * [Creating an InnerSource Strategy](/patterns/1-initial/creating_an_innersource_strategy.md) - *Sometimes, it is difficult to convince people of the relevance of InnerSource for your organization and/or to get support from management. Creating an InnerSource strategy, that connects your InnerSource approach and activities to the goals and the overall strategy of your organization, can help in this regard.*
+* [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.*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

assets/img/code-of-conduct/CODE_OF_CONDUCT-for-the-community.png

@@ -0,0 +1,11 @@
+# Credits
+
+If you want to edit this illustration, please request access to this [source document](https://docs.google.com/presentation/d/11JOByEO9QXlRLXX5BIv9rjUzPzCKErZzknD1OLcprQQ/edit?usp=sharing).
+
+The humans in the illustration are [bro](https://storyset.com/illustration/coding/bro) and [pana](https://storyset.com/illustration/high-five/pana) from Storyset.
+
+See:
+
+- [Web illustrations by Storyset](https://storyset.com/web)
+- [People illustrations by Storyset](https://storyset.com/people)
+- [Community illustrations by Storyset](https://storyset.com/community)

assets/img/code-of-conduct/README.md

@@ -47,6 +47,7 @@ Instead edit toc_template.md
 ## Appendix
 
 * [Pattern Template](../../meta/pattern-template.md)
+* [Glossary](../../meta/glossary.md)
 * Extras
   * [README Template](../../patterns/2-structured/templates/README-template.md)
   * [CONTRIBUTING Template](../../patterns/2-structured/templates/CONTRIBUTING-template.md)

book/en/toc.md

@@ -24,6 +24,7 @@ Instead edit toc_template.md
 ## Appendix
 
 * [Pattern Template](../../meta/pattern-template.md)
+* [Glossary](../../meta/glossary.md)
 * Extras
   * [README Template](../../patterns/2-structured/templates/README-template.md)
   * [CONTRIBUTING Template](../../patterns/2-structured/templates/CONTRIBUTING-template.md)

book/en/toc_template.md

@@ -4,7 +4,9 @@ This glossary defines essential terms that are commonly used when writing new pa
 
 Through this the glossary helps members of the Patterns Working Group to use consistent language when writing and reviewing patterns.
 
-- **organization** - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)
 - **legal entity** - An entity that has its own legal rights and obligations (synonyms: company, subsidiary) (e.g. Lufthansa Systems GmbH, Lufthansa Industry Solutions TS GmbH, ...)
+- **organization** - An umbrella for multiple legal entities. (synonyms: group, enterprise) (e.g. Lufthansa)
+- **project** - Projects serve as a planning and tracking tool that can integrate with the issues and pull requests within one or more repositories. In [GitHub documentation](https://docs.github.com/en/issues/planning-and-tracking-with-projects/learning-about-projects/about-projects), projects are described as an adaptable spreadsheet, task-board, and road map that integrates with your issues and pull requests to help you plan and track your work effectively.  A single project can include items (e.g. issues and pull requests) from multiple repositories.
+- **repository** - A repository is a central location for source code, files, where each file's revision history is stored and managed. It enables version control and collaboration among multiple contributors. Repositories are designed to facilitate collaboration, discussion, and management of work through features like issues, pull requests, and project boards. A single repository can be associated with multiple projects.
 
 *Note that his glossary is far from complete. If you see terms that are used frequently in our patterns and should be defined in this glossary, please add them.*

meta/glossary.md

@@ -0,0 +1,95 @@
+## Title
+
+Code of Conduct
+
+## Patlet
+
+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.
+
+## Problem
+
+InnerSource initiatives often involve collaboration among individuals and teams from diverse backgrounds and perspectives.
+The absence of clear rules of communication and interaction leaves room for ambiguity and potential conflicts within the InnerSource community.
+Without established guidelines, members may engage in behavior that is harmful, discriminatory, or counterproductive, leading to a breakdown in collaboration and trust.
+
+## Context
+
+This pattern emerges when the communications between different team members are very far away of the goals, focused on personal references, blaming other opinions or following non-inclusive behaviors.
+
+Some examples of this context:
+
+* The organization has gone through a rapid growth phase, where maintaining a strong collaborative culture has suffered.
+* The organization has acquired multiple smaller organizations over a short period of time, and each of these organizations bring their own slightly different culture.
+* The organization is highly distributed over multiple countries, nationalities, cultures, and timezones.
+* Members of different teams at the organization have not established strong inter-personal relationships.
+* Previous attempts to establish ground rules for collaboration have been treated as mere lip service, and have had little to no effect.
+
+## Forces
+
+* Define or establish rules of communication to avoid conflicts.
+* Create a welcoming, respectful and inclusive environment to foster more collaboration.
+* Create trusted relationships across different teams.
+* Create the environment where all community members feel safe and valued.
+* Connect to corporate's compliance, and business ethics.
+
+## Solution
+
+Develop a Code of Conduct that outlines expected behavior, including guidelines for communication, collaboration, and conflict resolution.
+The Code of Conduct will articulate the shared values and principles of the InnerSource community, fostering a sense of belonging and common purpose, such as:
+
+- **Diversity**: InnerSource communities may consist of individuals with varying cultural backgrounds, beliefs, and communication styles.
+- **Trust**: Building trust among community members is essential for effective collaboration and knowledge sharing.
+- **Inclusivity**: A Code of Conduct and Social Contract can promote inclusivity by setting expectations for respectful behavior and interactions.
+- **Accountability**: Clear guidelines help hold community members accountable for their actions and contributions.
+
+## Implementation
+
+The adoption of well-known handbooks, such as the [Contributor Covenant](https://www.contributor-covenant.org/), or the adaptation of some internal employee handbooks for members of the organization are good starting points for implementation of this pattern.
+However, adopt the following life cycle can improve the implementation and adoption of the Code of Conduct in an InnerSource community:
+
+1. Collaboratively draft the Code of Conduct, involving input from community members representing diverse perspectives.
+2. Seek feedback and consensus from the community to ensure buy-in and ownership of the guidelines.
+3. Publish the finalized documents in a prominent location accessible to all community members, such as the [InnerSource portal](https://patterns.innersourcecommons.org/p/innersource-portal) or communication channels.
+4. Regularly review and update the Code of Conduct as needed to reflect evolving community norms and values.
+
+A good practice for the third point is to share the Code of Conduct in each InnerSource community repository as a file named `CODE_OF_CONDUCT.md`.
+In order to avoid content duplication of the Code of Conduct, another good practice is include a reference to a centralized resource within the organization where the content is published to all the InnerSource projects.  
+This file can be part of the [Standard Base Documentation](../2-structured/base-documentation.md) of any InnerSource project repository.
+
+![CODE_OF_CONDUCT.md](../../assets/img/code-of-conduct/CODE_OF_CONDUCT-for-the-community.png)
+
+It is important to understand that simply adopting a Code of Conduct will not prevent conflict or toxicity in the InnerSource project.
+The [Core Team](https://patterns.innersourcecommons.org/p/core-team) and [Dedicated Community Leader](https://patterns.innersourcecommons.org/p/dedicated-community-leader) are responsible for the safe, fair, and transparent enforcement of the community's code of conduct.
+That responsibility will imply provide a reporting process, a gathering information process and the consequences of any unacceptable behavior.
+These references must be part of the Code of Conduct to encourage the behavior expected in the InnerSource project.  
+
+## Resulting Context
+
+With a well-defined Code of Conduct in place, the InnerSource community can cultivate a culture of respect, trust, and collaboration.
+Community members feel empowered to contribute openly and engage in meaningful dialogue, leading to enhanced innovation and problem-solving.
+
+## Known Instances
+
+- Red Hat - Many of the internal communities
+- National Australia Bank
+- GitHub (Company wide "Handbook for Hubbers")
+
+## Authors
+
+- Roman Martin Gil
+
+## Acknowledgments
+
+- Matt Cobby - Adding the National Australia Bank reference
+
+## References
+
+- [InnerSource Commons Pattern - Standard Base Documentation](../2-structured/base-documentation.md)
+- [Open Practice Library - Social Contract](https://openpracticelibrary.com/practice/social-contract/)
+- [Contributor Covenant](https://www.contributor-covenant.org/)
+- [GitHub Open Source Guide: Code of Conduct](https://opensource.guide/code-of-conduct/)
+
+## Status
+
+- Initial

patterns/1-initial/code-of-conduct.md

@@ -0,0 +1,78 @@
+## Title
+
+Trusted Committer and Contributor Retrospectives
+
+## Patlet
+
+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.
+
+## Problem
+
+For long running collaborations friction between host team and collaborators is substantially reducing focus and energy for everyone involved.
+Willingness to continue the collaboration is shrinking.
+
+## Context
+
+A host team of [trusted committers](../2-structured/trusted-committer.md) has started a long running collaboration with a group of contributors.
+
+* Over time the number of misunderstandings grows.
+* People may run into mis-communication.
+* Teams may discover slight differences in development culture.
+* Team members may discover that assumptions they made about how the other team works are false.
+* Contribution processes may not be entirely clear and workable for everyone involved.
+
+## Forces
+
+* Participants are inclined to take "written over verbal" as "only written".
+* Trusted committers are all part of the same team.
+* There is a group of contributors all coming from the same team.
+* As a result trusted committers know each other well and understand constraints, prioritization side effects and team dynamics without ever sharing them with contributors.
+* Also contributors form a well knit group.
+* The contribution process is seen as transient and temporary.
+As a result little is invested in forming a shared team of trusted committers and contributors.
+* There is no clear path from contributor to becoming trusted committer - other than becoming a member of the host team.
+
+## Solution
+
+Bring host team and contributors together:
+
+* As a first step it can help to share a meal together and get to know each other.
+* For collaborations running over several weeks establish a monthly retrospective meeting that involves everyone who is needed for a successful contribution.
+* Make sure that action items for each restrospective are being followed up upon, ideally check these action items at the beginning of the next retrospective.
+* Keep the agenda of retrospectives stable and predictable: It's already uncomfortable enough to name and resolve collaboration issues.
+
+Example agenda:
+
+* 5 minute check-in so everyone can test their audio setup, silly questions preferred so people can laugh together, reducing overall stress.
+* 5 minute review for action items from last meeting (each item presented by its owner)
+* 10 minutes to gather strengths and weaknesses of the past collaboration time period. Do this as a combination of writing (sticky notes on a digital white board) and verbally explaining the stickies to make sure introverts get involved as well.
+* 2 minutes to put dots against weaknesses that should be addressed in the next cycle. Pick the top 1-2 weaknesses.
+* 10 minutes to gather potential remedy actions to address the picked weaknesses. Again use time for writing sticky notes to involve everyone.
+* 2 minutes to put dots against action items (each participant may add 2-3 dots), pick at most top 3 items, assign each item two owners - one trusted committers and one contributor.
+* 5 minutes for checkout so everyone can wind down and leave feedback on the meeting.
+
+Caveat: In particular for cases where people have tried to collaborate for a long time already, the initial meeting may need more than 30 minutes.
+
+## Resulting Context
+
+* Trusted committers understand how to improve communication and contribution processes.
+* Contributors understand how to support trusted committers in improving documentation and processes.
+* Likely both uncover issues that are beyond their direct control but also see ways to address these in the organisation adopting InnerSource.
+* Ideally several learnings can be shared with other InnerSource teams so they avoid running into the same trouble.
+* When done regularly after a handful of retrospectives collaboration improves, issues uncovered reduce, turning the session more and more into a lot of positive feedback. As a result motivation on both sides increases.
+* [Communication Tooling](../2-structured/communication-tooling.md) and [Base Documentation](../2-structured/base-documentation.md) improves.
+
+## Related material
+
+* [Generator for check-in questions](https://www.checkin-generator.de) (in German)
+* [Examples of retrospective formats](https://retromat.org/en/)
+
+## Known Instances
+
+* Europace AG
+
+## Status
+
+Initial