Why we exist
We help guide and educate Buyers on how GitLab’s DevOps Platform can solve their problems.
Where we’re going
A future where everyone can contribute, consumers become contributors and we greatly increase the rate of human progress.
What we do
We drive continual improvement to GitLab’s user journeys and conversion funnel.
|Team Member||Role||Contact Info|
|Michael Preuss||Senior Manager, Digital Experience||- Email: email@example.com
- GitLab: @mpreuss22
- Slack: @mpreuss22
- ReadMe: michael-preuss
|Lauren Barker||Senior Fullstack Engineer||- Email: firstname.lastname@example.org
- GitLab: @laurenbarker
- Slack: @lbarker
- ReadMe: lauren-barker
|Nathan Dubord||Senior Frontend Engineer||- Email: email@example.com
- GitLab: @ndubord
- Slack: @Nathan Dubord
- ReadMe: nathan-dubord
|Jessica Halloran||Senior Product Designer (UX)||- GitLab: @jhalloran
- Slack: @jhalloran
|Tyler Williams||Senior Fullstack Engineer||- Email: firstname.lastname@example.org
- GitLab: @tywilliams
- Slack: @Tyler Williams
- ReadMe: tyler-williams
|Laura Duggan||Frontend Engineer||- Email: email@example.com
- GitLab: @lduggan
- Slack: @Laura Duggan
- ReadMe: laura-duggan
|Javier Garcia||Frontend Engineer||- Email: firstname.lastname@example.org
- GitLab: @jgarc
- Slack: @Javi
|Megan Filo||Frontend Engineer||- Email: email@example.com
- GitLab: @meganfilo
- Slack: @Megan Filo
- ReadMe: megan-filo
|Tina Lise Ng||Product Designer (UX) (Contract)||- GitLab: @Tinaliseng
- Slack: @Tina Lise Ng
|Mateo Penagos||Senior FullStack Engineer (Contract)||- GitLab: @mpenagos-ext
- Slack: @Mateo Penagos
|John Arias||Senior Fullstack Engineer (Contract)||- Email: firstname.lastname@example.org
- GitLab: @jariasc-ext
- Slack: @John Arias
|Miguel Duque||Frontend Engineer (Contract)||- Email: email@example.com
- GitLab: @mduque-ext
- Slack: @Miguel Duque
|Daniel Vilchis||Senior Frontend Engineer (Contract)||- Email: firstname.lastname@example.org
- GitLab: @dvilchis-ext
- Slack: @Daniel Vilchis
|Stephanie Garrido||Scrum Master (Contract)||- Email: email@example.com
- GitLab: @sgarrido-ext
- Slack: @Stephanie Garrido
Metric: Conversion (past the Pricing Page)
There are many other digital marketing metrics we track for the Marking Site. These include pageviews, unique visitors, time on site, and conversion metrics for key funnels. These detailed metrics are leading indicators for the health of our North Start metric, and are internal to GitLab.
GitLab's digital marketing platform, or simply the “Marketing Site" refers to
https://about.gitlab.com with the exception of the the handbook.
We collaboratively define OKRs as a team with cross functional partners in advance of each quarter. Once OKR candidates are complete we review, size/scope them and align on which best help achieve our business objectives.
FY22Q4 Digital Experience Quarterly Plan & OKRs
Objective: Improve Free Trial Experience
We release every 2 weeks, always on a Wednesday. We can push MRs at any time but for collaborative work initiatives, we plan a package for delivery to ensure we’re consistently improving our prospective customer’s experience.
|Sprint Release Async||Sprint Ends|
Before a sprint starts, our team aligns on what will be delivered during the sprint. We identify issues that need to be written, write them, then add them to our boards and weight them.
There is always a chance that a team member's sprint plan will change during the meeting.
We use issue weight to plan and manage our work. Team members are not held to weights, they’re simply a planning and learning tool. Digital Experience weights are based on the following point scale: 1pt = .5 day. In a full two-week sprint, we plan to deliver 20 points per team member.
We use our Sprint Planning document for our planning meetings.
Team members plan a majority of their sprint async before the sprint planning meeting. If you have an issue or project that needs to get done in the upcoming sprint, place it in the "Unassigned" section. Please add a link to the issue and when it needs to be delivered. It is recommended to add these items to the sprint planning doc by the Friday before Monday's sprint planning meeting. This will enable team members to work efficiently while planning their sprints Monday morning.
We use Geekbot to conduct asynchronous, weekly check-ins on iteration progress.
Each member of the Digital Experience team should be listed as a participant in the weekly check ins, and everyone should have permissions to manage the application for our team. The app can be configured through the Geekbot Dashboard, which you can visit directly, or find by clicking the Geekbot Slack conversation, navigating to the About tab, and clicking App Homepage.
Our team makes every attempt to complete code reviews on Merge Requests as timely as possible.
Team members who create a Merge Request should factor in a suitable amount of time for code and/or design review. If an issue has a due date, the MR creator should try have the work code-complete at least 24 hours prior to the intended release. This gives time for any major fixes that the reviewers may point out, and encourages quick iterations and Minimal Viable Change releases.
When a team member is requested for review, it is good practice for them to post a comment in the Merge Request with an estimated timeline by which they expect to complete the review. For example, it is understandable to take 3 days to do a review, as long as you’ve let the MR creator know it may take that long. This gives the MR creator an opportunity to request a review from another team member.
Digital Experience code request reviews should include the merge request checklist as referenced on the reviewing merge requests handbook page. Merge requests involving a URL redirect should also include the redirect checklist.
From time to time, our team has objectives that require us to collaborate on the GitLab product. Read more about the process for our engineers to onboard
On the second Wednesday of each sprint, we have a calendar reminder for: “Sprint Release Async”, which serves as a reminder for team members to add to our Sprint Release Video Document.
Special cases during release post schedule: we hold off on making changes to the
www-gitlab-com repository during release post days. The release post process is handled by a different team, and it can be disruptive to their work when we release changes to dependencies, CI/CD, or other major changes around their monthly release cadence.
Sprint Retros allow us to reflect on what went well and what we can to do continuously improve our process.
This is the agenda we use for Sprint Retros
We release videos for:
All videos are accessible in our Digital Experience playlist on GitLab Unfiltered.
At the end of every sprint cycle, Digital Experience will spend 10% or one day to work on issues related to improving the health of about.gitlab.com, the developer experience, tackle tech debt, or improve our documentation.
The structure of Repository Health Day is as follows: 1. Team members will choose what they wish to work on for this day. 1. Each team member will submit a single merge request to the
www-gitlab-com repository by the end of repository health day. 1. This merge request will be related to an issue from any partner or group within GitLab.
By allowing our team members to contribute to the health of our repository for a day, we can contribute low-effort, high-impact solutions that will drive results for our team, partners, and the entire marketing site. This will enable Digital Experience team members to use their strengths to efficiently drive results for the
www-gitlab-com repository. We’re all good at different things and come from different backgrounds. Let’s use that to our advantage to build a better repository that is inclusive of the team members that use it everyday.
Digital Experience will dedicate one week or 8.33% per quarter to work on projects that improve the health of the
www-gitlab-com repository, the developer experience, or tackle larger tech debt projects. These are projects that can not be completed in a single repository health day and require a higher degree of effort.
@digital-experience use this handle in any channel to mention every member of our team.
We do our best to assist team members but do not operate as an internal agency so all requests will be prioritized against commitments in our current quarterly plan.
We love collaborating on work that drives our North Star and supporting metrics. If you have an idea, a strategic initiative, or an OKR that we requires our support here's how you can kick off our collaboration: