Blog（E4002）

Objectives

1. Build credibility and authority.
2. Increase awareness of GitLab the company, product, and community.
3. Increase organic search rankings and traffic.

4. Contribute to lead generation and revenue.

   Scope

   Mission statement: Create, curate, and elevate stories that increase awareness of the benefits of a single application for the entire DevOps lifecycle, as well as awareness of GitLab as a pioneer in all-remote work.
   Please see Attributes of a successful blog post below for examples of stories that perform well on our blog.
   The blog is not the permanent place for tutorials, which should live in the docs and should be linked to when relevant.

   Publishing process

   We follow the GitLab Workflow. At GitLab, everyone can contribute, and we encourage anyone to submit a blog post idea or write your own. Below are instructions on how to contribute to the GitLab blog.

   Time-sensitive posts: Official announcements, company updates, breaking changes, and news

   If you need to publish a time-sensitive post, it is critical that you give the content team advance notice. Please follow the process outlined below:

5. Start by opening an issue in the gitlab.com/gitlab-com/www-gitlab-com project, using the Blog post template and applying the priority label. Even if you do not have a draft or a confirmed publish date, it’s important to open the issue as far in advance as possible and ping @rebecca so she knows it is coming and can prioritize accordingly.

6. The issue title should reflect the date on which you expect to publish.
7. The issue due date should be two working days before the publish date.
8. If other due dates apply (for example, design assets are required) make sure the entire timeline and all the people responsible are captured in the issue description.
9. In most cases, we expect that you or one of your team will write the post and create the merge request for it, with all images and other formatting included. Feel free to start your draft using this blog post template which has all the relevant information already embedded. Then see the formatting guidelines for help with creating and formatting your blog post MR.
10. If you need assistance with drafting the post or creating the MR, please make this clear in your issue and we will confirm if this is possible within your timeframe.
11. Use the Blog post merge request template for your MR and ensure it is set to close the associated issue automatically.
12. Be sure to check the review app for your blog post or preview it locally to ensure images, headlines, etc. are formatted correctly before handing over.
13. When your MR is ready for review, please assign it and the corresponding issue to @rebecca (or @erica if Rebecca is OOO) a minimum of two working days ahead of when you expect to publish. Please submit your MR earlier if you can.
14. When you’ve assigned your MR and issue to a reviewer, please change the due date on the issue to reflect the publishing date.
15. Your reviewer may leave comments for you to address, in which case they will assign the MR back to you. When you have resolved all outstanding discussions, assign the MR back to the reviewer for final review and merging.

    Who to assign your MR to – urgent posts

    Please assign first to @rebecca. If she is OOO, assign to @erica. If both are unavailable and you cannot wait until either returns, please assign to a member of the Technical Writing team. Where possible, select the technical writer who is listed for the most relevant stage group. If you need immediate assistance/review, find a technical writer who is online on Slack to request this directly. Regardless, be sure to specify any time contraints around getting the content reviewed and posted.
    Continuous delivery mindset: With time-sensitive posts, don’t wait to publish a post if you have enough information to go live. It’s OK to publish a headline and paragraph to get the news out in a timely matter and add more details later (e.g. add more graphics, charts, etc.). We don’t want to miss out on a news cycle because we’re waiting for an image or supplementary information.

    Error budgets for time-sensitive posts

    Inspired by error budgets used by Engineering.
    Applied to the blog, error budgets incentivize forward planning and early communication of time-sensitive blog posts. This helps the Editorial team to minimize time spent on unplanned work, shuffling of the publishing schedule, or work that is subsequently wasted or does not serve our mission and vision, or the needs of our audience.
    Each functional group is responsible for not exceeding an allowed budget of 15 points per quarter. The number of points given will depend on the severity of the impact to the team’s workflow:

• S1: 15 points - Less than 2 working days’ notice for a time-sensitive post (except in cases of responding to an industry or company event/news for which there was no prior warning).
• S2: 10 points - Failure to submit complete, formatted MR a minimum of 2 working days ahead of publish date.
• S3: 5 points - MR submitted ahead of time, but without all required formatting, links, and images included (unless otherwise agreed).

Where error budget points are incurred, a member of the Editorial team will apply the relevant label to the issue or merge request in question. Points will be totaled at the end of the quarter and communicated to functional groups who exceed their budgets, so that we can work together on solutions to prevent this in the future.

How to avoid incurring error budget points

