Developer Relations Workflows: Content Review

The Developer Relations team provides ongoing support to a number of stakeholders who create content including Product Marketing, Brand, and numerous Sales teams. In order to ensure the technical accuracy of content being created across GitLab, we conduct regular reviews of top-performing content across GitLab’s main public facing content channels, notably about.gitlab.com and Highspot.

Fix Fridays

Our primary mechanism for conducting content reviews is Fix Fridays. These are once-monthly days set aside for content review. Team members should plan their calendar with a defined review time, for example, the last Friday of each month. If Friday is not possible, another day and time can be considered to complete the assigned tasks by the end of the month.

The checklist for Fix Fridays is as follows:

1. Prior to the review, a Fix Friday issue will be created documenting GitLab’s top performing content over the past 30 days. The focus is webpages or Highspot content ranking among the top 20 pages on either channel. The docs site is excluded from these regular reviews.
2. Once the issue has been created, items will be assigned by a DRI (typically Director, Developer Relations) for review based on team member’s areas of expertise, familiarity, recent reviews, and other considerations.
3. After you are assigned an item, each team member will be responsible for reviewing their items. These Fix Fridays, however, are intentionally designed to be collaborative so feel free to consult with other team members from across GitLab, as needed. This is a chance to surface issues to our stakeholders, gain a better understanding of our marketing messaging, and deepen our knowledge of GitLab and our customers.
4. Address feedback following the steps for providing feedback outlined below.
5. Once you have completed review of your items, please ensure that the tasks created during your review are assigned to the appropriate DRIs to be resolved.
6. After the review is complete and tasks are assigned, check the corresponding box in the FixFriday issue to show that the review for each item has been completed.

Providing feedback

How to make changes to the content you review:

Website

1. During the review process, small changes may be able to be fixed with an MR assigned for the page.
   • When authoring an MR, assign a Developer Relations team member for review first, and then ask the page CODEOWNER or DRI for the final review and merge.
   • If there is no CODEOWNER or DRI, use the Suggested Reviewer feature to help identify a reviewer.
   • For the about.gitlab.com Homepage, Pricing Page, Why GitLab, Why Enterprise, Why Premium, or Platform assign to Michael Preuss. For any other Buyer Experience Marketing page assign to Justin Vetter.
2. If feedback cannot be addressed during the review using MR may require creation of a separate issue.

Highspot

1. In a comment on the Fix Friday issue, tag the author or feedback owner for any Highspot page, play or content that needs to be updated in an issue comment which details the proposed change. This will create a TODO for the DRI for that content item.
   • If the author or feedback owner does not exist on a smartpage or play, tag the person/people in the “Ask for Help” section (located at the bottom of the page).
   • Alternatively, for a piece of content on Highspot, you can tag the owner or the person who uploaded the file/last updated the file. If that person is not the right DRI to update, they can tag the correct person.