Digital_Definitions :: Engineering_AB_Tests :: Engineering Marketo :: Foundations_Agenda :: How_to_Write_Templates :: Image_Guidelines :: Marketo_Page_Template :: Slippers_Design_System :: Video_Bands :: Website :: Figma Process
Why we exist
To guide the intention of GitLab’s initial impact. Our goal is to continually shift perception by delivering positive experiences at velocity.
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
Create tools and processes that unlock GitLab team members and users to deliver results.
Contribute and execute on the strategy for the marketing site.
View long-term goals here: /handbook/marketing/inbound-marketing/digital-experience/foundations-agenda/
|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
|Tyler Williams||Fullstack Engineer||- Email: email@example.com
- GitLab: @tywilliams
- Slack: @Tyler Williams
- ReadMe: tyler-williams
|Laura Duggan||Frontend Engineer||- Email: firstname.lastname@example.org
- GitLab: @lduggan
- Slack: @Laura Duggan
- ReadMe: laura-duggan
|Stephen McGuinness||Design System Lead (Contract)||- GitLab: @smcguinness1
- Slack: @Stephen McGuinness
|Jessica Halloran||UX Designer (Contract)||- GitLab: @jhalloran
- Slack: @jhalloran
|Tina Lise Ng||UX Designer (Contract)||- GitLab: @Tinaliseng
- Slack: @Tina Lise Ng
|Javier Garcia||Frontend Engineer (Contract)||- GitLab: @jgarc
- Slack: @Javi
|Nathan Dubord||Frontend Engineer||- Email: email@example.com
- GitLab: @ndubord
- Slack: @Nathan Dubord
- ReadMe: nathan-dubord
Specific targets can be found here
Metric: Inbound marketing qualified leads.
There are many other digital marketing metrics we track for the website. 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.
See Where should content go? to learn which web property is the most appropriate place to put different types of content. To learn what section of the website different content belongs see definitions.
The website does not include - The Docs:
docs.gitlab.com - The GitLab.com product:
gitlab.com - The Handbook:
about.gitlab.com/handbook - The blog:
We collaboratively define OKRs as a team with cross functional partners in advance of each quarter. Once OKR candidates are complete the Growth Marketing Leads review and submit for ratification.
Key Result: During Q3 FY21, we made the decision to move forward with a 3rd party CMS (content management system) for the GitLab marketing website. A vendor selection process was completed, and the decision is to implement NetlifyCMS.
Key Result: During Q3 FY21, we will invest in planning, designing, and building a design system for our Marketing site. The Marketing Design System will increase our efficiency and make it easier for everyone to contribute.
Our goal is to deliver a release every 2 weeks. Our release day is always a Wednesday. We can push MRs at any time but for collaborative work initiatives, we plan a package for delivery to ensure we're improving our customer's experience rapidly.
For FY22 Q1 we have one two-week sprint cycle.
|Sprint Release Async||Sprint Ends|
Every sprint cycle, Digital Experience is open to requests initiated outside of the Inbound Marketing team. Our capacity for agency-related tasks during a sprint is 10% or one day. These issues should be labeled with the
IM-WEBAGENCY label and will be taken on based on priority/due date.
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:
www-gitlab-comrepository by the end of repository health day.
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.
These issue boards were created by the Digital Experience team to track our own workloads for a given release cycle.
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.
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 the Inbound Marketing Sprint Planning document for our planning meetings.
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.
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 the 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
@digital-experience use this handle in any channel to mention every member of our team.
The Digital Experience team who work on the marketing website are primarily responsible for facilitating content, not creating it. Please prepare a content plan:
Requests should be made with sufficient lead time to process the request, allocate resources, iterate, and produce related items.
The time needed for your webpage request will vary on a number of factors, including, but not limited to:
If your request requires changes to the
www-gitlab-com repository's dependencies, pipeline, or other critical infrastructure, and it coincides with a release post, the Digital Experience team may choose to wait for deployment, to avoid disrupting the monthly release post process.
Please fill out one of these Issue Templates to request support. Please note that if these are not filled out then we won't have the information needed to support your request.
In the spirit of Everyone Can Contribute, we're excited to collaborate with other teams! We request that if you make code changes or design changes, to please do the following:
We are also implementing a 2-week code freeze on recently updated pages. Since we may be doing research and analysis on page performance, we ask that you check with our team before making changes that could impact our results. A good place to do this is in the #digital-experience-team slack channel.
It should be noted that for small typo fixes and copy edits, these steps aren't necessary (as per the cleanup over sign-off sub-value).
Unfortunately we get multiple of these requests every day. When we do unplanned work, then we cannot deliver all of the work we planned. That said, it doesn't hurt to ask. We might have availability.
If we don't have availability, then we respectfully ask for your patience while waiting for the next available agency day. This is time we set aside for this kind of work.
Your request might only take a few minutes to implement, but there is additional overhead in context switching, creating issues + merge requests + branches, testing procedures, reviewing, and verifying releases.
If you have an emergency then please do let us know. Be aware that whenever new work is brought into a sprint, other work is negatively impacted. Your request might be important, but we still need to weigh the importance against other projects.
This is a specific type of blocked issue. An issue is not actionable if the Digital Experience team is missing what we need to work on it. We might have unanswered questions or the project might be missing a content plan.