From 1386d21310cd5c62c4c498f411105e4b00b1281e Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Tue, 11 Aug 2026 10:55:23 -0500 Subject: [PATCH 1/5] Add GitLab as Known Instance across two patterns Based on Raimund Hook's InnerSource Commons talk "Break the contribution wall" (April 2026), GitLab's DevRel Engineering team's contributor-growth program is added as a Known Instance to: - Incentive Mechanisms for Voluntary Contributions: contributors.gitlab.com gamifies contribution across code, review, docs, and translations with points, levels, and leaderboards, unlocking exclusive contributor swag - replaces "TBD" Known Instances - Internal Developer Platform: GitLab containerized their GDK, cutting new-contributor environment setup from ~2 hours (often failing) to under 5 minutes Co-authored-by: Claude Sonnet 5 --- .../incentive-mechanisms-for-voluntary-contribution.md | 2 +- patterns/1-initial/internal-developer-platform.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md b/patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md index 7c911f919..82b3d65b9 100755 --- a/patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md +++ b/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 diff --git a/patterns/1-initial/internal-developer-platform.md b/patterns/1-initial/internal-developer-platform.md index ba7d45266..40d9421aa 100644 --- a/patterns/1-initial/internal-developer-platform.md +++ b/patterns/1-initial/internal-developer-platform.md @@ -123,7 +123,7 @@ An IDP provides a solution to the competing forces of consistency, flexibility, ## Known Instances -(known instances to be added) +* **GitLab** - GitLab containerized their GitLab Development Kit (GDK), cutting new-contributor environment setup from roughly two hours (frequently failing) to under five minutes. This directly reduced time-to-first-contribution for both open source and InnerSource-style contributors. See: [Break the contribution wall](https://www.youtube.com/watch?v=d3igPlTr4Ag) (InnerSource Commons, 2026, by Raimund Hook). ## Status From 4ae4a446dd8ae7322bb2066545f89b09e8df6c73 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 08:22:56 -0500 Subject: [PATCH 2/5] Draft new pattern: Paired Onboarding Sprint Also from Raimund Hook's "Break the contribution wall" talk: GitLab's Co-create program pairs a host-team engineer with a high-value potential contributor for a dedicated week to make their first real contribution together. No existing pattern covers this structured 1:1 onboarding model, and it passes the "uniquely InnerSource" filter - it addresses contributors outside the host team's shared context, not generic onboarding advice. Filed at maturity level 1 (Initial), which requires no validation per meta/contributor-handbook.md - one known instance is exactly what this level is for. Bundled into this PR with the other two Known Instance additions from the same talk, per the "one talk = one PR" convention. Co-authored-by: Claude Sonnet 5 --- .../1-initial/paired-onboarding-sprint.md | 61 +++++++++++++++++++ 1 file changed, 61 insertions(+) create mode 100644 patterns/1-initial/paired-onboarding-sprint.md diff --git a/patterns/1-initial/paired-onboarding-sprint.md b/patterns/1-initial/paired-onboarding-sprint.md new file mode 100644 index 000000000..1ffcd1aea --- /dev/null +++ b/patterns/1-initial/paired-onboarding-sprint.md @@ -0,0 +1,61 @@ +## 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. + +## 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 + +* TBD + +## 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. From b5355aec39332db93d3c0de1123fd6e57bcecb9a Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 12:18:19 -0500 Subject: [PATCH 3/5] Drop GitLab GDK from Internal Developer Platform Known Instances GDK is a local development environment a contributor runs on their own machine, not the centralized, deployed self-service platform this pattern describes. Per Sebastian Spier's review on #926. --- patterns/1-initial/internal-developer-platform.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patterns/1-initial/internal-developer-platform.md b/patterns/1-initial/internal-developer-platform.md index 40d9421aa..ba7d45266 100644 --- a/patterns/1-initial/internal-developer-platform.md +++ b/patterns/1-initial/internal-developer-platform.md @@ -123,7 +123,7 @@ An IDP provides a solution to the competing forces of consistency, flexibility, ## Known Instances -* **GitLab** - GitLab containerized their GitLab Development Kit (GDK), cutting new-contributor environment setup from roughly two hours (frequently failing) to under five minutes. This directly reduced time-to-first-contribution for both open source and InnerSource-style contributors. See: [Break the contribution wall](https://www.youtube.com/watch?v=d3igPlTr4Ag) (InnerSource Commons, 2026, by Raimund Hook). +(known instances to be added) ## Status From 0adaa7a64a09a31970f121faecb21f6e4cc5c740 Mon Sep 17 00:00:00 2001 From: Russ Rutledge Date: Wed, 12 Aug 2026 14:29:57 -0500 Subject: [PATCH 4/5] List Paired Onboarding Sprint pattern in README --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index 5067007c6..b48fd7f9e 100644 --- a/README.md +++ b/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.*