Von 17 % auf 100 %: Wie wir das Open-Source-Onboarding revolutionierten

GitLabs Contributor Success Team stand vor einer Herausforderung.

Während unsere wiederkehrenden Open-Source-Mitwirkenden mehr Code-Änderungen mergten und an tiefgreifenden Funktionen zusammenarbeiteten, hatten Erstmitwirkende Schwierigkeiten, den Einstieg zu finden. Wir wussten, dass viele Neulinge in Open Source oft aufgaben oder nie um Hilfe baten. Aber als Verfechter von GitLabs Mission,

allen das Mitwirken zu ermöglichen, wollten wir es besser machen.

Wir begannen Forschungsstudien über Open-Source-Mitwirkende bei GitLab durchzuführen. Dann verbesserten wir die Stolpersteine. Im Januar erreichten wir einen Rekord von 184 einzigartigen Community-Mitwirkenden bei GitLab in einem einzigen Monat

und übertrafen damit erstmals unser Teamziel von 170.

Drei Monate später brachen wir den Rekord erneut mit 192.

So haben wir GitLabs eigene Tools genutzt, um das Neueinsteiger-Dilemma zu lösen und unsere Open-Source-Community wachsen zu lassen.

Was wir aus der Untersuchung von Erstmitwirkenden gelernt haben

2023 führten wir die erste Nutzerstudie über GitLab Open-Source-Mitwirkende durch.

Wir beobachteten sechs Teilnehmende, die noch nie bei GitLab mitgewirkt hatten, bei ihrem ersten Versuch. Sie führten Tagebuchstudien durch und nahmen an Zoom-Interviews teil, in denen sie ihre Erfahrungen detailliert schilderten.

Die Teilnehmenden sagten uns:

• Die Mitwirkenden-Dokumentation war verwirrend

• Der Einstieg fühlte sich überwältigend an

• Es war nicht klar, wie oder wo man Hilfe finden konnte

Nur eine(r) der sechs Teilnehmenden schaffte es während der Studie erfolgreich, einen Code-Beitrag zu GitLab zu mergen.

Es wurde klar, dass wir uns auf die Onboarding-Erfahrung konzentrieren mussten, wenn wir wollten, dass neue Mitwirkende Erfolg haben.

Also haben wir iteriert!

Unser Team verbrachte das nächste Jahr damit, ihre Herausforderungen anzugehen. Wir nutzten GitLab-Tools

wie Issue-Templates, geplante Pipelines, Webhooks und die GitLab Query Language (GLQL), um eine innovative halbautomatisierte Onboarding-Lösung zu entwickeln.

2025 führten wir eine Folgestudie mit neuen Teilnehmenden durch, die noch nie einen Beitrag zu GitLab geleistet hatten. Alle 10 Teilnehmenden erstellten und mergten erfolgreich Beiträge zu GitLab – eine Erfolgsquote von 100 %. Das Feedback zeigte große Wertschätzung für den neuen Onboarding-Prozess, die Geschwindigkeit, mit der

Maintainer bei Mitwirkenden nachfragten, und die Anerkennung, die wir Mitwirkenden anboten.

Noch besser: Die Teilnehmenden teilten mit, wie viel Spaß sie beim Mitwirken hatten:

„Ich fühlte einen kleinen Adrenalinstoß bei dem Gedanken, sagen zu können: ‚Ich habe beim Aufbau von GitLab geholfen.'"

Wir haben persönliches Onboarding mit GitLab aufgebaut

Unsere Lösung begann mit Engagement.

Um Neulingen beim Einstieg zu helfen, führten wir einen persönlichen Onboarding-Prozess ein, der jeden

Mitwirkenden mit einem Community-Maintainer verbindet.

Wir erstellten ein Issue-Template mit einer klaren Checkliste von Aufgaben.

Das Onboarding-Issue behandelt auch die Zugangsgenehmigung für die

GitLab Community Forks,

eine Sammlung gemeinsamer Projekte, die es einfacher machen, Änderungen zu pushen, mit anderen zusammenzuarbeiten

und auf GitLab Ultimate- und Duo-Funktionen zuzugreifen.

Mit Scoped Labels zeigen wir den Status der Zugangsanfrage für einfache Maintainer-Nachverfolgungen an.

Wir begannen mit einem Ruby-Skript, das über eine geplante Pipeline ausgeführt wurde,

