Skip to content

Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern - #926

Draft
rrrutledge wants to merge 6 commits into
InnerSourceCommons:mainfrom
rrrutledge:add-gitlab-known-instance
Draft

Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern#926
rrrutledge wants to merge 6 commits into
InnerSourceCommons:mainfrom
rrrutledge:add-gitlab-known-instance

Conversation

@rrrutledge

@rrrutledge rrrutledge commented Aug 11, 2026

Copy link
Copy Markdown
Contributor

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."

  • Incentive Mechanisms for Voluntary Contributions — adds GitLab as a Known Instance: contributors.gitlab.com gamifies contribution across code, code review, documentation, and translations with points, levels, and leaderboards; points unlock exclusive contributor-only swag - replaces "TBD" Known Instances
  • Internal Developer Platform — adds GitLab as a Known Instance: GitLab containerized their GitLab Development Kit (GDK), cutting new-contributor environment setup from roughly two hours (frequently failing) to under five minutes
  • Paired Onboarding Sprint (new pattern, filed at maturity level 1/Initial) — 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; one known instance is exactly what Initial-level requires per meta/contributor-handbook.md.

Test plan

  • Verify all YouTube links resolve to the correct talk
  • Confirm the two Known Instance entries match the surrounding formatting style
  • Confirm Paired Onboarding Sprint follows the pattern template and reads clearly for a first-time reader

🤖 Generated with Claude Code

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>
@spier spier added 📖 Type - Content Work Working on contents is the main focus of this issue / PR 🐅 patterns-in-the-wild InnerSource patterns that were spotted in the wild. We can extract Known Instances and new patterns. 💻 AI-generated Experiments with generating drafts of patterns with the help of our robot friends :) labels Aug 11, 2026
## 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).

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll have to work on the Claude skill to make this better 🤔

@rrrutledge

Copy link
Copy Markdown
Contributor Author

The linkChecker failure above is a known false positive, not related to this PR's changes — see #927 for the root cause (lychee can't resolve a pre-existing root-relative image link without --root-dir) and the fix. No required status checks block merging this PR in the meantime.

spier pushed a commit that referenced this pull request Aug 12, 2026
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.
@rrrutledge
rrrutledge marked this pull request as ready for review August 12, 2026 13:09
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>
@rrrutledge rrrutledge changed the title Add GitLab as Known Instance across two patterns Add GitLab as Known Instance and draft Paired Onboarding Sprint pattern Aug 12, 2026
rrrutledge added a commit to rrrutledge/InnerSourcePatterns that referenced this pull request Aug 12, 2026
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>
@rrrutledge
rrrutledge marked this pull request as draft August 12, 2026 14:29
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.
rrrutledge added a commit to rrrutledge/InnerSourcePatterns that referenced this pull request Aug 12, 2026
…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.
rrrutledge and others added 2 commits August 12, 2026 14:29
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.
@rrrutledge
rrrutledge force-pushed the add-gitlab-known-instance branch from 443b9d3 to a616aba Compare August 15, 2026 13:04
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
@rrrutledge
rrrutledge force-pushed the add-gitlab-known-instance branch from a616aba to 63316d6 Compare August 15, 2026 13:12
spier added a commit that referenced this pull request Aug 18, 2026
* 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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

📖 Type - Content Work Working on contents is the main focus of this issue / PR 💻 AI-generated Experiments with generating drafts of patterns with the help of our robot friends :) 🐅 patterns-in-the-wild InnerSource patterns that were spotted in the wild. We can extract Known Instances and new patterns.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants