New Pattern: Add Centralised InnerSource Repository Governance pattern

[amburi]

Summary

Adds a new InnerSource pattern for maintaining repository contributor readiness at scale through a central
governance repository, policy-as-code, and scheduled readiness audits.

Changes

• Introduces the Centralised InnerSource Repository Governance pattern.
• Frames governance around InnerSource readiness, discoverability, documentation, ownership, communication,
  and contribution paths.
• Defines readiness policies for checks such as README.md, CONTRIBUTING.md, CODEOWNERS, issue/PR templates, labels, portal metadata, and trusted collaboration settings.
• Adds guidance for repository inventory, policy profiles, exception handling, and source-of-truth
  boundaries.
• Covers incremental, rate-aware audits to reduce GitHub API and CI infrastructure strain.
• Clarifies roles for contributors, Trusted Committers, repository maintainers, ISPO/community stewards,
  platform/security partners, and Product Owners.
• Includes governance repository protection, reporting principles, remediation guidance, and operating
  metrics.
• Links related InnerSource patterns.

[spier]

@amburi this pattern looks great already! I left some minor comments.

Just curious:
The pattern sounds like you already have a reference implementation of this. If you want you could share more in the Solution section about the stack that you used to implement this.

Or if you have open sourced that work, you can of course also link to that (although I am assuming that this is an internal project at your org rather?).

[spier]

Suggested change

	Create a **central InnerSource governance repository** that defines contributor-readiness expectations as policy-as-code and audits repositories in scope. Treat it as an internal product with clear roles, review rules, actionable reports, and an exception process.
	Create a **central InnerSource governance repository** that defines contributor-readiness expectations as policy-as-code. Run audits of these policies across all repositories in scope.
	Treat it as an internal product with clear roles, review rules, actionable reports, and an exception process.

[spier]

Suggested change

	Maintain the audit scope in `repository-inventory.yml`, or import it from an InnerSource Portal or source code inventory.
	Maintain the audit scope in `repository-inventory.yml`, or import it from an [InnerSource Portal](../2-structured/innersource-portal.md) or [Unified Source Code Inventory](../1-initial/source-code-inventory.md).

[spier]

Suggested change

	* [Unified Source Code Inventory](source-code-inventory.md) — can provide audit scope and repository metadata.
	* [Unified Source Code Inventory](../1-initial/source-code-inventory.md) — can provide audit scope and repository metadata.

Even if the files are in the same folder, I like to include the folder name in the link, as that clearly shows which maturity this pattern is at. This also makes it simple to copy the links to different patterns.

[spier]

I am moving this content to Context, as the purpose of that section is to allow a reader to decide whether the pattern is applicable for them. So this context here fits that purpose perfectly.

Suggested change

	## Use This Pattern When
	* You have many InnerSource repositories owned by different teams.
	* Contributors struggle to identify how to use or contribute to projects.
	* InnerSource Portal quality depends on repository metadata and project hygiene.
	* Manual readiness checks are too slow or incomplete.
	* You want transparent policy-as-code instead of undocumented central checks.
	* Poor contributor experience costs more than maintaining the governance process.
	## Don’t Use This Pattern When
	* Only a few InnerSource repositories exist and manual support is enough.
	* You need hard enforcement at merge time rather than periodic guidance.
	* You cannot maintain repository ownership or lifecycle metadata.
	* You cannot protect the governance repository and its credentials.
	* Most projects require unique contribution models that do not fit a small set of profiles.

[spier]

Suggested change

	### Use This Pattern When
	* You have many InnerSource repositories owned by different teams.
	* Contributors struggle to identify how to use or contribute to projects.
	* InnerSource Portal quality depends on repository metadata and project hygiene.
	* Manual readiness checks are too slow or incomplete.
	* You want transparent policy-as-code instead of undocumented central checks.
	* Poor contributor experience costs more than maintaining the governance process.
	### Don’t Use This Pattern When
	* Only a few InnerSource repositories exist and manual support is enough.
	* You need hard enforcement at merge time rather than periodic guidance.
	* You cannot maintain repository ownership or lifecycle metadata.
	* You cannot protect the governance repository and its credentials.
	* Most projects require unique contribution models that do not fit a small set of profiles.