基于 GitLab foss 搭建的类 medium 的信息流协作平台

18508426569 — Sat, 25 Dec 2021 00:21:28 +0800

其实博客平台有很多，但是这个平台和其他平台有啥不一样的（当然平台目前也没啥内容，备案还没通过），下面是我在 devops 峰会闪电演讲的一些案例和场景，解释一下这个项目的来源：

1. 案例

1.1. 案例一：阮一峰《科技爱好者杂志》ruanyf/weekly

大家中应该有人读过他的博客或听说过他，他的《科技爱好者杂志》是每周五定时更新，每期都有多个板块：话题、文章、工具等，每个板块具有相应的多条内容，从 2018 年到目前已经更新了 185 期，几乎没有断更，这种级别内容的创作，一个人是几乎不可能完成的，当然他也确实不是一个人完成的。他基于协作工具 github，让参与者通过提交 issue 的方式参与到杂志的内容生产，目前 issue 数量已经达到 1.6k。

这个案例实际上也说明了，协作不止于代码，还可以让文字内容的创作更加高效、高质与高产。

1.2. 群体创作实验：未完成的文章——《海盗的田园时代》

这是一个公众号作者想要同关注者一同创作一篇文章，从这篇文章的标题来看，这篇共同创作的文章没有完成，但在这之中我们能看到什么呢，先简单看一看文章中的描述：通过以上描述，可以看到整个协作过程的效率并不是特别高，人工参与非创作的时间占比较高，这或许是共同创作未完成的原因。

下面再来说几个场景：

2. 场景

2.1. 场景一：技术分享，开篇就是最终篇

相信大家都经历过，遇到问题在网上搜索相关博客，并按照博主分享的方法并没有解决时，评论提交了自己的疑问，过了很久也不见回复时的绝望。在工作中，大家为了客户的体验，产品需要不断迭代更新，但是对于自己的分享，却好像没有迭代。

2.2. 肝了很久的项目，提交到 github 无人 star

程序员或多或少有点想造福他人的念头，有时候肝了很久项目，提交上去之后，希望能够有人光顾并 star，但是过了很久还是“star:0”,于是去其他平台写了博客，并贴了自己项目地址，无奈时不时有墙挡着，并不能顺利 starred。

基于以上案例或场景，可以看出在内容的创作、协作、迭代、推广过程中，不能做到很好的关联，不像 DevOps 的流程紧密高效。内容的创作过程，其实也和产品的发布过程有相似之处，内容构思=》创作=》协作=》推广，那能不能将产品研发过程中的 DevOps 理念应用到内容创作中，从而提升内容质量与产率呢？答案是可以的，我的解决方案是“Feed + Gitlab”,当然在这也非常感谢 Gitlab 团队的开源，让我可以站在巨人的肩膀上，去探索这件事。体验链接在这： https://1.14.250.46/home

仓库地址：https://gitlab.com/YushuaiLI/gitlab-foss 目的是打算做一个开源的内容平台，一个深度的分享平台，如果有小伙伴感兴趣也欢迎到仓库提交 issue