目标
- 建立信誉和权威。
- 提高对GitLab公司,产品和社区的认识。
- 增加自然搜索排名和流量。
-
范围
使命宣言:创建,策划和提升故事,以提高人们对整个DevOps生命周期中单个应用程序的好处的认识,以及对GitLab作为全远程工作的先驱者的认识。
请参阅下面成功的博客文章的属性,以获取在我们的博客上表现良好的故事的示例。
博客不是教程的永久场所,教程应该存在于文档中,并在相关时链接到。发布过程
我们遵循GitLab工作流程。每个人都可以做出贡献,我们鼓励任何人提交博客文章的想法或写自己的想法。以下是有关如何为GitLab博客做出贡献的说明。
时间敏感的帖子:官方公告,公司更新,重大更改和新闻
如果您需要发布时间紧迫的帖子,请务必提前通知内容团队。请遵循以下概述的过程:
首先使用模板并应用标签在gitlab.com/gitlab-com/www-gitlab-com项目中打开问题。即使您没有草稿或尚未确定的发布日期,也应尽可能提前打开问题并ping @rebecca,这一点很重要,这样她才能知道问题即将到来并可以据此确定优先顺序。
Blog post``priority
- 问题标题应反映您希望发布的日期。
- 发行截止日期应在发布日期之前两个工作日。
- 如果需要其他截止日期(例如,需要设计资产),请确保在问题描述中记录了整个时间表和所有负责人。
- 在大多数情况下,我们希望您或您的团队之一将撰写该帖子并为其创建合并请求,其中包括所有图像和其他格式。随时使用此博客文章模板开始草稿,该模板已嵌入所有相关信息。然后,请参阅格式化指南,以帮助您创建和格式化博客文章MR。
- 如果您在起草职位或创建MR方面需要帮助,请在您的问题中明确说明,我们将确认是否可以在您的时间范围内完成。
Blog post
对您的MR 使用合并请求模板,并确保将其设置为自动关闭关联的问题。- 在移交之前,请务必检查您博客文章的评论应用程序或在本地预览它,以确保图像,标题等的格式正确。
- 准备好审核您的MR时,请至少在预计发布之日前两个工作日,将其和相应的问题分配给@rebecca(如果Rebecca是OOO,则将其分配给@erica)。如果可以的话,请提早提交您的MR。
- 将您的MR分配给审阅者后,请更改发行日期,以反映发布日期。
- 您的审阅者可能会留下评论供您解决,在这种情况下,他们会将MR分配给您。解决所有悬而未决的讨论后,将MR分配给审阅者以进行最终审阅和合并。
谁将您的MR分配给–紧急职位
请首先分配给@rebecca。如果她是OOO,则分配给@erica。如果两者都不可用,并且您等不及要返回,请分配给技术写作团队的成员。尽可能选择与最相关的阶段组列出的技术作家。如果您需要立即的帮助/审查,请在Slack上找到在线的技术作家,以直接提出请求。无论如何,请确保指定任何时间来审查和发布内容。
持续交付的心态:对于时间敏感的帖子,如果您有足够的信息可以上线,请不要等待发布帖子。可以发布标题和段落以及时发布新闻并在以后添加更多详细信息(例如,添加更多图形,图表等)。我们不想错过新闻周期,因为我们正在等待图片或补充信息。时间敏感职位的错误预算
受工程使用的错误预算的启发。
错误预算应用于博客,可以激励对时间敏感的博客文章的预先计划和早期沟通。这有助于编辑团队最大程度地减少计划外工作,改编出版时间表或随后浪费或无法满足我们的使命和愿景或听众需求的时间。
每个职能小组负责每个季度不超过允许的15点预算。给出的分数将取决于对团队工作流程的影响的严重性:
- S1:15分-少于2个工作日的时间敏感通知(对于没有事先警告的行业或公司事件/新闻做出回应的情况除外)。
- S2:10分- 在发布日期之前至少 2个工作日内未提交完整的格式化MR 。
- S3:5分-MR提前提交,但没有包括所有必需的格式,链接和图像(除非另有协议)。
如果发生错误预算点,则编辑团队的成员将在有关问题或合并请求上贴上相关标签。积分将在本季度末进行汇总,并传达给超出预算的职能部门,以便我们可以共同制定解决方案,以防止将来出现这种情况。
如何避免产生错误预算点
- 使用博客文章发布模板,在知道需要博客文章后立即打开问题,并
@rebecca
提示您该文章需要在特定日期上线。 - 为您的博客文章创建MR,确保所有内容的格式均正确,添加了所有相关图像并包括链接。
- 检查评论应用程序或在本地预览以确保所有内容均符合预期。
@rebecca
提前将MR分配给您(至少要等两个工作日才能发布)。任何其他博客文章想法
您无需批准即可编写GitLab博客,但是,如果您建议的帖子与博客的目标和范围不符,则编辑团队可能建议您将帖子提交到GitLab未过滤的博客。如果您想为主要博客写一篇文章,请按照下面概述的过程进行。
注意:如果您打算编写教程文章来描述如何使用GitLab进行操作,请确保在撰写有关它的博客文章之前首先存在相关文档。博客文章不应替代文档,而应在技术主题周围添加更多信息,上下文和颜色,并链接回文档以获取完整说明。
- 使用模板在gitlab.com/gitlab-com/www-gitlab-com项目中打开一个问题
Blog post
。 - 随时使用此博客文章模板开始草稿,该模板已嵌入所有相关信息。然后,请参阅格式化指南,以帮助您创建和格式化博客文章MR。
Blog post
对您的MR 使用合并请求模板,并确保将其设置为自动关闭关联的问题。- 为您自己分配问题和相关的合并请求,并根据您所处的创建阶段来应用适当的标签。准备好进行编辑审核后,将它们都分配给@rebecca。她将指派编辑团队的成员来审核该帖子。
如果您有博客文章的想法,但又不想自己写,则只需标记问题blog post
,内容小组将在分流中进行审核。
博客文章的思路和建议,内容黑客日应在创建内容黑客日项目。我们不会将这些问题放在一个单独的项目中,因为并非所有来自Hack Day的想法和建议都将得到解决。
选择你的大脑职位
对于后续的职位,以与CEO挑选你的大脑采访,只要一接受采访或视频直播计划,请在打开一个问题gitlab.com/gitlab-com/www-gitlab-com项目,使用PYB blog post
模板,在此填写相关信息。
博客编辑团队将评估帖子的内容,并决定如何最好地利用它。这可能意味着在博客,我们的中型网站上发布,仅在社交上分享视频或其他方式即可。
达成协议后,博客团队将分配并传达预期的发布日期。
博客文章问题分类
编辑团队负责对博客文章问题进行分类并审查blog post
队列。
- 带有标签的问题
priority
将添加到计划列表的顶部。 - 如果指派了作者的问题在三个月内都没有活跃,则编辑团队将评估该帖子是否可能吸引大量访问,并可以与该作者合作或接替该帖子以完成工作。
具有确定的,指定的作者的Content Hack Day问题将移至www-gitlab-com项目–这些问题
In progress
应已开始草稿,因此应直接移至阶段标签
blog post
:每个博客帖子的想法,提议,草稿等都必须带有此标签priority
:应立即处理的博客文章Planning/in progress
:分配给内容营销/编辑团队成员的博客文章Review
:准备进行编辑审查的博客文章Waiting for author
:已由编辑团队审查并分配给作者的博客文章,以解决反馈或批准安排工作Scheduled
:完成评论并计划发布的博客文章Guest/Partner post
:由GitLab之外的贡献者创作和提交的博客文章customer story
:包含客户访谈的博客文章CEO interview
:GitLab CEO提交的博客文章,需要他们的主题专业知识Content hack day
:内容Hack Day项目已接受的博客文章。发布时间表
除了时间敏感的公告和新闻,我们的目标是在两周前安排博客文章。
我们每周将发布2-3个帖子,旨在在同一周内涵盖各种主题。
- 我们会错开发布时间,通常避免在星期五和每月的最后几天发布。
- 我们认为操作性帖子(例如,补丁发布公告)与其他发布不冲突,因此我们可以在其中一个发布的同一天发布一个帖子。
- 我们的目标是确保及时发布可能流行的帖子,并将其包含在每个月的10日和25日发布的双周新闻通讯中。
博客日历
下面的日历记录了何时发布帖子,以及我们可能涵盖的行业宣传日和周年纪念日。在请求帖子的特定发布日期时,请记住这一点。
请注意,所有日期可能会更改,以适应紧急发布和公告。撰写博客文章
内容营销团队负责每月在GitLab博客上增加会话。我们使用数据驱动的见解来决定使用内容营销仪表板写些什么。为了实现我们的目标,我们的目标是至少发布3个博客文章,这些博客文章将获得10,000多个会话。发展趋势
*摘自2018-10年度的2018年博客分析
- 博客每月平均会话数:〜30,000
- 发布月份每个帖子的平均会话数:3,792
- 每个内容营销职位在发布月份的平均会话数:3,500
- 55%的帖子每月获得<1,000个会话
- 27.47%的帖子在发布月份达到了我们预期的1,000-4,999次会话的预期结果
- 在发布的月份中,有28.57%的帖子获得少于499个会话
- 9%的帖子是“热门”(已发布月份的10K会话以上);随着时间的流逝,“命中率”的表现并不一致
按“点击数”类别细分:
- 会话数与主题之间没有很强的相关性
- 表现出色的内容营销职位专注于展示和讲述工程案例
- 帖子确实属于5,000-9,999个会话支架(3.3%)
内容黑客日活动通常表现良好(在发布的月份中有超过1,000次会话)
识别和鉴定高性能博客文章
符合条件的故事创意:
查找以下模式:团队实施新技术,流程或编码语言
- 深入研究流行功能的制作方式
- 逐步改善性能
- 涵盖已做出的有争议的决定
谁以及如何面试:
- 联系技术主题专家。这可以是创建问题或管理项目的人。
- 进行30分钟的采访并深入探讨:
- 挑战是什么?
- 解决方案是什么?
- 您是如何从a点转到b点的?引导我完成您的思考过程。
- 解决方案是如何实施的,解决方案的实际用例是什么?
- 学到了什么?
- 这如何使GitLab产品/开发社区变得更好?
- 可选:联系业务主题专家。这可以是产品经理或产品营销经理。
进行30分钟的采访并深入探讨:
深入研究艰巨的技术挑战。
- 让读者坐在面对挑战者的面前;读者通过引人注目的例子学习。
- 智力上令人满意;学习组成部分。
- 允许读者从别人的错误中学习,并遵循问题/试炼和胜利/解决方案的故事弓。
-
高绩效职位的示例(在发布的月份中有2万多个会话):
- Go 1.9中的修复程序如何使我们的Gitaly服务加速30倍
- 嘿,数据团队-我们正在为您开发一种工具
- 为什么我们选择Vue.js
- 我们如何做Vue:一年后
进行博客分析
拉取所有博客文章上的信息,以记录每个帖子在一个月中收到了多少次会话,以及他们在整个时间中收到了多少次会话。按类型,括弧,每月总会话数,迄今为止的总会话数,类别,主题和主题对它们进行分类。最终添加第一接触点收入数据。在Google云端硬盘中搜索Blog Performance
以查找合适的工作表。
- 发布博客链接时,应添加这些链接,并填写类别,受众,主题和主题。
- 内容营销的执行编辑兼经理应该在每月的上个月进行审核,以填写会议信息并进行观察
- 在每个季度的第一天检查一次,以更新总会话数
列说明:
- 类型:有助于确定在当前博客中共享某些类型信息的频率
- 括号:可帮助您按效果水平快速对博客文章进行排序
- 类别:表示信息类别
- 月中的总会话数:该帖子在发布当月收到的会话数
- 受众群体:表明我们希望与谁联系
- 主题:表明帖子的结构
- 主题:表明涵盖的主要主题
准备机密博客文章
如果我们要进行重大公告,并且必须对信息保密,直到使用分叉的项目https://gitlab.com/gitlab-com/marketing/www-gitlab-com
准备您的合并请求。在LinkedIn和Medium上本地发布
有时,某些博客文章更适合作者在LinkedIn或Medium上以本机发布。在这些渠道上,我们的受众群体略有不同,并且某些内容在该渠道发布后会获得更好的曝光率和影响力。如果您提交了一篇博客文章,而内容团队认为它更适合其中一种,我们将通知您。目前,我们会将这种细分视为一种实验,在不同渠道上监控不同类型内容的效果,并运用我们的经验。然后,我们也许可以开始为特定商店计划内容并相应地委托故事。第三方帖子
我们将提倡任何与GitLab集成的人,即使我们与他们竞争。向客户证明我们不会锁定他们是非常重要的。
如果您是想要为我们的博客撰写文章的合作伙伴或与行业相邻的第三方,请在继续之前与合作伙伴营销团队联系。
有关第三方或合作伙伴的博客文章,无论是在GitLab博客上发布还是在外部发布,都应在同意之前向博客编辑团队提出。
通常,任何博客帖子,无论作者如何,都应为读者提供一些信息,教育或娱乐价值。我们不会发布纯粹是促销性质的材料。GitLab合作伙伴的来宾帖子
正式的GitLab合作伙伴可以使用我们的CTA按钮并包含促销副本,但是该博客文章除了简单地推广某些东西外,还必须具有其他功能(信息性或教育性)。
对于任何一种来宾帖子,发布的过程和准则如下:
- 在www-gitlab-com项目中创建一个问题,并将其标记为
blog-post
和guest/partner post
。 - 如果需要技术投入,我们将要求第三方提供指导;否则,是否继续前进取决于博客编辑和技术写作团队。
非合作伙伴的来宾帖子
如果来宾文章的作者不是GitLab的官方合作伙伴,则他们可以使用内联链接链接回其网站或自己的内容,但不包括CTA按钮或促销副本。