Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern - #926
Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern#926rrrutledge wants to merge 6 commits into
Conversation
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 <noreply@anthropic.com>
| ## 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). |
There was a problem hiding this comment.
Does "new-contributor environment setup" refer to the local development environment on a laptop?
And is this pattern referring to local development environments, or rather remote infrastructure that a software package is deployed to (like a DEV/STAGING/PROD environment)?
Or is the difference insignificant?
Aside: If this is the repo of the GDK, we could add a link to this: https://gitlab.com/gitlab-org/gitlab-development-kit
There was a problem hiding this comment.
Good question — and you're right, this doesn't belong here. The GDK is a local development environment a contributor runs on their own laptop (via GDK-in-a-box, a containerized GitLab instance), not the centralized, deployed self-service platform this pattern describes. I've dropped it from this pattern's Known Instances rather than trying to make it fit — pushed in b5355ae.
There was a problem hiding this comment.
I'll have to work on the Claude skill to make this better 🤔
|
The |
lychee cannot resolve links like /assets/img/foo.png without being told the repo root, so any changed file containing a pre-existing root-relative link fails the check even though the link is valid. Pass --root-dir . so lychee resolves these against the repo root. Observed in PR #926, which failed on an unrelated pre-existing image link.
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 <noreply@anthropic.com>
The old guidance ("one talk is one data point, not proof a pattern is
widely applicable") read as a reason to hold back drafting a genuine
new-pattern candidate. But this process only ever sees one talk at a
time, so that standard would mean a new pattern candidate never gets
drafted at all. Checked meta/contributor-handbook.md: maturity level 1
(Initial) has NO validation requirement - it's explicitly for a single
unstructured idea. One instance is what's needed for level 2
(Structured); only 3+ need level 3 (Validated). So the guidance now says
to draft at Initial from one talk, which is exactly what that level is
for - confirmed against Paired Onboarding Sprint (InnerSourceCommons#926), the first
pattern this skill has drafted this way.
Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com>
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 InnerSourceCommons#926.
…stance Topical keyword overlap (e.g. 'developer environment') isn't enough - the GDK/Internal Developer Platform mismatch on InnerSourceCommons#926 happened because a local dev tool got matched to a pattern about centralized, deployed platforms purely on theme.
Same talk, same underlying point (respect the contributor's time) - not a separate Known Instance, since no pattern actually covers local dev-environment setup friction as its own solution.
443b9d3 to
a616aba
Compare
O'Reilly returns 403 to lychee's automated requests, so the June 2017 webinar link fails the PR link checker even though the page loads fine in a browser. Keep the link in the README and add it to .lycheeignore so CI stops flagging it. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EDwBfCivCNdKJA2BexAizd
a616aba to
63316d6
Compare
* Add analyze-innersource-video Claude Code skill Adds a Claude Code skill that analyzes an InnerSource Commons community call video against this repo's pattern library: it fetches the talk's transcript and metadata, surveys adjacent patterns, and categorizes the talk's content into Known Instance candidates, clarifications to an existing pattern, or genuinely new pattern candidates - applying a "uniquely InnerSource" filter to screen out generic engineering advice that isn't specific to cross-team, cross-org contribution dynamics. The skill always proposes and asks for confirmation before editing any pattern file or opening a PR - it never auto-commits. This was already used manually to produce the Thales Group Known Instance PR (#909); this commit is the first time the skill itself is checked into the repo rather than living only on one contributor's machine. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> * Accept a transcript directly, and bundle one talk into one PR Two corrections per review: - Step 1 now accepts a transcript handed to it directly (the going-forward case: an automated source pulls a Zoom transcript once a community call finishes, with no YouTube URL involved at all) as well as a YouTube URL to fetch from - the URL-fetch path stays for backlog talks and one-off requests. - Step 8's "one concern per PR" is replaced with "one talk = one PR": bundle everything a single talk's analysis found - Known Instances across multiple patterns, clarifications, new pattern drafts - into one PR, matching how #909 actually added Thales across five patterns in a single PR. Only split PRs across genuinely different source talks. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> * Write the whole skill as transcript-first, not YouTube-first Per review: stop framing this as two parallel input paths ("YouTube URL or transcript"). The skill takes a transcript - full stop; where it came from is the caller's concern, not something this document needs to branch on. YouTube-specific fetch mechanics (youtube-transcript-api, yt-dlp) stay as a practical note for when a transcript still needs to be pulled from a video, not as the document's primary framing. Generalizes metadata field descriptions and "cite the source link" away from video-specific phrasing, and retitles the output template's "Video summary" to "Talk summary" to match. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> * Stop discouraging new-pattern drafts from a single talk The old guidance ("one talk is one data point, not proof a pattern is widely applicable") read as a reason to hold back drafting a genuine new-pattern candidate. But this process only ever sees one talk at a time, so that standard would mean a new pattern candidate never gets drafted at all. Checked meta/contributor-handbook.md: maturity level 1 (Initial) has NO validation requirement - it's explicitly for a single unstructured idea. One instance is what's needed for level 2 (Structured); only 3+ need level 3 (Validated). So the guidance now says to draft at Initial from one talk, which is exactly what that level is for - confirmed against Paired Onboarding Sprint (#926), the first pattern this skill has drafted this way. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> * Read README's pattern list instead of extracting patlets Per Sebastian Spier's review: the repo's own README.md already has a "List of Patterns" section with every pattern's title and patlet, kept current as patterns are added (spot-checked against the newest merged pattern - it's there). Reading that one file directly is simpler and more reliable than writing and running a script to walk the patterns/ directory and regex out each Patlet section. Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Sebastian Spier <github@spier.hu> * Require checking a pattern's actual Solution before citing a Known Instance Topical keyword overlap (e.g. 'developer environment') isn't enough - the GDK/Internal Developer Platform mismatch on #926 happened because a local dev tool got matched to a pattern about centralized, deployed platforms purely on theme. --------- Co-authored-by: Claude Sonnet 5 <noreply@anthropic.com> Co-authored-by: Sebastian Spier <github@spier.hu>
Summary
From Raimund Hook's InnerSource Commons talk "Break the contribution wall" (April 2026). GitLab's DevRel Engineering team (formerly Contributor Success) runs a contributor-growth program reaching "hundreds of users a week."
meta/contributor-handbook.md.Test plan
🤖 Generated with Claude Code