一点思考|为什么建议开源社区的技术交流使用邮件列表?

简介: 来自互联网小运营的一点思考,和大家分享一下~

引言

最近朋友大力推荐了《开源之谜》这本书,目前已经读了近 2/3。作为一个开源方向的小运营,很多时候还在摸着石头过河,但书中的内容可以不断激发自己对开源的思考,实在与此书相见恨晚。结合自己最近查阅的一些资料,有一些想法迫不及待想要和大家分享。深知自己阅历尚浅,希望能与大家多多交流,不足之处也希望大家多批评指正。


自从进入运营行业,发现一件事是绕不开的:建群


互联网行业的运营更是喜欢这一套玩法:组织线下 meetup 讲讲技术,引导大家加群;线上直播搞个抽奖,引导大家加群;新产品、新功能上线搞点拉新活动,还会引导大家加群。

躺在聊天列表里的群聊越来越多,每天一打开手机,各种群聊消息已经刷了一轮又一轮……感兴趣的,随便点开一两个扫两眼,回几条消息几个表情,碎片时间就用的差不多了。

有一件事让我印象很深刻:在一次线下 meetup 抽奖时,前置条件需加入社群,有很多参与者就会“加群——抽奖——没中奖——退群”一套流程行云流水;加入群聊的人,抽奖过后选择默默潜水的也不在少数。社群数量看似起来了,但活跃的用户却真真没几个……

越来越多的群聊消息也逐渐成为了大家的负担,【消息免打扰】逐渐不能满足大家的需求,微信敏锐的捕捉到了用户的这一“痛点”,及时推出【折叠该群聊】功能 🌝,不知道又有多少社群被打入冷宫,社群运营同学要哭晕在厕所……

话题稍微走远了点,我们回到开源社区的技术交流中来,诚然很多很多开源社区都在使用微信社群作为日常技术沟通交流的主要方式,但是随着社群消息的不断刷屏,以及群聊消息的可折叠化,开源社区使用微信群来进行技术交流,到底是不是一个好主意?

如何吸引开源爱好者的目光呢?这里当然有很多复杂的因素,但是回归到开源的本质,我产生了一些思考:

  • 我们的技术交流够不够开放?
  • 外部的人如何能够更好地看到我们?
  • 我们如何的更好的、更高效的传递技术内容?


针对以上问题和朋友们聊了聊,查阅了一些资料后,我认为不妨可以试试使用邮件列表,来为开源社区的发展助力,也让技术的交流更加公开且透明。


什么是邮件列表


我们分别浅看下 WIKI 和度娘对这一词条的解读:


以下来自 WIKI:

邮件列表又称邮寄清单、邮递论坛、邮寄列表、通信论坛或邮件论坛等(英语:Mailing list),是电子邮件服务的特殊应用,该列表可以由个人或组织运作,表中收集了用户名和电子邮件地址,由此可以将消息同时发给多位收件人。

邮件列表一般分两种:公告型和讨论型(讨论组)。公告型邮件列表被用来单向发送报纸、杂志、广告等,更接近邮件列表的最初含义,以前这些出版物都是通过邮局投递的,但是伴随着电子邮件服务的兴起,公告型邮件列表开始流行起来;讨论型邮件列表(讨论组)允许表中用户自行向列表发送消息,发送的消息会被所有成员看见。

以下来自度娘:

邮件列表(Mailing List)的起源可以追溯到1975年,是互联网上最早的社区形式之一,也是Internet上的一种重要工具,用于各种群体之间的信息交流和信息发布。

更具体的描述大家可以自行查阅,这里就不再赘述啦 😁~


微信群终究是错付了吗


这里对使用微信群进行技术交流可能会存在的问题进行了简单的分析:

  • 信息的阻塞
  • 微信沟通采用即时通信模式,这种同步沟通形式假如一方没有收到反馈,则需要持续等待下去,造成信息的阻塞;

  • 信息的撕裂
  • 新入群的人无法看到之前的聊天信息,不知道大家正在聊什么;
  • 大家的注意力不会一直放在即时聊天窗口上,如果有问题需要询问,大多会直接在群内 po 出问题,可能会打断当前群内正在进行的对话。

  • 碎片化时间沟通
  • 如果社群没有专门负责答疑的同学轮值,但提出问题的人又期望能够得到快速回复,随着等待时间增加,对社群的整体印象大打折扣,让人产生“这个社群非常不活跃”的感觉,从而可能会对产品的维护产生质疑;
  • 利用碎片化时间在微信群进行沟通,更容易让人产生急躁感,有时一言不合和可能就会在群里争吵起来,虽然围观群众都很乐意吃瓜,但是过度的争吵也会影响群氛围的和谐。


  • 信息冗杂:
  • 随着群消息不断增多,所有人被动接收所有消息,与自己相关度低的群消息渐渐变成一种负担;
  • 一些闲杂人等在群内打广告,管理员无法对他人信息进行删除或者撤回。

  • 资源消耗:
  • 同样的技术问题被一遍遍重复提问,重复解答对技术同学产生消耗;
  • 群里讨论的内容很难形成文件或文档,也无法在互联网上被搜索到,想要形成可沉淀的内容需要花大量时间去整合。

