Comment nous utilisons GitLab pour développer les communautés open source

L'équipe Contributor Success de GitLab faisait face au défi suivant : alors que nos contributeurs open source récurrents fusionnaient davantage de modifications de code et collaboraient sur des fonctionnalités avancées, les contributeurs novices, quant à eux, avaient du mal à se lancer. Nous étions conscients que beaucoup de nouveaux contributeurs open source finissaient par abandonner sans même demander de l'aide. Attachés à la mission de GitLab où chacun peut contribuer, nous aspirions à inverser cette tendance.

Nous avons commencé à effectuer des recherches sur les contributeurs open source de GitLab. Puis nous avons amélioré les obstacles majeurs. En janvier, nous avons atteint un record de 184 contributeurs communautaires uniques à GitLab en un seul mois, dépassant pour la première fois notre objectif de 170 fixé par l'équipe.

Trois mois plus tard, nous l'avons de nouveau battu avec 192 contributeurs.

Voici comment nous avons utilisé les propres outils de GitLab pour résoudre le dilemme des nouveaux contributeurs et développer notre communauté open source.

Ce que nous avons appris sur les nouveaux contributeurs

En 2023, nous avons mené la toute première étude sur les contributeurs open source de GitLab. Nous avons observé six participants qui n'avaient jamais contribué à GitLab.

Voici ce qu’ils nous ont dit :

• La documentation destinée aux contributeurs était confuse

• La prise en main était difficile

• Trouver de l’aide n'était pas clair

Seul un participant sur six a réussi à fusionner une contribution de code dans GitLab au cours de l'étude.

Il est devenu évident que nous devions nous concentrer sur l'expérience d'intégration si nous voulions que les nouveaux contributeurs réussissent à faire leurs premiers pas sur GitLab. Nous avons donc itéré !

Notre équipe a passé l'année suivante à résoudre leurs défis. Nous avons utilisé les outils de GitLab, tels que les templates de tickets, les pipelines programmés, les webhooks et le GitLab Query Language (GLQL), pour construire une solution d'intégration innovante et semi-automatisée.

En 2025, nous avons effectué une étude de suivi des utilisateurs avec de nouveaux participants qui n'avaient jamais contribué à GitLab. Les 10 participants ont tous créé et fusionné avec succès des contributions dans GitLab, avec un taux de réussite de 100 %. Les retours ont montré une grande appréciation pour le nouveau processus d'intégration, la rapidité avec laquelle les chargés de maintenance vérifiaient le travail des contributeurs, et la reconnaissance que nous offrions aux contributeurs.

Création d’une intégration personnalisée

Notre solution a commencé par l'engagement. Pour aider les nouveaux contributeurs à se lancer, nous avons mis en place un processus d'intégration personnalisé connectant chaque contributeur avec un chargé de maintenance communautaire.

Nous avons créé un template de ticket avec une liste claire de tâches.

Le ticket d'intégration gère également l'approbation d'accès aux forks de la communauté de GitLab, une collection de projets partagés qui facilitent le push de modifications, la collaboration entre contributeurs, et l'accès aux fonctionnalités GitLab Ultimate et GitLab Duo.

En utilisant des labels à portée limitée, nous indiquons le statut de la demande d'accès pour faciliter le suivi par les chargés de maintenance.

Nous avons commencé avec un script Ruby exécuté via un pipeline programmé, vérifiant les nouvelles demandes d'accès et utilisant le template de ticket pour créer des tickets d'intégration personnalisés.

À partir de là, nos chargés de maintenance collaborent avec les nouveaux contributeurs pour vérifier l'accès, répondre aux questions et trouver des tickets.

Standardisation des réponses avec des templates de commentaires

Avec plusieurs chargés de maintenance dans la communauté de GitLab, nous voulions assurer une communication cohérente et claire.

Nous avons créé des templates de commentaires, que nous synchronisons avec le dépôt en utilisant l'API GraphQL et un script Ruby.

Le script est déclenché dans le fichier .gitlab-ci.yml lorsque des modifications de templates de commentaires sont apportées avec un push vers la branche par défaut (un test est déclenché dans les merge requests).

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

Suppression du temps d'attente de 5 minutes

Notre première itération était un peu lente. Après avoir commencé le processus d'intégration, les contributeurs se demandaient ce qu’il fallait faire ensuite, tandis que le pipeline programmé prenait jusqu'à 5 minutes pour créer leur ticket d'intégration.

Niklas, un membre de notre équipe Core, a trouvé une solution. Il a ajouté des événements webhook pour les demandes d'accès et des templates de charge utile personnalisés pour les webhooks.