nach neuen Zugangsanfragen suchte und das Issue-Template nutzte, um personalisierte Onboarding-Issues zu erstellen.

Von hier aus engagieren sich unsere Maintainer mit neuen Mitwirkenden, um den Zugang zu verifizieren, Fragen zu beantworten und Issues zu finden.

Wir standardisierten Antworten mit Kommentar-Templates

Mit mehreren Maintainern in der GitLab-Community wollten wir konsistente und klare Kommunikation sicherstellen.

Wir erstellten Kommentar-Templates,

die wir mit dem Repository über die GraphQL-API und ein

Ruby-Skript synchronisieren.

Das Skript wird in .gitlab-ci.yml ausgelöst, wenn Änderungen an Kommentar-Templates

zum Standard-Branch gepusht werden (ein Trockenlauf wird in Merge Requests ausgelöst).

execute:sync-comment-templates:
  stage: execute
  extends: .ruby
  script:
    - bundle exec bin/sync_comment_templates.rb
  variables:
    SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_ONLY
  rules:
    - if: $CI_PIPELINE_SOURCE == 'schedule' || $CI_PIPELINE_SOURCE == "trigger"
      when: never
    - if: $EXECUTE_SYNC_COMMENT_TEMPLATES == '1'
    - if: $CI_MERGE_REQUEST_IID
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        REPORT_ONLY: 1
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      changes:
        - .gitlab/comment_templates/**/*
      variables:
        FORCE_SYNC: 1
        DRY_RUN: 0
        SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN: $SYNC_COMMENT_TEMPLATES_GITLAB_API_TOKEN_READ_WRITE

Wir eliminierten die 5-Minuten-Wartezeit

Unsere erste Iteration war etwas langsam.

Nach dem Start des Onboarding-Prozesses fragten sich Mitwirkende, was als Nächstes zu tun ist, während die geplante Pipeline bis zu 5 Minuten brauchte, um ihr Onboarding-Issue zu erstellen.

Fünf Minuten fühlen sich wie eine Ewigkeit an, wenn du den Schwung hast, einzutauchen.

Niklas, ein Mitglied unseres Core Teams, entwickelte eine Lösung. Er fügte Webhook-Events für Zugangsanfragen und benutzerdefinierte Payload-Templates für Webhooks hinzu.

Diese Funktionen ermöglichten es uns gemeinsam, eine Pipeline sofort auszulösen, anstatt auf den Zeitplan zu warten. Das reduziert die Zeit auf etwa 40 Sekunden (die Zeit, die die CI-Pipeline zum Ausführen benötigt) und generiert das Onboarding-Issue sofort. Es spart auch Tausende verschwendeter Pipelines und Compute-Minuten, wenn tatsächlich keine Zugangsanfragen verarbeitet werden müssen.

Wir richteten ein Pipeline-Trigger-Token ein und nutzten dies als Ziel für den Webhook, wobei wir die gewünschten Umgebungsvariablen übergaben:

{
  "ref": "main",
  "variables": {
    "EXECUTE_ACCESS_REQUESTS": "1",
    "DRY_RUN": "0",
    "PIPELINE_NAME": "Create onboarding issues",
    "GROUP_ID": "{{group_id}}",
    "EVENT_NAME": "{{event_name}}"
  }
}

Wir automatisierten Nachfassaktionen

Mit einem steigenden Volumen von Kunden und Community-Mitwirkenden, die in die GitLab-Community einsteigen,

hatten Maintainer Schwierigkeiten nachzuvollziehen, welche Issues Aufmerksamkeit benötigten, und einige Nachfragen gingen verloren.

Wir bauten eine Automatisierung auf, die Webhooks und Ruby nutzt, um Issues zu kennzeichnen, die von Community-Mitgliedern aktualisiert wurden.

Dies schafft ein klares Signal des Issue-Status für Maintainer.

GitLab Triage

stupst automatisch inaktive Onboarding-Issues an, um sicherzustellen, dass wir die Dynamik der Mitwirkenden aufrechterhalten.

Wir organisierten die Issue-Verfolgung mit GLQL

Wir bauten eine GLQL-Ansicht, um Issues im Blick zu behalten.

Diese GLQL-Tabelle fasst Onboarding-Issues zusammen, die Aufmerksamkeit benötigen,

