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

18508426569 · 2021年12月25日 · 最后由 lidashuang 回复于 2021年12月27日 · 424 次阅读

其实博客平台有很多,但是这个平台和其他平台有啥不一样的(当然平台目前也没啥内容,备案还没通过),下面是我在 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

没个域名?

需要 登录 后方可回复, 如果你还没有账号请 注册新账号