• Open an issue as soon as you know a blog post will be needed, using the blog post issue template, and give @rebecca a heads up that your post needs to go live on a specific day.
• Create the MR for your blog post, ensuring everything is formatted correctly, all relevant images added, and links included.
• Check the review app or preview locally to make sure everything looks as expected.
• Assign the MR to @rebecca well ahead of time (a minimum of two working days before you expect to publish).

  Any other blog post ideas

  You do not need approval to write for the GitLab blog, however if your proposed post does not align with the blog objectives and scope, the Editorial team may suggest that you submit your post to the GitLab Unfiltered blog instead. If you would like to write a post for the main blog, please follow the process outlined below.
  Note: If you’re planning to write a tutorial post describing how to do something with GitLab, please ensure that the relevant documentation exists first before you write a blog post about it. A blog post should not replace documentation, but should add more information, context, and color around a technical subject, linking back to the documentation for full instructions.

1. Open an issue in the gitlab.com/gitlab-com/www-gitlab-com project, using the Blog posttemplate.
2. Feel free to start your draft using this blog post template which has all the relevant information already embedded. Then see the formatting guidelines for help with creating and formatting your blog post MR.
3. Use the Blog post merge request template for your MR and ensure it is set to close the associated issue automatically.
4. Assign the issue and associated merge request to yourself and apply the appropriate labels based on what stage of creation you are on. Once it’s ready for editorial review, assign both to @rebecca. She will assign a member of the Editorial team to review the post.

If you have a blog post idea but do not intend to write it yourself, simply label the issue blog post and the content team will review during triage.
Blog post ideas and proposals for Content Hack Day should be created in the Content Hack Day project. We keep these issues in a separate project because not all ideas and proposals that come from Hack Day will be worked on.

Pick Your Brain posts

For follow-up posts to Pick Your Brain interviews with the CEO, as soon as an interview or livestream is scheduled, please open an issue in the gitlab.com/gitlab-com/www-gitlab-com project, using the PYB blog post template, and fill out the relevant information there.
The blog editorial team will assess the content of the post and decide how best to leverage it. This may mean publishing on the blog, on our Medium site, simply sharing the video on social, or something else.
Once agreed, the blog team will assign and communicate the expected publish date.

Blog post issue triaging

The Editorial team is responsible for triaging blog post issues and reviews the blog post queue.

• Issues that are labeled priority will be added to the top of the planning list.
• If issues that have an assigned writer have not been active for three months, the Editorial team will evaluate if the post is likely to draw high traffic, and may work with the writer or take the post over to get it finished.

• Content Hack Day issues that have a committed, assigned writer will be moved to the www-gitlab-com project – these issues should move directly to the In progress stage as they should already have a draft started

  Labels

• blog post: every blog post idea, proposal, draft, etc. MUST have this label

• priority: blog posts that should be worked on immediately
• Planning/in progress: blog posts that are assigned to a member of the Content Marketing/Editorial team
• Review: blog posts that are ready for an editorial review
• Waiting for author: blog posts that have been reviewed by the Editorial team and assigned back to the author to address feedback or approve for scheduling
• Scheduled: Blog posts that have completed reviews and are scheduled for publishing
• Guest/Partner post: blog posts that are authored and submitted from a contributor outside of GitLab
• customer story: blog posts that include a customer interview
• CEO interview: blog posts submitted by the GitLab CEO and require their subject matter expertise

• Content hack day: blog posts that have been accepted from the Content Hack Day project.

  Publishing schedule

  With the exception of time-sensitive announcements and news, we are aiming to have blog posts scheduled two weeks ahead.

• We will publish 2-3 posts per week, aiming to have a variety of topics covered within the same week.

• We will stagger publishing, generally avoiding posting on Fridays and in the last few days of the month.
• We don’t consider operational posts (patch release announcements, for example) as conflicting with other publishing, so we may publish a post on the same day that one of those goes live.
• We aim to ensure that posts that are likely to be popular are live in time to be included in the bi-weekly newsletter that goes out on the 10th and 25th of each month.

  Blog calendar

  The calendar below documents when posts will be published, as well as industry awareness days and anniversaries we may cover. Please bear this in mind when requesting a specific publish date for a post.
  Please note that all dates are subject to change to accommodate urgent posts and announcements.

  Writing blog posts

  The Content Marketing team is responsible for increasing sessions on the GitLab blog month over month. We use data-driven insights to decide what to write on using the content marketing dashboard. In order to hit our goals, we aim to publish at least 3 blog posts that will garner 10,000+ sessions.

  Trends

  *From 2018 blog analysis conducted in 2018-10

1. Average sessions per month on the blog: ~30,000
2. Average sessions per post in published month: 3,792
3. Average sessions per content marketing post in published month: 3,500
4. 55% of posts get <1,000 sessions in a month
5. 27.47% of posts hit our expected outcome of 1,000-4,999 sessions in published month
6. 28.57% of posts garner less than 499 sessions in published month
7. 9% of posts are “hits” (10K+ sessions in published month); “Hits” don’t consistently perform well over time