邮件列表妙在哪里


  • 异步沟通可以给大家充裕的时间:
  • 大多数人会选择在时间充裕的时候查阅邮件,或者专门留出一部分时间对邮件列表内容进行浏览;
  • 相同的内容被归类在同一话题下,有的话题可以讨论好几天或者好几周,持续保持话题热度。


  • 更优质的内容:
  • 我们在编辑/回复邮件时会更加注意措辞和用词的严谨性,对内容的质量有潜在的更高要求;
  • 邮件可以提供更丰富的内容形式,图片、视频、代码、附件等,双方对于问题可以进行更深入的交流;
  • 对不同的内容、话题进行管理,可以让界面更加整洁,整个列表内容丰富且不杂乱。


  • 更高效:
  • 邮件列表提供的检索功能,可以通过关键词快速定位到问题以及相关内容,如果问题之前被回答过,则可以快速查看解决方案;
  • 同样的问题可以整合后形成链接,直接转发给提问者,缩短解决问题的链路;
  • 邮件列表可通过类似广播的形式,将内容发给所有订阅者,关键信息不会被一条条聊天记录刷屏刷走。


  • 适用范围更广:
  • 针对国际化的长久考虑,邮件列表的适用范围更广,加入组织讨论的链路更简单;
  • 大家的讨论公开且透明,讨论内容可以形成链接在互联网上传播,吸引更多想要了解相关信息的人加入;
  • 有一些对社区好奇、又想先观望一下的人,可以通过邮件列表中的多元化内容对社区的有一个初步、快速又不乏立体的了解。

  • 信息的安全性:
  • 这的安全性指的是,订阅邮件列表的每个人都会有一份信息副本,邮件列表的每个字都通过公开的传播流程,形成永不丢失的状态。


进一步思考


以上对微信和邮件列表做了对比思考,并不是说要舍弃微信群,把用户全都转移到邮件列表场景中来

微信群自然也有微信群的优点,比如在活动运营的时候,微信群里的互动可以快速让大家参与进来,引发一波参与热潮。

但是这里考虑的是,在小热度过了以后,如何让开发者保持对开源社区、对技术的关注,而不是活动本身。

如果我们所运营的微信技术交流社群已经存在了部分上述问题,社群活跃度也有下降趋势,不妨通过邮件列表的形式,形成技术爱好者的小圈子,通过技术的交流、碰撞不断吸引更多技术爱好者加入,让每个人有真实的参与感,通过优质技术内容留住开发者的心。

一开始可能推广起来存在一定难度,面对空白的邮件列表有一种无从下手之感,但是我们已有的内容可以先行一步,沉淀下来可以为后续做好铺垫,新加入的人看到的不会是“空空如也”的邮件列表啦 😄~


如何实现邮件列表


如果我们选择添加邮件列表作为技术交流的主要阵地,那么需要考虑如下方面:


1. 邮件列表的创建


这里以 google group 为例(需要提前准备 gmail 账号):

  • 点击左上角【创建群组】,如下图:

  • 填写群组关键信息,如下图:

  • 开通组群对外权限,如下图:

  • 点击【创建群组】,成员可在后续进行添加:

  • 群组创建成功,此时你可以在“我的群组”列表中看到新创建的群组了,如下图:



  • 此时不妨发一个简单的欢迎语,迎接即将加入的新成员吧~



2. 如何引导用户订阅


关于引导用户订阅的方式,笔者暂时没有一个成功的案例可以分享给大家,不过脑海中暂时构建了几个引导思路,希望能起到抛砖引玉的效果,大家可以在后台留言,我们一起讨论 😊~

这里涉及到了几个不同的引导场景

  • “散户”开发者:这些开发者通过网络搜索,可能在渠道推文、知乎之类的问答平台看到相关的内容,我们可以在这些场景中加入邮件列表链接🔗,引导关注;

  • 已产生联系的开发者:这类开发者可能已经加入到我们的社群中,或者已经关注了我们的公众号等各种渠道,可以通过信息推送、朋友圈广告、设置技术话题讨论、有奖参与等形式引导关注;

  • 对技术感兴趣的客户:可以在产品官网首页增加订阅邮件列表入口,引导订阅;

  • 高校学生:后续如果针对高校有进一步的拓展计划,可以附着在相应的活动、培训、社区共建等形式在高校中进行引导订阅。


3. 邮件列表的后续运营

邮件列表的后续运营动作,需要有社区管理者来定期对列表内容进行维护以及资源的整合。

邮件列表社区管理者可以是固定的一个人或者是几个人,针对不同的内容板块/内容,可以有

  • 总负责人;
  • 答疑组;
  • 运营组;
  • ……

如果后续有更多的内容和栏目,则可灵活性地进行调整。


小结


