graph TD
LA[Marketing]
LB[Handbook / Docs]
LC[GitLab]
LD[Repository Issues]
classDef yellow fill:#ff0,stroke:#333,stroke-width:4px;
classDef green fill:#0f0,stroke:#333,stroke-width:4px;
classDef orange fill:#fa0,stroke:#333,stroke-width:4px;
classDef red fill:#f00,stroke:#333,stroke-width:4px;
class LA yellow;
class LB green;
class LC orange;
class LD red;
Current
%%{init: {"flowchart": { "useMaxWidth": false } }}%%
graph TD
subgraph Discovery
AA[Contributing page]
AB[Hackathon page]
AC[Google]
end
subgraph Engagement
BA[Contributing to Development guide]
BB[Creating a fork]
BC[Code Contributor program]
BD[Update the documentation]
BE[How to open a MR]
BF[Add Tests if needed]
BG[Merge Request Coaches]
BH[Developer documentation]
BI[Accepting MR Issues]
BJ[Project specific contribution guide]
BK[Project specific issues]
BL[Project repo]
end
subgraph Onboarding
CA[GitLab development environment guide]
CB[GitLab README]
CC[Project specific setup]
CD[Picking out an issue]
end
subgraph Contribution
DA[Open MR]
DB[Iterate]
end
AA --> BA
AB --> BA
AB --> BI
AC --> AA
AC --> BI
AC --> BJ
AC --> BL
BA --> BB
BA --> BC
BA --> BD
BA --> BE
BA --> BF
BA --> BG
BA --> BI
BH --> BI
BI --> BL
BI --> CB
BI --> DA
BJ --> BK
BJ --> CC
BK --> CB
BK --> CD
BL --> CB
BL --> CC
CB --> CA
CB --> BI
CB --> BA
CB -.-> CC
CC --> CD
CD --> DA
DA --> DB
DB --> DA
classDef yellow fill:#ff0,stroke:#333,stroke-width:4px;
classDef green fill:#0f0,stroke:#333,stroke-width:4px;
classDef orange fill:#fa0,stroke:#333,stroke-width:4px;
classDef red fill:#f00,stroke:#333,stroke-width:4px;
class AA,AB,AC yellow;
class BA,BB,BC,BD,BE,BF,BG,BH,BJ,CC green;
class BL,CB,CA,DA,DB orange;
class BI,BK,CD red;
Goal
graph TD
subgraph Discovery
AA[Contributing page]
AB[Hackathon page]
AC[Google]
end
subgraph Engagement
BA[Contributing to Development Guide]
BB[GitLab development environment guide]
BC[List of projects to contribute to]
end
subgraph Onboarding
CA[Project specific setup]
CB[Picking out an issue]
end
subgraph Contribution
DA[Open MR]
DB[Iterate]
end
AA --> BA
AB --> BA
AC --> BA
BA --> BB
BB --> BC
BA --> BC
BA --> CA
BB --> CA
BC --> CA
CA --> CB
CB --> DA
DA --> DB
DB --> DA
classDef yellow fill:#ff0,stroke:#333,stroke-width:4px;
classDef green fill:#0f0,stroke:#333,stroke-width:4px;
classDef orange fill:#fa0,stroke:#333,stroke-width:4px;
classDef red fill:#f00,stroke:#333,stroke-width:4px;
class AA,AB,AC yellow;
class BA,BC,CA green;
class BB,DA,DB orange;
class CB red;
Top Findings
The Contribution guide is overwhelming.
Triaging MRs is one of the major pain points. This leads to long review times and frustration.
Not all groups/products are properly labeling issues for new contributors.
Just a few groups/products are actively engaging contributors throughout their product development process.
The majority of 1st-time contributors for the past year never come back for a second one.
We don’t attract new long-term/core contributors.
Detailed Findings
Discovery
The Contributor guide is the main entry point for contributors.
There might be some misunderstanding between Contributing to GitLab and GitLab
Contribute (the annual conference).
Engagement / Identification
The contributor guide is designed to help contribute to GitLab overall, without having in mind different groups/products and their development environment (e.g. GitLab Runner)
It’s overwhelming
There is a lot of information which is not relevant or digestible for contributors.
It has a lot of text.
It is driving contributors to a list of easy issues, to begin with, without additional information about the different projects/groups.
The user flow has a lot of exit/drop points.
There is an infinite loop between the contributor guide and the GitLab README file (that has the instructions for setting up the GitLab dev environment).
Onboarding/Dev Environment
Users can't easily understand that there is more than one product at GitLab.
Different products are written in different programming languages; this means they have different development environments.
Products milestones are rarely published, so contributors aren't aware of priorities.
The product teams are not properly labeling issues or catering to them for community contributions.
There is no consistency across projects' documentation.
Contribution
Long times triaging issues (applying the proper labels).
Not clear to who to assign the MRs for review.
Getting help is currently working just fine.
We have a stable average number of 11 days before a community MR is merged. It's not optimal, but it's acceptable and similar to the community's expectation (1 week).
Retention
We attract a stable number of new contributors per milestone (~50), but our overall contributions are not increased accordingly.
According to sample research, for the past year, the majority of 1st time contributors drop off after their MR is merged.
