Create a plan to level up existing patterns

[spier]

Things that we could do (in random order):

• (priority) promote patterns from Initial to Structured / this would get them published in the book
  • Possible organize a hackathon of sort around this?
• Do we need to revisit our Pattern maturity model? (i.e. the Levels 1,2,3)
  • Do the content and validation requirements for our patterns still make sense for us? If not, let's change them :)
  • See contributor handbook
  • See discussion Why publish patterns in a staged approach? #762
• (later) promote patterns from Structured to Validated
• orphaned patterns / how to create an offloading path for patterns? (i.e. deprecating patterns, no matter what maturity they were at before)

Initial => Structured

1-Initial patterns primed for upgrade to 2-Structured (based on Known Instances only)

# orgs	pattern	ready to be leveled up?
0	assisted_compliance.md
0	bad-weather-for-liftoff.md
2	balancing-openness-and-security.md	yes
1	capacity-for-contributions.md	yes - one more Known Instance would be great
0	change-the-developers-mindset.md
0	change-the-middle-management-mindset.md
3	circle-communities.md
0	code-consumers.md
3	code-of-conduct.md	yes - could be a bit more targeted towards InnerSource
0	concept-anchor.md
1	contained-innersource.md
1	creating_an_innersource_strategy.md
1	cross-team-retrospectives.md	no - Seems like a relatively obvious practice though, especially in orgs/teams that do team-internal retrospectives anyways. I would expect that we can find more orgs that have used this pattern, without knowing that it exists.
0	crossing-chasm.md
0	cultural-change-through-hiring.md
0	defeat-hierarchical-constraints.md
0	developer-incentive-alignment-for-innersource-contribution.md
2	discover-your-innersource.md	maybe - 2 Known Instances were added. work to level up started in #780
2	document-architecture-decisions.md	maybe - pattern was only recently added, without involvement from an author from the orgs mentioned as known instances. would benefit from contributions from other people before leveling it up
0	duplicated-projects.md
0	explicit-shared-ownership.md
0	good-first-project.md
0	governance-based-project-setup.md
0	improve-findability.md
0	incentive-mechanisms-for-voluntary-contribution.md
1	include-product-owners.md
1	incubator-pipeline.md
3	innersource-ambassador.md	yes - Siemens is another org that just confirmed that they use something like this. This pattern was partly written by AI. Next steps: a) thorough review by any of the adopting orgs (e.g. SAP) maybe a visual that we can use?
2	innersource-customer-interview-questions.md
1	innersource-guidance-group.md
1	innersource-hackathon.md	no - Hackathons are widely adopted at companies. Wondering if we can find more orgs that have used that existing hackathons to increase the InnerSource practice between teams.
0	innersource-portal-hygiene.md
0	internal-developer-platform.md	maybe - one would expect that we can find some known instances for this pattern but so far we have not. also much like the "code of conduct" pattern this one could be more targeted towards InnerSource
1	introducing-metrics-in-innersource.md
0	junkyard-styled-innersourcing.md
1	modular-code.md	no - Lack of modularization in the software architecture prevents reuseability. Therefore this pattern seems like a baseline requirement for any InnSource activity. Maybe this is is so basic, that orgs don't even realize that they are actually using this pattern. An extension of this pattern could be to invest even more in modularization, to create more opportunities for reuse (and with that opportunities for InnerSource).
0	not-invented-here.md
0	open-source-trumps-innersource.md
0	organizational-mindset-change.md
0	overcome-acquisition-based-silos-developer.md
0	overcome-acquisition-based-silos-manager.md
0	overcoming-project-management-time-pressures.md
0	reluctance-to-accept-contributions.md
0	share-your-code-to-get-more-done.md
0	shared-code-repo-different-from-build-repo.md
1	source-code-inventory.md	yes - if we can integrate the working knowledge from Philips, and find one more Known Instance. work started in #779
0	sustainable-innersource-program.md
1	transitioning-contractor-code-to-innersource-model.md
3	walk-the-innersource-talk.md	yes - check the pattern name. shorten patlet. Check the unverified solutions in the pattern.

Structured => Validated

2-Structured patterns primed for upgrade to 3-Validated (based on Known Instances only)

# orgs	pattern	ready to be leveled up?
4	30-day-warranty.md	yes
5	base-documentation.md	yes
1	common-requirements.md
3	communication-tooling.md	yes
1	contracted-contributor.md
3	core-team.md	yes
1	crossteam-project-valuation.md
2	dedicated-community-leader.md
3	document-your-guiding-principles.md	yes
1	extensions-for-sustainable-growth.md
3	gig-marketplace.md	yes
2	governance-levels.md	maybe - in 3/2025 levelled up to structured - see #765
1	group-support.md
4	innersource-license.md	yes
5	innersource-portal.md	yes
1	issue-tracker.md
4	maturity-model.md	yes
2	praise-participants.md
2	release-process.md
2	repository-activity-score.md
1	review-committee.md
3	service-vs-library.md	yes
2	start-as-experiment.md
6	transparent-cross-team-decision-making-using-rfcs.md	yes
4	trusted-committer.md	yes

[rrrutledge]

Sebastian - do you and @meller13 want to come back to the ISPO working group to present on what we can do next to uplevel these patterns and get more of them in the online book? We never really circled back on that line of thinking.

[spier]

@rrrutledge the approach I would suggest for a couple of weeks:

• Identify 2 people from the ISPO WG that have time to actively work on leveling up a pattern. (@meller13 could be one of those, if she has time)
• Pick 2 patterns that look like they could be promoted to the book within a couple of weeks.
• Organize a working session with those 2 people, to get to a common understanding of what is required to promote the patterns (and created documentation about this if missing)
• Then work async with those contributors via PR/Slack for a couple of weeks

Whether this approach can work will depend mostly on these two points:

1. Can we find people that have time to do the work?
2. Can get to a shared sense of quality expectations for a pattern to be published to the book? (this we would find out by doing actively working on this together)

I am happy to come to the ISPO working group to explain that idea and work in feedback.

However we could also ask async "who has time". Because if there is nobody, then the idea won't fly :)