damit Maintainer sie überprüfen und mit Community-Mitgliedern nachfassen können.

Diese GLQL-Ansichten verbesserten unsere gesamte Triage-Effizienz.

Es war so erfolgreich, dass wir diese Strategie auch bei den Programmen GitLab for Open Source

und GitLab for Education anwendeten.

Mit GLQL-Tabellen für Support-Issues senkten diese Community-Programme ihre Antwortzeiten um 75%.

Wir machten die README auffindbar

Die @gitlab-community-Gruppe

ist das Zuhause für Mitwirkende auf GitLab.com.

Wir hatten bereits eine README.md-Datei, die die Community Forks und den Onboarding-Prozess erklärte, aber diese Datei

befand sich in unserem Meta-Projekt.

Mit unserer Folgestudie entdeckten wir, dass dies ein Verwirrungspunkt für Neulinge war, wenn ihre

Onboarding-Issues unter einem anderen Projekt waren.

Wir nutzten GitLabs Projekt-Spiegelung,

um dies zu lösen und spiegelten das Meta-Projekt zu gitlab-profile.

Dies machte die bestehende README-Datei auf Gruppenebene sichtbar und erleichterte die Entdeckung.

Die Ergebnisse sprechen für sich selbst

Durch das Dogfooding von GitLab verbesserten wir die in unseren Forschungsstudien gefundenen Stolpersteine

und transformierten die GitLab-Mitwirkenden-Journey.

Wir haben die Anzahl der Kunden und Community-Mitglieder erhöht, die zu GitLab beitragen,

Funktionen zum Produkt hinzufügen, Fehler beheben und zu unserem CI/CD-Katalog beitragen.

Unser Onboarding-Prozess hat die Rate erhöht, mit der Neulinge der Community beitreten, und unsere Gesamtzahl der

Mitwirkenden in den Community Forks hat sich in den letzten 9 Monaten verdoppelt.

Wir reduzierten die Zeit, die Neulinge für ihren ersten Beitrag benötigen, indem wir sie

schneller mit Maintainern verbinden und sie beim Einstieg unterstützen.

Wir nutzen GitLabs Value Stream Analytics,

um unsere Antwortzeiten zu verfolgen.

• Die erste Antwortzeit von Community-Maintainern liegt in den letzten 3 Monaten bei 46 Minuten

• Die durchschnittliche Genehmigungszeit für den Zugang zu Community Forks liegt in den letzten 3 Monaten bei 1 Stunde

Die 100%-ige Erfolgsquote unserer Nutzerstudie 2025 bestätigte diese Verbesserungen für unsere Erstmitwirkenden.

Wir investierten Zeiteinsparungen in die Anerkennung von Mitwirkenden

Die Behebung dieser Neueinsteiger-Herausforderungen ermöglichte uns mehr Kapazität, uns auf eine bessere Anerkennung von

Mitwirkenden zu konzentrieren und Erstmitwirkende zu motivieren, wiederzukommen.

Das Ergebnis ist contributors.gitlab.com.

Wir haben einen zentralen Hub für unsere Mitwirkenden aufgebaut, der gamifizierte Bestenlisten,

Erfolge und Belohnungen bietet.

Mitwirkende können ihre Wirkung sehen, Fortschritte verfolgen und in der Community wachsen.

Was wir gelernt haben teilen

Diese Verbesserungen funktionieren und sind für andere Open-Source-Projekte wiederholbar.

Wir teilen unseren Ansatz über Communities und Konferenzen hinweg, damit andere Projekte in Betracht ziehen können, diese Tools zum Wachstum zu nutzen.

Wenn mehr Organisationen die Teilnahmebarrieren kennenlernen, können wir eine einladendere Open-Source-Umgebung schaffen.

Mit diesen GitLab-Tools können wir sowohl Mitwirkenden als auch Maintainern eine reibungslosere Erfahrung bieten.

Wir sind entschlossen, diese Arbeit voranzutreiben und zusammenzuarbeiten, um Barrieren für Open-Source-Projekte überall zu beseitigen.

Das Gespräch beginnen

Möchtest du mehr darüber erfahren, wie du deine Mitwirkenden-Community wachsen lassen kannst?

Sende eine E-Mail an [email protected] oder öffne ein Issue,

um eine Diskussion zu beginnen.

Wir sind hier, um beim Aufbau von Communities zu helfen.