Apache 软件基金会的博客对邮件列表是如此表述的:

Apache 软件基金会的所有正式的通信都通过邮件列表进行,为了解决地理位置分布在全球不同时区的问题,邮件列表可以保证良好的异步通信,几乎所有的 Apache 社区都坚持和认同这样的做法。

一件事如果没有在邮件列表中讨论过,那么它就没有发生过;

为了保证 Apache Groups 建立在透明的文化基础之上,所有的协作都需要在邮件列表中进行;

自 Apache 软件基金会成立以来,340000 多位作者撰写了 17.5 万封之多的电子邮件,涵盖了超过 7.5 万个主题,归档了 1247 份邮件列表,这些都是可以公开访问的(2018 年年初)。

可以看出,基于异步通信理性思考公开透明的电子邮件列表,是开源协作的基石。不妨我们也试一试?

参考链接

1. 为什么不应该使用QQ进行技术交流

https://blog.zhgdg.org/2013-06/anti-qq-as-tech-communication/

2. 《开源之谜》作者:适兕

https://book.douban.com/subject/35716759/

3. 词条解释:邮件列表

https://zh.m.wikipedia.org/wiki/%E9%82%AE%E4%BB%B6%E5%88%97%E8%A1%A8

https://baike.baidu.com/item/%E9%82%AE%E4%BB%B6%E5%88%97%E8%A1%A8/3242524?fr=aladdin




欢迎关注【绯绡】公众号

一起交流、进步、成长

目录
相关文章
|
2天前
|
Web App开发 小程序 JavaScript
社区每周丨基础库更新至 2.8.7及3月社区有奖活动发布
社区每周丨基础库更新至 2.8.7及3月社区有奖活动发布
38 0
|
12月前
《阿里云产品手册2022-2023 版》——钉钉会议
《阿里云产品手册2022-2023 版》——钉钉会议
|
12月前
|
架构师 NoSQL 搜索推荐
「首席架构师推荐」精选内容管理系统列表
「首席架构师推荐」精选内容管理系统列表
|
NoSQL 安全 搜索推荐
连接微信群、Slack 和 GitHub:社区开放沟通的基础设施搭建
在开源社区中,开放的一个重要意义是社区内的沟通、讨论应该是透明、包容并且方便所有成员访问的。这意味着社区中的任何人都应该能够参与讨论和决策过程,并且所有相关信息应该公开和自由地与他人共享。
276 0
|
SQL 机器学习/深度学习 JSON
钉钉/企业微信机器人:“Github触发器”与“Issue机器人”
众所周知,在Serverless领域中,触发器是FaaS必不可少的一部分;一个FaaS平台,他的触发器数量、质量以及类型,很可能会决定这个FaaS平台是否能成为“主流”平台;因为触发器不仅仅是一种功能的体现,更是解决普遍性业务诉求的一个重要途径;目前来看,各个云厂商所提供的触发器基本上都会包括API网关触发器、对象存储触发器、时间触发器等,当然也有厂商提供一定的消息触发器、日志触发器、甚至是一些SQL相关的触发器、CDN触发器等,那么在我们的实际生产生活中,这些表面上看起来“很基础”的触发器,是否可以升级成为一个有趣的“高级触发器”呢?
504 0
|
文字识别 监控 安全
《钉钉连接平台速成手册》全新发布!
钉钉连接平台,通过简单的低代码配置,帮助企业迅捷实现系统集成和连接。原本应用之间的连接需要技术人员去开发才能实现,通过连接平台,非专业技术同学也能够通过简单的低代码或者零代码的方式就实现应用互联互通,帮助企业降低集成实施的周期和成本。
《钉钉连接平台速成手册》全新发布!
|
小程序 开发者
技术沙龙|DingTalk「开发者说」—钉钉说给你听
钉钉开发者沙龙盛宴,钉钉技术人为你分享钉应用开发实战技巧、技术架构与解决方案
技术沙龙|DingTalk「开发者说」—钉钉说给你听
|
Kubernetes Cloud Native Java
Gopher China 2021 讲师专访之周正喜:首次参会分享—阿里基于 Go 的应用管理和交互引擎
Gopher China 2021 大会又准时和大家见面了, 2015年由 Go 中国社区发起的第一届 Gopher China 大会在上海成功举办,历时五年已成为国内最权威和最干货的Go大会
Gopher China 2021 讲师专访之周正喜:首次参会分享—阿里基于 Go 的应用管理和交互引擎
|
SQL 存储 人工智能
官方剧透:1.11 发版前我们偷看了 Flink 中文社区发起人的聊天记录
自 2014 年正式开源, Flink 发展非常迅速,在 GitHub 上其访问量在 Apache 项目中位居前三。去年年底 Flink Forward Asia 2019 大会公布,仅仅 2019 年一年的时间,Flink 在 GitHub 上的 star 数量就翻了一倍,Contributor 数量也呈现出持续增长的态势。
官方剧透:1.11 发版前我们偷看了 Flink 中文社区发起人的聊天记录