Ces fonctionnalités combinées nous ont permis de déclencher un pipeline immédiatement. Cela réduit le temps à environ 40 secondes (le temps qu'il faut au pipeline CI pour s'exécuter) et génère le ticket d'intégration immédiatement. Cette action économise également des milliers de pipelines et de minutes de calcul lorsqu’aucune demande d'accès n’a besoin d'être traitée.

Nous avons configuré un token de déclenchement de pipeline et l'avons utilisé comme cible pour le webhook, en passant les variables d'environnement souhaitées :

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

Automatisation des suivis

Avec un volume croissant de clients et de contributeurs à la communauté GitLab, les chargés de maintenance avaient du mal à suivre les tickets qui nécessitaient une attention particulière et certaines questions de suivi se perdaient.

Nous avons mis en œuvre une automatisation utilisant les webhooks et Ruby pour labeliser les tickets mis à jour par les membres de la communauté. Cela crée un signal clair du statut du ticket pour les chargés de maintenance.

GitLab Triage relance automatiquement les tickets d'intégration inactifs afin de maintenir cette dynamique.

Organisation du suivi des tickets avec GLQL

Nous avons construit une vue GitLab Query Language (GLQL) pour garder une trace de l'ensemble des tickets. Ce tableau GLQL recense les tickets d'intégration qui nécessitent une attention particulière, permettant aux chargés de maintenance de les examiner et de les suivre avec les membres de la communauté.

Ces vues GLQL ont amélioré notre efficacité globale de classement. Le succès a été tel que nous avons fini par utiliser cette stratégie dans les programmes GitLab pour l’open source et GitLab pour l'éducation. Avec les tableaux GLQL pour les tickets d’assistance, ces programmes communautaires ont réduit leurs temps de réponse de 75 %.

Meilleure accessibilité du README

Le groupe @gitlab-community est l’espace dédié aux contributeurs sur Gitlab.com. Nous avions déjà un fichier README.md expliquant les forks de la communauté et le processus d'intégration, mais ce fichier vivait dans un projet meta. Avec notre étude de suivi des utilisateurs, nous avons découvert que cette séparation désorientait les nouveaux contributeurs quand leurs tickets d'intégration se trouvaient dans un projet différent.

Nous avons alors utilisé la mise en miroir de projet de GitLab pour résoudre cela et mis en miroir le projet meta vers gitlab-profile. Cela a fait remonter le fichier README existant au niveau du groupe, le rendant plus facile d'accès.

Les résultats parlent d'eux-mêmes

En utilisant GitLab nous-mêmes, nous avons amélioré les points de friction identifiés dans nos études et transformé le parcours des contributeurs de GitLab. Nous avons augmenté le nombre de clients et de membres de la communauté contribuant à GitLab, ajoutant des fonctionnalités au produit, résolvant des bogues, et enrichissant notre catalogue CI/CD.

Notre processus d'intégration a augmenté le taux d'adhésion des nouveaux contributeurs au sein de notre communauté, et le nombre total de contributeurs sur les forks de la communauté a doublé au cours des 9 derniers mois.

Nous avons réduit le temps nécessaire aux nouveaux contributeurs pour apporter leur première contribution en les connectant plus rapidement avec les chargés de maintenance et en les aidant à démarrer.

Nous utilisons l’analyse de la chaîne de valeur de GitLab pour suivre nos taux de réponse.

• Le délai avant première réponse des chargés de maintenance de la communauté est descendu à 46 minutes au cours des 3 derniers mois

• Le temps d'approbation moyen pour l'accès aux forks de la communauté est descendu à 1 heure au cours des 3 derniers mois

Le taux de réussite de 100 % de notre étude de suivi des utilisateurs de 2025 a confirmé ces améliorations pour nos contributeurs novices.

Meilleure reconnaissance des contributeurs

Corriger les défis rencontrés par nos nouveaux contributeurs nous a permis de nous concentrer sur une meilleure reconnaissance de notre communauté, incitant les novices à revenir. Le résultat : contributors.gitlab.com. Nous avons construit un hub central pour nos contributeurs qui comprend des tableaux de classement, des réalisations et des récompenses. Les contributeurs peuvent voir leur impact, suivre leurs progrès et grandir au sein de la communauté.

Partager ce que nous avons appris

Ces améliorations fonctionnent et sont reproductibles pour d'autres projets open source. Nous partageons notre approche pour que d'autres projets puissent envisager d'utiliser ces outils pour se développer.

Au fur et à mesure que les organisations prennent connaissance des obstacles à la participation, il est possible de créer un environnement open source plus convivial. Avec les outils de GitLab, nous pouvons offrir une expérience plus fluide aux contributeurs et aux chargés de maintenance.

Contactez-nous

Vous voulez en savoir plus sur le développement de votre communauté de contributeurs ? Envoyez un e-mail à [email protected] ou créez un ticket pour démarrer une discussion. Nous sommes là pour aider à construire des communautés.