Breakdown by category of “hits”:

• Content: 37.5%
• Product: 31.35%
• Corporate: 25%

  Observations

1. There is not a strong correlation between # of sessions and topic
2. Strong performing content marketing posts focus on show and tell engineering stories
3. Posts really fall into the 5,000-9,999 session bracket (3.3%)

4. Content hack day posts tend to perform well (>1,000 sessions in published month)

   Identifying and qualifying a high-performing blog post

   Qualifying story ideas:
   Look for the following patterns:

5. Team implementing a new technology, process, or coding language

6. Deep dive into how a popular feature is made
7. Chronicling a performance improvement
8. Covering a controversial decision that was made

Who and how to interview:

1. Contact the technical subject matter expert. This can be someone who created the issue, or managed the project.
2. Set up a 30 minute interview and dig into:
   • What was the challenge?
   • What was the solution?
   • How did you go from point a to point b? Walk me through your thought process.
   • How was the solution implemented and what is a realistic use case of the solution?
   • What lessons were learned?
   • How did this make the GitLab product / development community better?
3. Optional: Contact the business subject matter expert. This could be a product manager or a product marketing manager.

4. Set up a 30 minute interview and dig into:

   • How does this solution help a user?
   • What business value does this solution bring?
   • How does this solution relate to our product?

     Attributes of a successful blog post:

5. Deep dive into a hard technical challenge.

6. Puts the reader in the shoes of the person who faced the challenge; reader learns via compelling example.
7. Intellectually satisfying; learning component.
8. Allows the reader to learn from someone else’s mistake, and follows a problem/trials and triumphs/solution story arch.

9. Taking a controversial or unpopular stance on a topic, back by hard evidence.

   Examples of high-performing posts (20K+ sessions in published month):

10. Meet the GitLab Web IDE

11. How a fix in Go 1.9 sped up our Gitaly service by 30x
12. Hey, data teams - We’re working on a tool just for you
13. Why we chose Vue.js
14. How we do Vue: one year later

    Conducting a blog analysis

    Pull information on all blog posts to document how many sessions each post received in the month, and how many sessions they received of all time. Categorize them by type, bracket, total sessions in month, total sessions to date, category, theme, and topic. Eventually add first touch point revenue data. Search Google Drive for Blog Performance to find the appriopriate sheet to work from.

• Blog post links should be added as they are published and category, audience, theme, and topic should be filled out.
• The Managing Editor and Manager, Content Marketing should review last month on the 1st of the month to fill out session information and make observations
• Review 1st of each quarter to update total sessions

Column explanations:

• Type: helps identify the frequency of which certain types of information is shared on our current blog
• Bracket: helps quickly sort blog posts by performance level
• Category: indicates class of information
• Total sessions in month: how many sessions the post received in the month it was published
• Audience: indicates who we expect to reach
• Theme: indicates the structure of the post
• Topic: indicates the main subject covered

  Preparing confidential blog posts

  In the event that we have a big announcement to make and the information must remain confidential until, use the forked project https://gitlab.com/gitlab-com/marketing/www-gitlab-com to prepare your merge request.

  Publishing natively on LinkedIn and Medium

  Occasionally, some blog posts are better suited to publishing natively by the author on LinkedIn, or on Medium. We reach slightly different audiences on these channels, and some content will get better exposure and reach if published there. If you submit a blog post and the content team decides it’s a better fit for one of these, we will let you know. For now, we will treat this segmentation as an experiment, monitor the performance of different types of content on different channels, and apply our learnings. We may then be able to start planning content for specific outlets and commission stories accordingly.

  Third-party posts

  We will promote anyone integrating with GitLab, even if we compete with them. It is very important to demonstrate to our customers that we do not lock them in.
  If you are a partner or industry-adjacent third party who wants to write for our blog, please contact the Partner Marketing team before proceeding.
  Blog posts concerning third parties or partners, whether they are to be published on the GitLab blog or externally, should be proposed to the blog editorial team before agreeing.
  As a rule, any blog post, regardless of the author, should offer some informational, educational, or entertainment value to the reader. We do not publish material that is exclusively promotional in nature.

  Guest posts by GitLab partners

  Official GitLab partners may use our CTA button and include promotional copy, however the blog post must still serve a function (informational or educational) other than simply promoting something.
  For either type of guest post, the process and guidelines for publishing are as follows:

1. Create an issue in the www-gitlab-com project and label it blog-post and guest/partner post.
2. If technical input is required, we will ask for instructions from the third party; otherwise it is at the discretion of the blog editorial and technical writing teams whether or not to go forward.

   Guest posts by non-partners

   If the author of a guest post is not an official GitLab partner, they may link back to their website or own content with inline links, but may not include a CTA button or promotional copy.