As a company we have to be great at providing multiple journeys. The contributor, user, and buyer journey involve different people going through them, different metrics, different hand-offs, and different teams providing them. Most companies never master a journey, a few companies master one: Ubuntu mastered the contributor journey, Atlassian the user journey, and Oracle the buyer journey. Our ambition is to master all three.
The hard thing is that during a journey you have multiple hand-offs between departments and teams. These hand-off points need to be well defined and work for both teams. It is essential to measure all steps of the journey to see where an improvement would have the greatest effect.
A contributor is someone who contributed to GitLab with code, documentation, a blog article, a tweet, a talk, a meetup, and/or helping on the issue tracker/forum/irc.
Find GitLab (technical blog post)
Reach out to GitLab on social media (social media response)
Find information about contributing (contributor landing pages)
Start installation of GDK (multiple good options to run)
Finish installation of GDK (error free, good troubleshooting)
Submit a merge request (good documentation)
Get acknowledged (find first contributor)
Finish merge request (acknowledge first contribution, merge request coach)
Help someone else (forum, issue tracker)
Get recognized for a large contribution (named swag)
Get recognized as an core contributor (core contributor program, we need to know their location, maybe do this as part our forum)
Get invited to an event (match contributors with incoming requests for speakers, meetup organization, speaker content)
Write a blog post (help with editing)
Get activated after being inactive for a while (reactivation program)
People might skip parts of this journey, for example by never contributing code. That is perfectly fine.