连接微信群、Slack 和 GitHub:社区开放沟通的基础设施搭建
NebulaGraph 社区如何构建工具让 Slack、WeChat 中宝贵的群聊讨论同步到公共领域。
要开放,不要封闭
在开源社区中,开放的一个重要意义是社区内的沟通、讨论应该是透明、包容并且方便所有成员访问的。这意味着社区中的任何人都应该能够参与讨论和决策过程,并且所有相关信息应该公开和自由地与他人共享。
在公共场合进行沟通在开源理念中是重要的,正是这种方式使得社区的成员可以进行有效地共同工作,分享想法和反馈,为项目或社区做出贡献。
但是,社区在实践开放性沟通的过程中,或多或少都会遇到以下一些情况:
- 工具选择,本该是用来降低沟通成本的工具,却阻碍了部分社区成员在开源社区中的开放沟通。例如:
- 邮件列表交流模式是我个人很偏爱的方式,但在中文社区背景下,因为邮件列表不是所有用户都能够 access,其作为中文社区单一沟通渠道可能会带来沟通的不对等性(一定程度只有部分的人有特权表达自己),反而伤害中文开源社区的开放性。
- 选择交流工具的时候选择了付费产品,社区成员需要为此买单,而并非所有社区成员都能负担得起,这也导致了部分社区成员不能参与到社区中。
- 所用工具难用,或者需要一定的技术经验积累,而这经验并非所有社区成员都具备。
- 用于交流的工具在某些操作系统或设备上不兼容,这可能使一些社区成员难以访问它们,更别提使用它们。
- 信息共享,在不与社区其他成员分享上下文、过程或结果的情况下,只在线下(例如:通过当面沟通、IM 或电话会议)进行决策可能会使重要信息只被少数社区成员掌握。这可能会阻止其他人基于这些信息做贡献,或是从中学习知识,阻碍了开源社区所必需的开放沟通和协作。
- 资料公开,没有把系统、功能设计和提案信息以公开方式文档化、归档下来,例如:只提供某一个公司内网的链接,从而可能伤害开源社区的透明度和包容性。这样的封闭结果会使得社区的其他成员很难保持对社区进展的了解、就更不用说参与进来做贡献了。为了促进透明度和包容性,开源社区应尽量确保所有重要的信息公开和自由地共享、尽可能保有细节地被公开归档。
开放性挑战
为了使社区(或工作环境)的沟通保持透明、高效和健康,其实已经存在一些共识,和通用的做法:
- 异步优于同步,在分布式和全球协作的情况下,同步通信在大多数情况下成本高且效率低。因此,推荐使用 GitHub Discussion 和 Stack Overflow 进行提问式的沟通。
- 专题(Thread)讨论优于广播(Fan out),注意力是宝贵的,习惯性向所有人群发送信息会最终导致重要信息没有人真的读到信息,都知道狼来了的故事。因此,在 GitHub Discussion 和 Slack 中设有分类、频道。建立 SIG 来讨论一些有趣的主题并归档沟通的结果,而不是将所有事情带到社区会议广泛讨论。
- 优先选择可搜索/文本、版本控制、协作的方式与工具,并在可能的情况下鼓励成员们给其他人反馈;在基础设施上跟踪文档、设计流程,并且提供评论、review 的能力。为此,实践过程中采用 etherpad.opendev.org 来记录社区会议文档。
但是,还是存在一些特例的情况,我们不能盲目追求异步、绝对的开放。正如前面提到的,能让更多参与者公平、方便与社区连结本身也是开放的一部分,尽管使用的基础设施可能是封闭的。事实上,几乎所有的开源社区都在用类似的方式建立他们的社区沟通平台:
- Slack 支持丰富的格式化信息(支持 Markdown!)和 Thread 系统,其现代化的设计和开放/软定义接口使我们的工作流程可以非常优美流畅。
- 与 Slack 相比,因为微信不是专为开放的技术交流场景设计,所以微信在技术社区中在许多方面都很不理想。但在国内,它是社区中所有人都可以访问的唯一平台。几乎每个人都有一个微信账号,几乎每天都会查看微信信息。但与之相反的是,几乎上每个人都有不止一个邮箱,且只有很少一部分人会每天查邮件。
在 NebulaGraph 社区中,上面这两个平台承担了主要的沟通工作,但这些信息在出现后的几个月后就会消失,它们在短时间内只能被割裂的一部分社区成员看到,而未来没有人或其他平台可以读到、搜到和参考、引用这些有价值的讨论。
摸索的方案
曾经有一段时间,NebulaGraph 会自己手动收集 Slack、微信群里的讨论摘要,定期分享、归档在公共领域,这个方法也确实带来了一些价值。然而,我们最后都没坚持下去,原因很简单:
- 这太费事儿了,完全不 scale;
- 这种摘要其实不好平衡能被归档信息的裁剪程度,有时候细节非常重要却不容易被摘要保留。
搞定 Slack 的信息孤岛
2022 年 10 月,我注意到了 linen.dev 这个开源项目,同时它也是一个 SaaS 服务。有了它,我们可以把 Discord 和 Slack 中的每个 thread 保留。linen.dev 整站看起来和 Discord / Slack 几乎一样,但是,它完全是可以被匿名访问、引用,以及被搜索引擎收录供他人检索使用。
经过几个月的评估,我们最终决定了订阅 linen.dev 服务,并收获的果实:
- 不用去改造现有 Slack,保留 Slack 所有的好处;
- 有了这样 https://community-chat.nebula-graph.io/ 的一个站点收录 Slack 信息。其中,Slack 中的每个公共频道内容都能被匿名访问、被搜索引擎收录,而访客还可以很容易地知道怎么加入我们的 Slack,如图右上角:
这个站会实时同步 Slack 里的消息,重要的是,它是面向搜索引擎优化过的,你可以搜搜 Kotlin 社区通过 Linen 被收录的网页有多少,搜这个:"site: slack-chats.kotlinlang.org"。
此外,每一个 Slack thread 都有一个无需登录的只读 URL,我们可以方便去分享、引用它。虽然,这件事儿本身就是超链接、URL 的作用。但是,在现在已经变得非常不容易了,比如:这个新闻里提到现在新一代的年轻人更倾向于在抖音里搜索而不是在公共领域里。
有了 Linen,我们可以非常开心地在 GitHub 里引用任意一个 Slack 讨论话题:
解决了 Slack 的问题之后,唯一剩下的痛点就是微信群了。微信群每周都有许多宝贵的讨论在社群中进行,却不能被保留下来,真是太令人心疼了。终于有一天,我决定直面这个问题。
解决微信群的信息公开化
首先,能不能直接用 Linen 一把梭,同步群消息呢?我确实在 Linen 社区和他们的 Kam 讨论直接解决 IM 同步的可能,不过到现在,他们都没有优先考虑😭。
但,机智如我,我想如果直接把微信同步到 Slack,Linen 不就能把微信的信息也收录了吗?
在 Twitter 上 求助黑客/开源社区 + 一番调研确定了没有这样的东西存在之后,我决定搞一个,做成开源项目,我花了一点时间实现了最初的版本。
万万没想到,当我做到把消息从微信同步到 Slack 之后,随之而来的问题是,通过 Slack API 发出的消息 Linen 并不会收录。
为此,我放弃了 Linen 一把梭的美好愿望,转而考虑把消息同步到其他公共领域。而我第一个想到的就是 GitHub Discussions 之中,又花了周末的下午加晚上,把它做出来了:
现在,这个机器人程序会把配置好的微信群消息同时同步到 Slack 频道和 GitHub Discussion 中给定的标签下的主题中,每一个群一个礼拜是一个主题,所有的消息都是主题下的评论。
小结
现在,我们保留了所有 Slack / 微信的美好的一面的同时,把它们中的讨论消息历史全都归档、索引并公开到这两个域之下了,是不是很酷呢?来访问下下面的链接,感受“私密消息”下消息被公开的快乐吧:
- https://community-chat.nebula-graph.io/
- https://github.com/vesoft-inc/nebula-community/discussions/categories/wechat-chat-history
后续工作
这个同步微信的项目是 Apache 2.0 协议开源的,并且现在由我和Frost Ming在维护,这里还有很多待增强、实现的新功能、新任务,欢迎大家来试玩、贡献。
让我们一起把开源社区的沟通做的多一点开放、少一点封闭吧~
项目地址 👉🏻 https://github.com/wey-gu/chatroom-syncer
最新进展
在圣诞节前,Linen 的工程师允许了 chatroom-syncer 同步到 Slack 的消息,详见:
现在,我们可以在 https://community-chat.nebula-graph.io/c/wechat-sync-venus 看到 WeChat 中的群聊的文本备份了!当然啦,如果你更喜欢 GitHub Discussion 的方式,help yourself,选你选的方式就好。
结论
有效的沟通是成功的开源社区的基石,因为它让协作、分享思想与知识、以及所有成员的参与成为可能。为了确保沟通透明、包容和有效,对于开源社区来说,让所有成员有机会参与讨论和决策以及公开自由地分享相关信息是非常重要的。
我们 NebulaGraph 社区的建设者/贡献者将继续寻找和黑客方法,以开放和良好的方式使人们连接在一起,和大家共建更好的开源、技术社区。
谢谢你读完本文 (///▽///)
要来近距离体验一把图数据库吗?现在可以用用 NebulaGraph Cloud 来搭建自己的图数据系统哟,快来节省大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天免费使用中,点击链接来用用图数据库吧~
想看源码的小伙伴可以前往 GitHub 阅读、使用、(^з^)-☆ star 它 -> GitHub;和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能,留下「你的名片」一起玩耍呢~

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
非侵入式入侵 —— Web缓存污染与请求走私
作者:vivo 互联网安全团队- Gui Mingcheng 本文介绍了两种攻击者无需直接接触服务端即可攻击和影响用户行为的安全漏洞 —— Web缓存污染与请求走私。Web缓存污染旨在通过攻击者向缓存服务器投递恶意缓存内容,使得用户返回响应结果而触发安全风险。HTTP请求走私旨在基于前置服务器(CDN、反向代理等)与后置服务器对用户请求体的长度判断标准不一致的特性,构造能够被同一TCP连接中其它用户夹带部分恶意内容的攻击请求,从而篡改了受害者的请求与响应行为。两种漏洞均需要通过针对中间件的合理配置与业务接口的合理设计进行排查和防御。 一、Web 缓存污染攻击原理与场景 1.1 什么是缓存? 缓存技术旨在通过减少延迟来加速页面加载,还可以减少应用程序服务器上的负载。一些公司使用像Varnish这样的软件来托管他们自己的缓存,而其他公司选择依赖像Cloudflare这样的内容分发网络(CDN),缓存分布在世界各地。此外,一些流行的Web应用程序和框架(如Drupal)具有内置缓存。Web缓存污染关注的是CDN等前置服务端部署的缓存服务,还有其他类型的缓存,例如客户端浏览器缓存和DNS缓存,...
- 下一篇
从5分钟到60秒,袋鼠云数栈在热重启技术上的提效探索之路
更好地提高效率一直以来是袋鼠云数栈产品的主要目标之一。当前数栈客户的实时任务都是基于 Per-Job 模式运行的,客户在进行一些任务参数的修改之后,只能先取消当前任务,再选择 CheckPoint 恢复或者重新运行,整个过程需要3-5分钟,比较浪费时间。为了达到提高效率的目的,我们针对 Per-Job 任务的整体流程分析,进行了相关探索。 下文和大家聊聊数栈在热重启技术方面的探索之路。 热重启是什么? 热重启技术旨在复用当前 Per-Job 集群的相关资源,减少重新创建集群以及申请资源的耗时,同时通过 CheckPoint 机制保障数据的正确性。 Flink 的 Per-Job 模式是指每个任务都会对应一个独立的 Flink 集群。在任务提交的时候,会创建一个 Flink 集群进行任务的运行,整个集群只为这一个任务进行服务。同时 Flink 集群不允许继续提交任务,导致任务修改之后,只能 Cancel 当前任务。重新提交修改后的任务,创建一个新的 Flink 集群进行运行。 经过分析,耗时主要是由于以下两部分原因造成: • Client 需要在 Yarn 上启动一个 Flink 集群,...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- SpringBoot2全家桶,快速入门学习开发网站教程
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- 2048小游戏-低调大师作品
- SpringBoot2更换Tomcat为Jetty,小型站点的福音
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- CentOS7,8上快速安装Gitea,搭建Git服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块