Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern

.lycheeignore

@@ -14,4 +14,6 @@ https://www.linkedin.com/in
 # from source-code-inventory.md / no longer reachable but we want to keep the link in the pattern in case we find it again.
 https://github.com/trieshard/source-strategy-assessment/blob/master/framework.md
 https://dl.acm.org/doi/10.5555/3158161.3158175
-https://retromat.org/en/
+https://retromat.org/en/
+# O'Reilly returns 403 to the link checker's automated requests, though the page loads fine in a browser.
+http://www.oreilly.com/pub/e/3884

README.md

@@ -100,6 +100,7 @@ Our mission
 * [Centralized InnerSource Repository Governance](patterns/1-initial/centralized-repository-governance.md) - *InnerSource repositories lose contributor readiness when project hygiene drifts across teams. A central governance repository defines readiness checks as policy-as-code and runs automated audits that help Trusted Committers and repository maintainers keep projects discoverable, understandable, and contribution-ready without removing local ownership.*
 * [InnerSource as a Career Booster](patterns/1-initial/innersource-as-career-booster.md) - *Many employees wonder how contributing to InnerSource projects benefits their careers beyond their immediate team objectives. By engaging in InnerSource, individuals expand their skills, grow their network, increase visibility across the organization, and unlock new career opportunities.*
 * [Migrating from InnerSource to Open Source](patterns/1-initial/migrating-from-innersource-to-open-source.md) - *When an InnerSource project succeeds internally and meets criteria for external release, organizations often lack a structured approach for the transition. Establish a process that addresses legal, security, governance, and community readiness to transition the project to open source while maintaining its internal value.*
+* [Paired Onboarding Sprint](patterns/1-initial/paired-onboarding-sprint.md) - *Potential contributors who already depend on a shared project often stall before their first contribution - not for lack of ability, but because starting feels too costly to attempt alone. Pair a high-value potential contributor with a host-team engineer for a dedicated, bounded sprint to make their first real contribution together.*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md

@@ -116,7 +116,7 @@ This approach targets key human motivators for voluntary participation: financia
 
 ## Known Instances
 
-TBD
+* **GitLab** - GitLab's DevRel Engineering team built [contributors.gitlab.com](https://contributors.gitlab.com), a platform that gamifies contribution across code, code review, documentation, and translations with points, levels, and leaderboards. Points unlock access to exclusive contributor-only swag, redeemable only through sustained contribution. See: [Break the contribution wall](https://www.youtube.com/watch?v=d3igPlTr4Ag) (InnerSource Commons, 2026, by Raimund Hook).
 
 ## Status
 

patterns/1-initial/paired-onboarding-sprint.md

