The Content Marketing team includes audience development, editorial oversight, social marketing, media sponsorships, and content strategy, development, and operations. The Content Marketing team is responsible for the stewardship of GitLab's audiences, users, customers, and partners' content needs, preferences and perceptions of GitLab. Content marketing creates engaging, inspiring, and relevant content, executing integrated content programs to deliver useful and cohesive content experiences that build trust and preference for GitLab. Content marketing oversees the GitLab blog, newsletters, social media channels, webinars, customer case studies and reference program, and topical web content creation.
The content marketing team is responsbile for updating the /press and /press/releases/ pages.
Updating the /press/releases page
Create a new merge request and branch in www-gitlab-com
On your branch, navigate to source then press and click on the releases folder
Add a new file using the following format YYYY-MM-DD-title-of-press-release.html.md
Add the following to the beginning of your document
layout: markdown title: "Title of press release" —
Add the content of the press release to the file and save. Make sure to include any links.
Updating the recent news section
Every Friday the PR agency will send a digest of top articles
Product marketing will update the Recent News section with the most recent listed at the top. Display 10 articles at a time. To avoid formatting mistakes, copy and paste a previous entry on the page, and edit with the details of the new coverage. You may need to search online for a thumbnail to upload to images/press, if coverage from that publication is not already listed on the page. If you upload a new image, make sure to change the path listed next to image_tag.
Move older content to the archive.
Editorial Mission Statement
Empower and inspire software teams to adopt and evolve a DevOps workflow to collaborate better, be more productive, and ship faster by sharing insightful and actionable information, advice, and resources.
Build the largest and most diverse community of cutting edge co-conspirators who are leading the way to define and create the next generation of software development practices.
2018 Core content strategy statement
The content we produce helps increase awareness of GitLab’s complete and single application with the goal of broadening our market share and increasing sales by providing informative and persuasive content that makes DevOps teams feel excited, curious, and confident so that they can adopt & integrate industry best practices into their workflow.
Messaging for Verticals
When to develop vertical messaging: The key is to determine if an industry has a certain pain point that another industry does not share. You need to describe the problem (using industry specific terminology, if necessary) and also how your product solves these problems for them. Additionally, you can create high-level messaging and then branch off; for example if multiple industries are very security conscious, create security focused marketing, and adapt to select high value verticals.
Checklist for good content
User or customer-centered
Clear, Consistent, Concise
Crediting blog posts
Add a note at the end of a blog post reading "[Name] contributed to this story/post" if:
You ghostwrote the post on behalf of someone else who is listed as the author
You were heavily involved in editing/structuring/rewriting the post authored by someone else
You wrote the post, but it is a company announcement listing GitLab as the author
You wrote the post and are listed as the author, but wish to give credit to interviewees
At the highest level, Content Marketing is responsible for building awareness, trust, and preference for the GitLab brand with developers, engineers, and IT professionals.
Editorial voice and style
Defining and executing the quarterly content strategy
Content marketing is responsible for executing marketing campaigns for GitLab. We define a campaign as any programmed interaction with a user, customer, or prospect. For each campaign, we will create a campaign brief that outlines the overall strategy, goals, and plans for the campaign.
Campaign Brief Process
To create a campaign brief, first start with the "campaign brief template" (which can be found by searching on the google drive). Fill out all fields in the brief as completely as possible. Certain fields might not be applicable to a particular campaign. For example, an email nurture campaign leveraging text based emails won’t have a visual design component. This field can be left blank in that example.
Once the campaign brief is filled out, create an issue in the GitLab Marketing project and link to the campaign brief.
On the GitLab issue, make sure to:
Tag all stakeholders
Use the Marketing Campaign label
Set the appropriate due date (the due date should be the campaign launch date)
If there are specific deliverables, create a todo list in the issue description for each stakeholder along with a due date
We use giveaways to encourage and thank our community for participating in marketing events such as surveys, user-generate-content campaigns, social programs, and more.
Create an issue and tag Emily von Hoffmann (@evhoffmann) to determine the rules of engagement and Emily Kyle (@emily) for prizes.
Winners must sign an Affidavit of Eligibility & Liability, Indemnity, and Publicity Release. Use the "Affidavit of Eligibility - Sweepstakes" template found on the google drive.
Announce the winners
Social Support & Logistics for Giveaways
Creating the Campaign
Set a launch date
Ask for social image(s) with text (if organic posts only) explaining the offer/ask
Set an initial deadline for submissions, so you can have multiple pushes at interval & ramp up energy
Finalize the delivery method: form vs. tweets vs. retweets, depending on the goals of the campaign
Pros of a form: Neat, uniform, easy for us to keep track of, no downsides of low engagement (i.e., responses not visible)
Pros of asking for submissions via Twitter: we could more easily RT cool responses, get more out of a hashtag, etc.
Pros of asking for RTs in exchange for swag: very little backend to do on social afterwards, except to announce the winners of swag
Finalize the ask, making sure it's extremely clear what you want to happen (Share your GitLab story!Tell us your favorite thing you made with GitLabtell us a time GitLab helped you out of a tight spot)
Make sure the ask can be intuitively communicated via whichever delivery method you're using, i.e., the tweet doesn't need to explain everything if you're pointing to a form or blog post. If you're not pointing to anything, make sure the tweet plus possible image text must make sense by themselves. Use threads for more space!
Finalize the timeline for when the reminders/follow-ups will go out, add to social schedule and leave some space around them to RT/engage with responses
Finalize copy for all pushes
If swag is involved, create a google sheet with swag codes from Emily Kyle
Ask community advocates to review all copy (tweets, form, blog post) and adjust according to their suggestions
Make sure the community advocates are aware of the campaign timeline/day-of
Designate a social point person to be "on duty" for the day-of and one person who can serve as backup
Let the broader GitLab team know that the social campaign is upcoming and ask for their support
Day of giveaway
If you have entries for the giveaway in a spreadsheet, use random.org to generate a random number. Match the number to the corresponding row in your spreadsheet to identify the winner. Never enter email addresses or personal information of participants into a third-party site or system we do not control.
Try to schedule first push or ask a team member to tweet the first announcement early (ex: around 4 am PT) to try to have some overlap with all our timezones
If you're asking for RTs in exchange for swag, make sure there's a clearly communicated cut-off to indicate that the giveaway will not stretch into perpetuity. One day-long is probably the longest you want a giveaway to stretch, or you can limit to number of items.
Plan to engage live with people
If your promise was to give away one hoodie per 25 RTs, do it promptly after that milestone is crossed. It adds to the excitement and will get more people involved
Announce each giveaway and use handles whenever possible, tell them to check their DMs
DM the swag codes or whatever the item is
In your copy, directly address the person/people like you are chatting with them irl
RT and use gifs with abandon but also judgment
After the Giveaway
Thank everyone promptly, internal & external
Write in the logistics issue of any snags that came up or anything that could've gone better
Amend hb as necessary for next time
How to Create an Official Sweepstakes Rules Page
Create a new folder in /source/sweepstakes/ in the www-gitlab-com project. Name the folder the same as the giveaway /source/sweepstakes/name-of-giveaway
Add an index.html.md file to the /name-of-giveaway/ folder
So you've been nominated for a short-term takeover of GitLab's social channels — here's a quick guide with everything you need to know.
Create tracked links for every link back to about.gitlab.com (e.g., all blog posts, landing pages, etc.)
Publish and schedule in Sprout, using the “shorten links” button
Choose a tag for every post that goes out (there is a dropdown)
Preview posts in Sprout to make sure spacing, image, etc. looks fine on desktop and mobile
Check the schedule in Sprout.
Do not publish more than 1-2 times per day on Facebook & LinkedIn (studies show > 2 posts per day on brand pages on these platforms starts to feel spammy).
Do not publish tweets within 30 minutes of each other. Retweets of other stuff within that time is fine.
Especially if someone reacts to an article that you tweeted with a substantive comment, question, or conversation starter, that is a good one to retweet promptly, because it could spur additional engagement.
If you’re debating between posting early and posting late, post early (i.e., 4 am Pacific). We have a sizable audience in Europe, so it’s best to resist posting after 4 pm PT (unless it’s a retweet, or a post that is newsworthy and published late)
Newly published posts
Retweet of substantive, high quality tweets, especially from team members
Can also fill some space in the afternoon with a job posting (“jobs of the week” are in the company call agenda doc)
Have fun with it! Be liberal with emojis.
In addition to retweeting described above, please perform a search on #gitlab and gitlab a few times per day (can be within Sprout or twitter) and favorite positive mentions
Any particularly funny or complimentary posts, you can comment on with a gif, :blush:, “Thanks! We’re so glad you like it, let us know how we can help!” etc.
Be creative but refer back to these guidelines for the GitLab voice
If you know there is going to be a long (1+ days) delay between when you need to sign off and when the next person takes over (i.e., for Summit travel), I recommend scheduling a tweet saying something like “The team is heading to beautiful Cape Town for our xth Summit! See you on the other side :airplane:” This helps prime people for the disruption of regular content.
Social Channels and Audience Segmentation
You can find a list of evergreen content assets their primary channel for promotion here.
Broad audience - all our content gets shared here, but tone should still appeal to devs.
5 or more tweets per day, plus retweets
Schedule between 12 am - 5 pm PT (A large part of our audience is in EMEA, and we find an increase in organic impressions and engagement when we schedule tweets for their morning and workday)
At least 30 mins apart
Aim for variety & roughly even mix of main topics: Git, CI/CD, collaboration, DevOps, employer branding, product-specific, community articles & appreciation
Check mentions at least once per day, pull out articles to share with the team and favorite positive mentions.
Keep a list of our most engaged followers; keep these in mind for opportunities outside of social–blogging, live streamed interview etc.
15 tweets per day
2-4 videos published natively per month
5 lead-generating content items from the backlog published per month
Consider takeovers. Would need to develop an instructions kit & think about how/who to pilot.
Developer/community- and thought-leadership focused
1-2 facebook posts per day
At least 2 hours apart
Live events are more company/culture focused
talks by or AMAs with People Ops, etc.
Consider streaming a webcast on Facebook Live (a simple toggle switch in Zoom allows this) and compare the performance to YouTube live streaming
When the speaker cameras are enabled in Zoom webinars, natively publish clips of webcasts for post-promotion.
IT buyer/manager focus
3-5 posts per week
Non-tutorial original blog posts
Press releases/product announcements
Posts around particular features, releases, company culture, people ops new practices, problem/solution or personal growth structured posts; include links back to homepage
Identify key LinkedIn groups to join/share content in
Native posts on LinkedIn
Encourage targeted employees to do so; think of incentive/framing as professional development that we will help edit.
Curate and share articles from other publishers on remote work/culture that we want to elevate
Developer/community- and thought leadership-focused
Favorite articles about GitLab
Aim to post one article to Medium every two weeks
Cross-post our original thought-leadership posts to Medium, linking back to blog
Group Conversations, pick your brain meetings, demos, brainstorms, kickoffs
Re-post older articles from the archive periodically that we want to continue giving a boost
Aim for at least one post per week
After Committing to an Event
Find relevant handles (of speakers/moderators/hosts) or hashtags (if part of bigger conference for example), or create our own; try to include across all tweets for that event, characters permitting
Find event-related images to attach to all tweets (event logo showing GitLab sponsorship; speaker team pic; GitLab logo; or any sharable content designed for that event)
Schedule a tweet asap announcing our participation
Leading up to an Event, Schedule Tweets to go out:
1 week before event (counting down, include registration link if our event, include speaker team pic or other event branding where applicable)
1 day before event (same as above)
During event referencing something in the content of the presentation if applicable/ not redundant (x2 or more depending on length of event and amount of content)
Need to find balance between the dev advocates promoting themselves at events and when they are speaking- maybe one of these tweets is us retweeting them?
While at the Event:
Take pictures of booth and/or team members at booth
Try to tweet them out ~1 hour or more before event (mention our location in the venue if applicable/useful)
After the Event:
Thank those who attended or stopped by our booth in tweet with photo from the event
Ensuring your Post Will Have a Functional Card and Image
When you post a link on Facebook or Twitter, either you can see only a link, or a full interactive card, which displays information about that link: title, description, image and URL.
For Facebook these cards are configured via OpenGraph Meta Tags. Twitter Cards were recently set up for our website as well.
Please compare the following images illustrating post's tweets.
A complete card will look like this:
An incomplete card will look like this:
Note that the first post has a specific description and the image is a screenshot of the post's cover image, taken from the Blog landing page. This screenshot can be taken locally when previewing the site at localhost:4567/blog/.
Defining Social Media Sharing Information
Social Media Sharing info is set by the post or page frontmatter, by adding two variables:
This information is valid for the entire website, including all the webpages for about.GitLab.com, handbook, and blog posts.
All the images or screenshots for twitter_image should be pushed to the www-gitlab-com project at /source/images/tweets/ and must be named after the page's file name.
For the second post above, note that the tweet image is the blog post cover image itself, not the screenshot. Also, there's no description provided in the frontmatter, so our Twitter Cards and Facebook's post will present the fall back description, which is the same for all about.GitLab.com.
For the handbook, make sure to name it so that it's obvious to which handbook it refers. For example, for the Marketing Handbook, the image file name is handbook-marketing.png. For the Team Handbook, the image is called handbook-gitlab.png. For Support, it would be named handbook-support.png, and so on.
The description is not meant to repeat the post or page title, use your creativity to describe the content of the post or page. Try to use about 70 to 100 chars in one sentence.
As soon as you add both description and social sharing image to a page or post, you must check and preview them with the Twitter Card Validator. You can also verify how it looks on the FB feed with the Facebook Debugger.
To see it working, you can either share the page on Twitter or Facebook, or just test it with the Twitter Card Validator.