社区
FAQ
为什么Issues使用英文？
最根本的原因：Issues使用单语言书写，方便搜索。在Issues的使用过程中，最怕遇到使用多语言的开源项目，因为当要搜索一个问题时，比如“Turms服务端的黑名单机制是如何实现的”，对于中英文双语项目，我们通常需要搜索“黑名单”与“blocklist”这两个关键词，换言之，需要搜索至少两次才能保证能搜全相关的Issues，用户搜索体验极差。而如果Issues只有英文，那用户只需搜索“blocklist”关键词。
次要原因：使用英文方便在全球开源与推广，而使用非英文语言就与我们开源的宗旨背道而驰了。
另外，我们不排斥用户使用非英语语言提Issue，只是鼓励用户多用英文。但我们回复时一定是使用英文。
为什么不建立QQ群、微信群、Slack频道或其他群？
使用各种群做Issues管理与讨论是一种非常糟糕的实践，Issues管理本来就应该优先使用GitHub的Issues板块。原因如下：
Issues板块：
- 可以针对一个问题进行集中讨论
- 方便后来的用户对各种问题进行搜寻
- 开发人员可以通过Issues做任务追踪
- 用户可以通过Issues查看各种任务的进度，公开透明
而各种群显然做不到上述功能。相反地，各种群是项目信息闭塞的表现，与开源的宗旨背道而驰。部分开源项目会故意靠阻塞信息流通，以赚取咨询费或服务费，但这就不是Turms的开源宗旨了。
在实践过程中，群甚至是视频会议更多地用于开发人员内部进行快速讨论，尤其是早期草案的讨论，但最终的讨论结果与其中涉及到的关键问题其实还是会记录在Issue或文档上，以方便用户与开发人员明白一个问题的来龙去脉。
可以提“新手问题”吗？
Turms项目中没有所谓的“新手问题”，只有“与Turms项目相关的问题”与“与Turms项目不相关的问题”。每个人在接触新领域时，都可能表现地“不是很专业”，我们作为新人更多地希望在这个领域的人多些善意，多些包容。同理地，只要是与Turms项目相关的问题，我们都会答复。并且在遇到“很基础的问题”时，我们通常想得不是“这个问题很糟糕”，而是“可不可以补充些文档，或优化下文档，给新用户多些引导”，因此用户不必担心提出所谓的“新手问题”。
另外就是态度问题，只要大家互相尊重，那什么问题都可以讨论，而提问时展示尊重有一个很简单且实用的判断方法，就是根据“一个人在提问时，展示了ta在这个问题上花了多少的时间与精力”，而不可取的常见态度有：1. 自己不读文档、不先查Issues、也不肯思考，直接开问；2. 居高临下。
当然，学习如何提问也是件很有意思的事情，具体可以参考：提问的智慧
我是否能抄袭Turms？
可以的。原因其实也很简单，Turms作者自始至终，在主观上都没打算靠Turms盈利（不管是直接盈利，还是间接盈利。当然，如果有人执意要往我银行卡上打钱也是可以的），所以即便有人抄袭，跟Turms作者也没有什么利益冲突。
而对于所谓的“名气”，我对它的理解是“它决定了哪天你死了，你能在你维护的项目/论坛里，获得多少R.I.P.留言，以在地府人气排行榜中获得更高的名次”，因此做好开源项目可能可以让开源作者积些阴德，但这好处对我来说，确实没有什么吸引力。
并且，以绝大部分“软件工程师”的真实能力，也不足以维护Turms这个项目。读者有空可以观察下一些同类开源IM项目，我每次阅读这类项目的源码，我都会感慨，“难道真有面试官看到这种系统设计水平、编码水平的代码，还会给ta面试机会吗？如果大家都是qualified的软件工程师，怎么能接受这种质量的项目？”，然后得出了一个猜想：**难道不仅有面向简历开源，还有面向下沉市场开源？**不得不佩服一些同行“遥遥领先”的“创新”意识。
因此只要你或你的团队在抄袭的时候，不要把自己低劣的代码说是Turms作者写的，我就心满意足了。
甚至，即便你抄袭Turms时，遇到了一些问题，也能在Turms Issue区提问，只要问题能满足提问的智慧，一样能获得免费的回答。甚至你还可以把我免费的回答拿去卖你的课程（确实有其他IM开源作者通过邮件咨询我IM技术方案，我免费回答，然后ta拿去卖课的）。
我是否可以不使用Turms，但同时又通过提问来免费得到IM相关的技术方案？
可以的。只要你的问题能满足提问的智慧。
这个原则其实也很简单。有工作经验的人都会有跨部门合作的经验，需要和各式各样的人打过交道。我们总会遇到一些unqualified人（专业技能、职场技能，工作态度，如责任心都unqualified的人），他们会把自己遇到的问题，不假思索地抛给别人，甚至用命令式地语气让其他部门的人帮ta解决问题。大家会如何对待这类同事？如果ta是你的下属，你会让ta通过试用期吗？
当然，也有技能专业、对自己工作认真负责，积极帮助解决其他部门同事遇到的问题，即便解决这些问题，对他的绩效没有任何的好处。因此，你一想到这个人时，你就想到“这人认真负责、做事积极，每次都靠得住”。如果是这类同事来找你帮忙，大家又会如何对待这类同事？至少对我们来说，即便帮对方，对我们的绩效没有任何好处，我们也一样愿意帮助对方解决问题，甚至主动把对方未来可能遇到的问题，都一起解决了。
开源社区也是如此，大家是否愿意在没有收益的情况下解决一个问题，有时就取决于提问方式，以及问题提出者的credit。
可以用类ChatGPT生成的回答来参与讨论吗？
ChatGPT是一个优秀的背诵者，但它对各种技术方案的分析都很天真。用ChatGPT直接参与问题的讨论只会体现出该人：对自己的发言缺乏思考，对项目缺乏负责的态度。因此我们是否回答这类回答，取决于对方去除ChatGPT回答之后的占比。
这里提一下为什么这么关注“态度”的问题。其实有过工作经验的工程师应该都有过类似的体验：自己的工作需要依靠其他组的配合，尽管某件事情在技术上很简单的事情，但由于其他组成员的工作懒散与消极配合导致这件事情一直推不动，进而导致你自己的项目举步维艰。因此在需要团队配合的项目中，自己可控的技术问题通常是最容易解决的事情，而督促各方项目组配合，并在截止日期完成工作，才是最难与最费劲的事情。
一些还没入行的工程师，会把技术当中工程师的第一生存要义，但其实负责任的态度才是在工作或社区中的第一生存要义（当然，其实一个人如果真得对项目认真负责的人，那ta的技术水平也不会差）。除了需要特定领域，对于大部分项目，大部分合格水平工程师展现出来的技术水平都大差不差，大家真正能体现出差异的，更对的是自己对一个项目是否认真负责的态度。
因此为了表现出自己负责任的态度，请不要直接使用类ChatGPT生成的回答来参与讨论。
如何判断是不是类ChatGPT回复
- 由于GPT生成的文风过于明显，通常人工直接识别即可。
- 通过Hugging Face开源的Hello-SimpleAI/chatgpt-detector-roberta来在线识别。
- 即便随着GPT发展，展现出来的文风更多。但如今预训练语言模型繁荣，各种语料库也很多，因此基于迁移学习训练一个检测GPT回复的新模型，快得话只需要1天，慢的话也就2~3天。
关于“上游优先”
开发者直接与开源社区进行互动，并在源头上解决问题的办法，被称为上游优先。
对于Turms而言，上游优先主要涉及两个方面：沟通与代码回馈。
沟通：做特性或改Bug前，最好事先在GitHub开Issue。有些特性看起来好像很常见，也容易实现，但Turms目前却没有实现，那有可能这个“看起来”简单的特性通常会涉及很多细节，比如：
- 这一个需求有其他相关需求或拓展需求吗？
- 这一个需求可以这么实现，那这类相关特性都可以这么实现吗？是需要一个个单独实现，还有该代码实现是通用的，这一个模板可以实现几乎所有相关需求？
- 不论是在单机与分布式场景都可以这么实现吗？
- 换个业务视角或技术视角，还有更优秀的设计与实现吗？
因此一个“看起来”简单的需求，其背后都可能涉及大量需求分析与技术分析，如果开发者在本地默默地就把一些特性给实现了，则在回馈代码时，还将面临上述一系列问题，而如果这时才发现实现中存在一些重大设计问题，那可能之前的一部分精力就浪费了（当然，还是有收获的，至少知道“当前这个方案还有优化空间”）。因此，开发者在面对复杂特性时，最好做好“设计可能被反复推翻”的心理准备。
为了尽量避免这种情况，开发者在设计与实现可能复杂的特性时，最好事先开一个在Issue开一个新的讨论，以尽量减少设计被推翻的次数，节约开发者的时间与精力。
注意：其实有时候就算前期设计完了，在实现的过程中又会发现更精妙的设计，越是复杂的功能，通常也伴随着更多的设计迭代。但是，这些“推翻/半推翻”级别的迭代最好在代码发布之前，就反复讨论与开发完成，而不是代码发布了才发现。
额外补充：正是因为需求的复杂性，所以Turms很多“看起来”的Issues是处于“悬而未决”的状态。Turms GitHub Issues区中，有大量Open Issues，很多特性相关的Issues只是一个种子，需要开发者自行做更细致的需求分析、设计与编码，而其中最难的通常就是需求分析，需要弄清楚“到底要做什么”，开发者既要考虑现在的需求，也得考虑未来的需求，还得防止过度设计，这也是为什么Turms文档中好几次提到类似“IM业务功能的设计与实现其实远比技术中间件的设计与实现难得多的多”。
降低自己的维护成本，方便持续性地合并上游更新。如果开发者Fork Turms项目做复杂的定制化开发，那将面临一个长期维护的问题：如果开发者想要使用上游的新代码，就需要不断地在自己的分支上做适配，而上游Turms服务端更新得越快，开发者的适配工作量就越大。甚至还有可能出现逻辑上的冲突，但开发者没意识到。
相反的，如果开发者将代码回馈给上游，那就不会出现这类问题。因为我们不仅会一起来维护这些被回馈的代码，而且在为Turms设计其他新的相关功能模块时，也会考虑这些新设计与这些被回馈的代码在设计上是否一致。
减少维护冲突，避免反复推翻本地实现。可能开发者自己在本地添加了一些新特性或者修复了一些Bugs，但都没有回馈。过一段时间之后，开发者可能会发现上游比自己实现的功能考虑得更周全且完善，一些Bugs的修复更精妙（关于Turms服务端Bugs的难度介绍，读者可以阅读关于任务难度，最终开发者不得不把自己原来做的工作全Revert，然后再重新拉去上游搭配，重头做一遍适配。这其中的工作量想想就令人感觉痛苦，开发者在本地改得越多，冲突也就可能越多。
关于想找Turms作者私聊与做定制化开发
如果读者的团队是想自己做定制化开发，可以直接看文章关于定制化开发。
如果一些用户想付费找Turms作者做定制化开发，但Turms作者一般只接受为通用需求做无偿开发（是的，一般只接受免费帮社区做开发）。其中的原因很简单，Turms作者不缺钱，即便Turms项目持续每年亏损几万人民币，我们也都能保证Turms这项目持续运营下去，因为我们从始至终压根没打算盈利。所以要么只接受用户很高的报价，高到令人难以拒绝，要么就只接受为社区做免费的开发。
因此除非您已经准备好要报一个很高的价格，否则不要尝试私聊Turms的作者帮您做定制化开发。如果您真得很想让Turms作者尽早排期完成您的需求，您可以把自己的需求描述清楚并发到Issues区，然后我们会根据需求的性价比，以及您对您自己所提需求的尊重，来进行排期。
当然，如果您甚至愿意付Turms作者很高的定制费用，那我也建议您直接考虑用商业化方案，尽管ta们的开发水平、工作态度与工作责任心大概率不如Turms作者。当然，这主要取决于您决定采取哪个国家与公司提供的解决方案。
相比于免费开发，定制开发的区别在于：
会给出完整的、阶段性的工程排期，如设计、开发、测试、交付等。
帮忙设计需求。读者可能会好奇，既然都定制了，为啥还需要Turms作者来设计需求。这其实就像是亨利福特说的“如果我问人们他们想要什么，他们会说更快的马”。用户要求的不一定是他们内心真正所需的，而时刻洞察用户真正的需求正是工程师所需的必备技能之一。
定长的工作时长保证。在这段时间里，可以做仅限于项目相关的定制化设计、开发、测试、部署、解答各种疑问等。
当然，以上的内容都是Turms作者在下班时间进行的。
如果一些用户担心因为自己没付钱，而Turms作者就会故意拖慢自己想要特性的开发与发布进度，但这也不会发生，因为Turms作者不缺钱，也没打算靠做开源盈利，因此没有故意拖慢的动机。