# InnerSource Patterns WG - Report for Board Meeting 2023-05

## Meta

* Reporting Period: 2023-02..2023-04
* [merged PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+closed%3A2023-02..2023-04+is%3Amerged)
* [opened issues](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues?q=is%3Aissue+created%3A2023-02..2023-04+is%3Aopen)

## Engagement

The [patterns book] is the way InnerSource practices are captured and shared. Recent web analytics:

* stable traffic on the patterns book (tracking_id: `G-QL1S8MW5D9`)
  * 18,361 views total (previous report was 12,143 page)
  * that is 50% more traffic, so quite significant!
  * not sure where the increase in traffic comes from (didn't have time for a deep-dive)
* Most popular patterns:
  * Core Team
  * 30 Day Warranty
  * InnerSource Portal
  * Common Requirements
  * Maturity Model
* traffic for translations:
  * Japanese - 979 views total (somewhat continuous traffic but with spikes - probably around events of the Japanese community)
  * Chinese - 545 views total (most traffic around the time when the book was released at end of 2023/01)

## Changes

Changes are contributed via the [InnerSourcePatterns] repository:

* new visual and other improvements for the [Communication Tooling](https://patterns.innersourcecommons.org/p/communication-tooling) pattern - thank you @spier
* adding known instances to various patterns (BBVA, GitHub, Bosch) - thank you @rahermur, @zkoppert, @gruetter
* improvements to [Modular Code](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/modular-code.md) pattern. - thank you @fioddor
  * This is a case of a pattern that is around for years and still did not make it into our book. We suspect that many orgs are using this approach and might not even consider this an enabler for InnerSource. Might be too obvious! We have filed an issue to improve the pattern further and get it published in our book. So please [contribute](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/529)!
* New **Structured** patterns:
  * [Group Support](https://patterns.innersourcecommons.org/p/group-support) - great work @rrrutledge
* New **Initial** patterns:
  * none
* Last [Trusted Committer](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/TRUSTED-COMMITTERS.md) added was [@yuhattor](https://github.com/yuhattor) (added 2022-07-21)
* Trusted Committer candidates in the pipeline: No

## Next Goals (same as previous Board report)

The overall goals of this group are:

1. Increase number of people consuming the patterns. ("easier to discover", pattern of month, categories)
2. Increase the number and quality of patterns.
   1. Increase the number of people thinking to contribute. ("patterns in wild", "known instances")
   2. Increase probability of successful contribution. ("reduce review time", "lower barrier of entry")
   3. Optimise the existing content. (level-up more patterns, "known instances" again)

All goals will be progressed but we are prioritising effort towards 2.iii.

Specifically we want to get existing **Initial (L1)** patterns improved to **Structured (L2)**, so that we can publish them in the book.

We had a [discussion](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/486#discussion_r1029921121) about this and created a short-list of those patterns (details below).

We now have a [script](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/meta/scripts/find_upgradeable_patterns.rb) that identifies patterns that could be upgrade, based on the number of Known Instances only:

```
$ ruby find_upgradeable_patterns.rb
## Initial => Structured
## 1-Initial patterns primed for upgrade to 2-Structured (based on Known Instances only)
1 | ../../patterns/1-initial/innersource-guidance-group.md
1 | ../../patterns/1-initial/innersource-customer-interview-questions.md
2 | ../../patterns/1-initial/balancing-openness-and-security.md
1 | ../../patterns/1-initial/source-code-inventory.md
1 | ../../patterns/1-initial/incubator-pipeline.md
1 | ../../patterns/1-initial/include-product-owners.md
1 | ../../patterns/1-initial/introducing-metrics-in-innersource.md
1 | ../../patterns/1-initial/modular-code.md
1 | ../../patterns/1-initial/contained-innersource.md
1 | ../../patterns/1-initial/transitioning-contractor-code-to-innersource-model.md
1 | ../../patterns/1-initial/governance-levels.md

## Structured => Validated
## 2-Structured patterns primed for upgrade to 3-Validated (based on Known Instances only)
3 | ../../patterns/2-structured/30-day-warranty.md
5 | ../../patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md
3 | ../../patterns/2-structured/document-your-guiding-principles.md
4 | ../../patterns/2-structured/trusted-committer.md
3 | ../../patterns/2-structured/core-team.md
3 | ../../patterns/2-structured/maturity-model.md
5 | ../../patterns/2-structured/innersource-portal.md
3 | ../../patterns/2-structured/gig-marketplace.md
3 | ../../patterns/2-structured/project-setup/base-documentation.md
3 | ../../patterns/2-structured/project-setup/communication-tooling.md
```

### Shortlisted Patterns

Here you find more detail about the possible execution of this approach.
It is more information than what the Board needs. It may however help you to understand how we are reasoning about our patterns.

We identified these patterns as "low-hanging fruits", as they contain a **Known Instance** already, and that info is often hard to get.

We believe we can contact the respective authors/organizations, and ask them to review the patterns against the [Structured (L2) Requirements](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/meta/contributor-handbook.md#requirements-level-2---structured). The upside for those orgs is to get their pattern (and brand) published in our book.

We expect that with one round of review (or rather a single PR) we can get these patterns published in our book.

* **(in progress)** (Comcast) [release-process.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/release-process.md) - We kept this pattern in Initial to give the community time to review/harden this pattern before it goes into the book. - See [#524](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/524)
* **(in progress)** (Flutter, Europace) [governance-levels.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/governance-levels.md) - Proposed by Europace (Isabel) but further improved by Rob.
* (??? Tim Yao, Georg Grütter) [contained-innersource.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/contained-innersource.md) - This pattern has been around for a long time. It can try to contact the two authors and see if they want to bring it over the finish line.
* (Philips) [source-code-inventory.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/source-code-inventory.md)
* (Philips, Verizon) [balancing-openness-and-security.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/balancing-openness-and-security.md)
* (GitHub) [transitioning-contractor-code-to-innersource-model.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/transitioning-contractor-code-to-innersource-model.md)

[patterns book]: https://patterns.innersourcecommons.org/
[InnerSourcePatterns]: https://github.com/InnerSourceCommons/InnerSourcePatterns/