@@ -0,0 +1,63 @@
+## Title
+
+Paired Onboarding Sprint
+
+## Patlet
+
+Potential contributors who already depend on a shared project often stall before their first contribution - not for lack of ability, but because starting feels too costly to attempt alone. Pair a high-value potential contributor with a host-team engineer for a dedicated, bounded sprint to make their first real contribution together.
+
+## Problem
+
+Potential contributors who already use a shared project are often the best future contributors, but self-service onboarding material alone rarely converts them. Common blockers aren't knowledge gaps a README can fix - they're activation-energy problems: not knowing where to start, not having time to learn an unfamiliar codebase alone, assuming their own team won't prioritize the work, or not wanting to take on open-ended maintenance. An interested, capable person can stay stuck at "aware and willing" indefinitely without ever attempting a first contribution.
+
+## Story
+
+GitLab's DevRel Engineering team runs a program called Co-create. They identify a "high-value contributor" - someone already actively using GitLab's own tooling, with a clear ongoing need - and send one of their engineers to spend a dedicated week working alongside that person on a real feature. The engineer provides a clear guide through the codebase and the entire contribution process, not just pair-programming the code itself. By the end of the week the contributor has independent momentum: a real contribution in flight, a working understanding of how to contribute again unassisted, and in some cases the start of a path to mentoring other contributors themselves.
+
+## Context
+
+- A shared project already has self-service onboarding material (docs, good-first-issues, a portal) but conversion from "aware and interested" to "actually contributed" stays low.
+- Some potential contributors are identifiable in advance as high-value - people already depending on or using the project - rather than random newcomers.
+- The host team has enough capacity to dedicate one engineer's time for a bounded period.
+- The barrier is activation energy and structural friction, not a lack of technical ability or interest.
+
+## Forces
+
+**Host-team time cost vs. contributor lifetime value** - a dedicated engineer-week is a real cost, weighed against a contributor who may go on to contribute (and mentor others) indefinitely.
+
+**Selecting who gets this treatment** - not every potential contributor can receive a dedicated sprint, so the host team must judge who is high-value enough to justify the investment.
+
+**Risk of a one-off** - the contributor could complete the sprint but never contribute again without a clear handoff back to the project's normal self-service paths.
+
+## Solutions
+
+Identify a specific, already-engaged potential contributor - not a cold newcomer - who has a clear need the project could meet. Assign one host-team engineer to work with them for a bounded period (GitLab uses one week) on a real feature or fix the contributor actually cares about. Provide a guide through the whole contribution workflow, not just the code: where things live, how review works, who to ask. At the end, make sure the contributor leaves with independent momentum - a merged or nearly-merged contribution, a working understanding of how to contribute again alone, and ideally an on-ramp toward mentoring future contributors themselves.
+
+## Resulting Context
+
+The contributor is meaningfully more likely to keep contributing on their own, and the host team gains a return contributor without needing ongoing dedicated support. Some sprint participants go on to mentor other contributors, extending the pattern's value beyond the original pairing. This works best as a complement to self-service onboarding (see [InnerSource Portal](../2-structured/innersource-portal.md), [Standard Base Documentation](../2-structured/base-documentation.md)) rather than a replacement for it - the sprint is reserved for the highest-value candidates, not a scalable default path for every contributor.
+
+## Rationale
+
+Self-service onboarding assumes the only barrier is information: if the docs are good enough, people will find their own way in. But for a contributor who is already interested and capable, the real barrier is often activation energy - the first contribution feels too costly to attempt alone, so it never gets attempted. A dedicated, bounded, human-guided sprint directly removes that activation-energy barrier for the contributors most worth the investment, converting passive users into active contributors and, sometimes, into future mentors themselves.
+
+GitLab treats this as one piece of a broader respect for a contributor's time: alongside Co-create, they containerized their local development environment (the GitLab Development Kit), cutting setup from roughly two hours to under five minutes. The reasoning is the same either way - the less time a contributor spends fighting tools or navigating an unfamiliar codebase alone, the sooner they reach real contribution work, and the less likely they are to abandon the attempt.
+
+## Known Instances
+
+* **GitLab** - GitLab's "Co-create" program identifies high-value potential contributors (people already using GitLab's own tooling) and sends an engineer to spend a dedicated week guiding them through their first real contribution, followed by support as they build independent momentum. See: [Break the contribution wall](https://www.youtube.com/watch?v=d3igPlTr4Ag) (InnerSource Commons, 2026, by Raimund Hook).
+
+## Status
+
+* Initial
+* One known instance (GitLab) as of August 2026 - not yet validated across multiple organizations.
+
+## Authors
+
+* Raimund Hook
+
+## Related Patterns
+
+* [InnerSource Portal](../2-structured/innersource-portal.md) - self-service discovery this pattern complements rather than replaces.
+* [Standard Base Documentation](../2-structured/base-documentation.md) - the self-service onboarding path most contributors should still use; this pattern is for the subset worth a dedicated sprint.
+* [Trusted Committer](../2-structured/trusted-committer.md) - sprint participants who go on to mentor others are a natural path toward this role.