为什么你不该用微信进行主题讨论？
小编的话：本文约 3600 字，阅读时间约 5 分钟。
你在微信群里参加了一门课程，课后你在群内向老师请教问题，正当老师回答时，一个红包甩进来，群内一阵哄抢，老师的回答旋即被各种通知消息和感谢表情淹没，你只能刷聊天记录寻找回答。
虽觉得无奈与麻烦，但似乎也没更好的方法，长此以往，你渐渐习惯，参与的热情退却，提问少了，讨论少了，却没注意到——微信这样的即时通讯工具不适合进行主题讨论。原因是1）易撕裂讨论思索；2）无法理性有效沟通；3）数据易丢失。
那么，有没有更好的办法？有！且听 Python 中文社区联合创始人 Zoom.Quiet 的建议。
本文改编自 Zoom.Quiet 《为什么不应该使用QQ进行技术交流》 ：
简单说三点就足以明白，为什么你不应该通过即时通讯工具进行主题讨论。
同步 vs 异步
微信也好， QQ 也罢，以及消亡的 ICQ/MSN 等，都是一种 IM (Instant Messaging，即时通讯)工具。 IM 沟通很类似我们平常面对面交谈，容易为广大网友接受，成为好像主流的在线沟通形式。
IM 这种同步(synchronization)沟通形式，在软件工程学中属于阻塞式工作模式：一方发出的信息，必须等待另一方反馈后，才能继续通讯。也就是说，双方在没有相互明确彼此意思前，谈话是被阻塞的，只能进行多次反复确认，才能继续。
而在技术交流中，动辄有上千人注册的社区，技术讨论参与者不可能仅仅两人。如果你想在微信群中讨论某一技术问题，并达成共识决议，几乎不可能。
原因是 IM 要求双方同时在线，才可能跟上讨论的进展。如果有部分人不在线，或是注意力不在聊天窗口，那么就只能出声问，或是翻阅聊天历史来掌握进展。可惜，多数人是直接询问，从而撕裂其他人的交流。讨论线索被「自然」撕裂的几率，通常随着 IM 群组人数增加而急剧增加，直到所有人都搞不清现在在讨论什么。
工程师们的沟通形式则多是异步(asynchronization)沟通：GitHub Issues（议题）或邮件列表。其中，使用 GitHub Issues（议题）好处多多。
你可以在 GitHub 建立 Issues 展开讨论、驱动协同、分类标签、设定里程碑、指派分工、全文检索，还可以 close 过期或完结议题、保持主版面清爽，需要时还可以 re-open ……
你还可以在网页自由回复参与 Issues 讨论，在方便的时候专心查阅 Issue 自动触发的邮件，逐一回复其他人提出的问题。如果你已有邮件列表，还可以设置 Issues 更新自动发送到邮件列表。
最重要的是：所有人的意见或见解，都可以通过 GitHub Issues 页面或邮件追查、对比、反复理解，任何中途介入的人，也都可以通过 Issues 页面全面客观的知晓所有人的观点。再复杂的技术问题，通过 GitHub Issues 都可以优雅地、非时间强占式地，达成共识。
综上，同步交流最后多是趋向比谁刷屏刷的快，谁用的字体或表情亮瞎人的眼。但异步交流的 Issues 或邮件列表，则永远是有道理的、能解决问题的见解或代码获得认可。
形式决定内容
IM 的聊天记录只能由群成员查阅，而 GitHub Issues 或邮件列表 ，则可以自动完成公开的发布和归档。
这意味着，任何人都可以轻易的搜索出历史上任何人、任何时候发送的任何一则公开的 GitHub Issues 或邮件列表内容。
同时也意味着，在这种形式的讨论中，你的任何情绪化言论将永久性的归档在一个技术问题线索中，可能在未来任何时间点上被搜索出来，成为你专业经历中一处不洁数据。
比如： 就是 Linux 创始人 Linus 在 13 年前的一场讨论中的邮件原文，里面有一句技术著名宣言： Talk is cheap. Show me the code. 能侃不算什么，有本事把代码拿出来看看。
GitHub Issues 或邮件列表的形式，可潜移默化地让所有明白这种交流形式真实意义的人，在任何一次回应中，都趋向于越来越理性、中立和认真，绝不不懂装懂。毎一次回应，都尽可能将问题描述完备，说明清楚 5W1H：
who 谁，或 什么目标用户
When 何时，或 什么期限
Where 何地，或 什么场景/过程中
What 何解，或 前后文，具体的条件
Why 为何，或 具体的业务要求
How 如何，或 进行过怎样的尝试
你必须提供尽可能多的信息，以便他人复现问题才能给出确切的建议。也因为将问题描述明确如此简单又复杂，所以，发源自邮件列表的异步交流文化，甚至产生了类似《提问的智慧》这种详细指导新人的手册，让新人更易从容友好地进行交流。
数据安全
硬件不可靠，系统不可靠，网络不可靠，软件不可靠。但凡是人制造的东西，都不是 100% 可靠。
IM 群（例如微信及 QQ 群）的交流，当然也基于各种不可靠的东西之上。所有人的发言，通过 IM 公司的服务器集群进行中转、广播，以及暂存，一旦服务器发生什么意外，消息丢失了，IM 公司不承诺找回，损失的后果就只能自己承担，到时就算你哭天喊地也无法找回了。
GitHub Issues 或邮件列表则不同，信息进行分发时，所有相关人员的私人邮箱都有了一份信息副本；同时，服务系统自动完成了一份归档文本；再同时，搜索引擎自动抓取到了归档文本，分散存储到了全球无数主机中；再再同时，如果我们使用 Google 邮件列表沟通的话，那每封邮件自动完成三份相同的备份分散到全球数据中心中。即，邮件列表中毎一个字都永不丢失。
小结
综上，在技术或多数主题讨论场景，基于 GitHub Issues 或邮件列表公开沟通能令公众持续受益。
如果有可能，强烈建议你尝试 GitHub Issues 或邮件列表这样的异步沟通方式，而不是 IM 群中断断续续，难以追踪的沟通。
——- 广告时间 -——
那么，如何进入主题异步讨论环境?
综上，各种 IM 群不存在良好的主题讨论条件，那么你在学习过程中想跟同道中人交流怎么办？简单的方法是找到对应的社区列表订阅。
不知道哪儿有列表的话，可以尝试加入开智学堂课程，开智学堂所有课程都是使用 Issues 来进行主题异步交流，是你体验异步沟通乐趣，深入主题学习的好选择。
12 月下旬，开智学堂 Python 基础班三期开课，通过此课程，你将
掌握 Python 基础语法，明确 Python 新手到专家的进阶路线图；
获得一个自主开发的 Python 项目，比如原创微信后台；
能够自如地进行网络数据抓取，操作常见数据库；
搭建个人学习网站，持续记录你的学习心得；
认识一大群爱学习的互联网圈小伙伴；
……