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.
A tweet should contain a short hook/summary of the main takeaway of the content and should mention (@) people when characters permit. This is a great way to encourage further engagement from GitLab team members and community members alike.
Examples of content to be tweeted include announcements about events, product changes, company news, new team members, blog posts, and interviews or bylines of GitLab leadership in other publications
Retweet high profile mentions, as well as occasional high quality tweets (no typos or profane usernames) from people who mention switching to GitLab, positive anecdotes about using GitLab, positive comments about blog content.
The Jr. Content Editor will check our mentions at least once per day to collect articles from the community to share, post in #content for the team to read, or reach out to the author for a cross post or some other additional engagement. If you find an article on social from the community you think would be of interest to the team, post in #content.
Facebook & LinkedIn
Content posted on these channels is a subset of what we share on Twitter.
Include a longer pull quote or other share text on these platforms; do not copy the tweet.
Generally schedule posts to go out between 7 am - 10 pm Eastern Time
Try to schedule posts in such an order that will maintain variety in the feed (i.e., don't have 5 new team members tweeted out in a row)
Recycling of content on Twitter
Re-post content that gets a good response, such as positive blog comments, front page of hacker news, or the front page of reddit programming
Re-post gated content items
Repost up to two times after the original post, scheduling the posts to go out 1-2 weeks apart
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