一篇写给开发者的社区提问指南
全文约 4296 字，阅读需要 11 分钟
在技术社区运营过程中，每天会遇到各种各样的用户提问，我们发现其中很多提问的方式不够科学合理或者高效。特此，我们为 TDengine 用户撰写了这篇提问指南，希望能够帮助大家更科学、高效地进行交流。同时，本指南中的方法和建议也适用于绝大部分技术社区，有助于提高大家的整体提问水平。
⏱ 准备提问之前
在你准备要向 GitHub Issues、技术交流群、技术论坛中提出技术问题前，请先做到以下事情：
尝试在你准备提问的论坛的历史帖子中搜索答案。
尝试在网上搜索以找到答案。
尝试阅读官方文档以找到答案。
尝试阅读官方文档中的 FAQ 以找到答案。
尝试自己检查或试验以找到答案。
向你身边的强者朋友询问以找到答案。
如果你是程序开发者，请尝试阅读开源代码 https://github.com/taosdata/TDengine 以找到答案。
当你提出问题的时候，请先让别人看起来你已经做了上述的努力；这将有助于展示出你并不是一个不劳而获且浪费别人时间的提问者。如果你能一并展现在做了上述努力的过程中所学到的东西会更好，因为我们更乐于回答那些表现出能从答案中学习的人的问题。
准备好你的问题，再将问题仔细的思考过一遍，因为草率的发问只能得到草率的回答，或者根本得不到任何答案。越是能表现出在寻求帮助前你为解决问题所付出的努力，你越有可能得到实质性的帮助。
小心别问错了问题。如果你的问题基于错误的假设，社区里的人多半会一边在心里想着蠢问题…，一边用无意义的字面解释来答复你，希望你会从问题的回答（而非你想得到的答案）中汲取教训。
绝不要自以为够格得到答案，你没有，你并没有。毕竟你没有为这种服务支付任何报酬。你将会是自己去“挣到”一个答案，靠提出有内涵的、有趣的、有思维激励作用的问题 —— 一个有潜力能贡献社区经验的问题，而不仅仅是被动的从他人处索取知识。
另一方面，表明你愿意在找答案的过程中做点什么是一个非常好的开端。谁能给点提示？、我的这个例子里缺了什么？以及我应该检查什么地方比请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人能指个正确方向，你就有完成它的能力和决心。
📔 尝试在文档中直接找到答案
在上述“提问之前”步骤中，我们已经提到过“尝试阅读官方文档以找到答案”这一条，在此再次特别提出，因为通常学习一门技术最简单的方法就是跟着官方教程走一遍，通过官方教程理解这个产品最基本的技术概念。如果要深入理解，就需要继续研究文档。
以 TDengine 官方文档（http://docs.taosdata.com）举例，通常一份设计良好的文档中会包括如下几个部分：
教程 - 面向学习的方式
以最简单易懂的方式，让你快速了解产品的最基本用法。对应 TDengine 文档中的“立即开始”。
概念讲解 - 面向理解的方式
产品内部的核心技术理念和技术架构讲解。对应 TDengine 文档中的“数据模型”和“基本概念”。
开发指南 - 面向问题的方式
针对不同的功能主题，对具体功能进行说明介绍。对应 TDengine 文档中的 “开发指南”、“集群管理”和“运维指南”。
参考手册 - 面向信息的方式
全部语法、函数、功能、技术点的索引清单及其详细说明。对应 TDengine 文档中的“TAOS SQL”和“参考指南”。
通过以上介绍的几种不同类型的文档，你可以获取想要理解的不同知识，举例：
理解最基本的时序数据库概念：查看“基本概念”
简单体验下数据库产品：查看“立即开始”
如何进行连续查询：查看“开发指南 - 连续查询”
一个配置参数：查看“参考指南 - 配置参数”
如何查找一个聚合函数？查看“SQL 手册 - SQL 函数”
此外，千万别忘了文档有搜索功能，直接使用搜索可能是个更快的手段。
在这个技术爆炸的时代，大家要面对的技术概念非常多，不可能有任何人可以记住所有的知识点，但对一位技术人员最基本的要求是：知道技术文档的整体结构，可以以最快的速度找到对应技术所在的章节，然后再去进行检索。
🔍 通过搜索寻找答案
根据不同的情况，这里给大家介绍四种搜索技巧：
官方文档搜索
第一个方法是利用文档的基本搜索能力，在绝大多数情况下，你是可以通过文档内建的搜索功能获得自己想要的知识。
在特定页面搜索
在页面中，Windows 下使用 Ctrl+F，macOS 下使用 Cmd+F，可以直接通过浏览器内置的功能在页面中进行搜索。
Stack Overflow 搜索
Stack Overflow 社区是全球最大的技术问题社区。工作中遇到的绝大多数主流问题都可以在其网站上搜索得到。实际使用过程中，大多数开发者都是通过搜索引擎直接搜索的，往往搜索结果的前几条中，就有 stackoverflow.com 的结果存在。
国内对应的开发者社区包括：思否、掘金、CSDN、51CTO、博客园等，还有专业的技术内容平台 InfoQ 和通用性的内容平台如知乎、简书也可以搜索到一些技术文章。
搜索引擎搜索
利用搜索引擎搜索当然是你的终极武器，众所周知，对技术人员最友好的搜索引擎就是 Google，没有之一。相对于国内的某主流搜索引擎，你能搜索到更高质量的答案。使用搜索引擎的时候，大家要善用 site: 功能，针对特定网站进行搜索，比如搜索 TDengine 的文档，就需要输入：
unable to resolve FQDN site:docs.taosdata.com
如果搜索到的干扰内容比较多，可以使用 “-” 移除干扰，举例：
unable to resolve FQDN -DNS
此外，国内还存在着大量高质量的个人技术博客，这些内容在 Google 搜索中都有比较高的权重。
🙋 当你提问时
在技术交流群内亮明你的身份
即便出于纯粹的商业价值考虑，我们对企业客户也会更有兴趣。无论你是开源免费使用者，还是企业客户，亮明身份可能更有助于引发我们对你项目和问题的兴趣。
注意提问的语气和态度
在长期服务开发者的过程中，我们经常遇到如下的情况：
这是什么破玩意？怎么这么烂？给我造成了这么多麻烦？
为什么还没有人回答？人都哪儿去了？
XXX 在哪儿？谁告诉我一下？
我很着急，谁来马上回答一下！
毫无疑问没有人会欢迎这样的问题，在社区里工程师们既无责任也无义务无偿的支持你，官方运营的论坛和微信群也不是你发牢骚的场所。如果你喜欢 TDengine，好好使用它，认真反馈问题，为它的建设出力，如果不喜欢，可以转身离开；如果暂时还没有下定决心，可以保持长期关注或者和我们的团队进行良性的互动。
低声下气不能代替你的功课
有些人明白他们不该粗鲁或傲慢地提问并要求得到答复，但他们选择另一个极端 —— 低声下气：我知道我只是个可悲的新手，一个小白，但...。这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。
如果还是搞不懂
如果你看不懂回应，别立刻要求对方解释。像你以前试着自己解决问题时那样（利用手册，FAQ，网络，身边的高手），先试着去搞懂他的回应。如果你真的需要对方解释，记得表现出你已经从中学到了点什么。
比方说，如果我回答你：看来似乎是 zentry 卡住了；你应该先清除它。然后，这是一个很糟的后续问题回应：zentry 是什么？好的问法应该是这样：哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries，而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗？还是我看漏了什么？
如果得不到回答
如果仍得不到回答，请不要以为我们觉得无法帮助你。有时只是看到你问题的人不知道答案罢了。没有回应不代表你被忽视，虽然不可否认这种差别很难区分。
总的来说，简单重复地问问题是个很糟的点子。这将被视为无意义的喧闹。有点耐心，知道你问题答案的人可能生活在不同的时区，可能正在睡觉，也有可能你的问题一开始就没有组织好。
不该问的问题
问题：有大神熟悉 grafana 嘛？
回答：你的问题是什么？没有人会响应这个问题，因为你没有具体的提问。
问题：有没有 mac 版的客户端驱动啊？
回答：你有在官网产品页面、下载页面或者文档页面里寻找吗？如果寻找过了，你已经得到答案了。
问题：创建表报这个啥情况 System out of disk space？
回答：反馈错误非常明确。
问题：有没有人遇到过 Unable to resolve FQDN？
回答：搜索下即可解决，文档的 FAQ 里也有答案。
问题：请问一下，一张表不允许存在两条相同时间戳的记录吗？
回答：时序数据库的基本概念，时间戳唯一，看过文档中的基本概念了吗？
问题：老师你这边有 TDengine-flink-mysql 的案例吗？
回答：尝试搜索过“TDengine Flink MySQL”吗？如果搜索过，你能找到答案。
问题：源码没法编译。它怎么这么烂？
回答：他觉得都是别人的错，这个傲慢自大的提问者，他不受欢迎。
🌟 提交到 GitHub Issues
有一些问题并非咨询、答疑、讨论类的问题，这些问题通常非常复杂或者就是代码的 Bug，在提出的时候需要明确的上下文，复现环境和步骤，在处理过程中需要和研发人员进行深入的技术讨论。这样的问题并不适合在社区或者群里提出，而是应该提交到 GitHub Issues，并遵循 Issue 提交规范提交。
🧑💻 TDengine 的同学们在做什么努力？
没有人愿意每天回答各种重复性的问题或者反复不断的去打字，我们也一样。所以我们会尽力的持续做以下事情来优化我们的工作，让我们协助你解决问题的效率持续的提升：
针对常见的问题，不断地补充完善我们的官方文档 FAQ
每两周发布一次《TDengine 社区问题双周精选》
坚持持续迭代文档，遇到任何用户反馈文档中存在模糊和歧义的地方，我们都会及时修正
针对特定领域的问题，不定期发布各种主题技术博客
优化代码输出的错误信息，尽量提供友好和有用的反馈
不断地完善代码质量
我们也希望你能够加入到这个行列中来：
随时提出你认为的各种文档缺陷、典型问题，推动产品、文档的优化，也让后来者受益
勇敢地提出 GitHub Issues，提出 Issue，你就已经变成了开源项目的参与者
勇敢地提交 PR，以代码的形式对开源项目进行贡献，参与到项目中来，成为项目的 Contributor
💡 社区支持与企业支持的区别
以上我们严肃地讨论了社区支持的技巧和禁忌。你知道了社区支持者既不承担任何义务，也不提供任何承诺帮你解决问题。如果你觉得社区支持无法满足你对及时性、专业性、深度定制化的问题和需求，也许成为一位企业付费客户能帮你快速的解决掉大部分问题，你将得到专注的资源支持和及时的响应。但是请记住，无论免费用户还是付费客户，作为一位高素质的提问者，礼貌和尊敬都是做人的基本素养和道德准则。
欢迎向我们咨询如何成为企业付费客户，请直接在社区技术交流群里留言，会有TDengine 官方人员联系你。
进入社区技术交流群，请添加微信 tdengine 或扫描如下二维码：
结尾
本指南的最终目的并不是教人做事，也不是从支持者的角度意气地吐槽。
我们希望通过本文，能让开发者们更高效地找到问题的答案，也避免因为提出一些“小白”问题而消耗彼此的时间。
本文参考和大量引用了《提问的智慧》中的内容，地址为：https://github.com/ryanhanwu/How-To-Ask-Questions-The-Smart-Way/blob/main/README-zh_CN.md
英文原文是 Eric S. Raymond, Rick Moen 于 2001 撰写的 How To Ask Questions The Smart Way，地址为：http://www.catb.org/~esr/faqs/smart-questions.html
欢迎大家关注 TDengine 的 GitHub Repo，目前 Star 数量已经达到 18.5k：
https://github.com/taosdata/TDengine
也欢迎大家关注 TDengine 的公众号：
Developer Advocate or Developer Evangelist / 开发者布道师
Solution Architect / 解决方案架构师
Full-stack Engineer / 全栈工程师
Business Development / 生态合作经理
Pre-sales Engineer / 售前工程师