如何向开源社区提问题

如何向开源社区提问题

使用软件产品，或多或少都会遇到问题。对于商业产品，咱们能够咨询客服寻求帮助。对于公司本身研发的产品，咱们能够直接请教专家同事。但对于开源软件，在遇到问题时，如何才能及时有效地寻求帮助呢？

本文以开源类库 SeaJS 为例，说说我心目中的最佳实践。

提问前

遇到问题时，内心都很着急。在决定向开源社区提交问题前，最好先作作如下功课：

尝试从官方文档中找到答案

确保本身阅读过至少一次官方文档。这样在遇到问题时，若是能回忆起只言片语，就能够再去读一遍相关文档，问题每每也就解决了。

Google 是你的朋友

对于成熟的开源项目，你遇到的问题，极可能别人也遇到过。这时经过 Google、StackOverflow 等网站的搜索服务，能够帮你快速定位并解决问题。永远记住，地球上的你并不孤单，包括你遇到的问题。

挖掘 Bug 宝藏

开源软件通常都会有本身的 Bug 管理方案，好比 WebKit、V八、jQuery、SeaJS 等等。从它们的官网上找到 Bug 管理地址，而后经过搜索看看有无你遇到的问题。对于活跃社区来讲，这一招常常很管用。好比 jQuery 的 Bug Tracker，经过右上角的 Search Tickets 能够找到很是多有用的信息。一个运做良好的 Bug 库，常常是一座巨大的宝藏。SeaJS 是直接经过 GitHub Issues 来管理，你能够在 Issues 中找到不少信息。

求助身边的朋友

若是你使用的开源软件，在朋友圈或同事圈里也有人使用，那么抬起你的脚、或拿起你的电话，真挚诚恳的探讨不会遭遇拒绝，而会增进友谊。不要犹豫，你的心里渴望面对面交流，你的朋友也是。

若是以上 4 步都没法解决你遇到的问题，也别犹豫，立马向开源社区提交问题就好。

提问时

提问有不少种，好比你认识做者，直接面对面请教就行。下面探讨的是如何经过互联网的方式来问问题。

平和对等的心态

不少开源软件都是免费的，做者每每是业余时间出于兴趣在维护，没有义务回答社区问题。提问时，不要把本身摆在顾客的位置，好比

项目立刻要上线了，请务必帮忙解决
这是个人邮箱，请及时联系我

另外，也不要把本身摆在乞食者的位置，好比

冰天雪地跪求解答
救命啊，个人网站挂了

在开源社区，一切皆是朋友。不管对方是 Linux 内核的做者，仍是某个 jQuery 插件的做者，你和做者都是对等的。你的提问是在帮助开源软件完善。平和对等的心态，可让你的问题赢得更多人的阅读和思考。

经过正确的途径提交

若是遇到问题的开源软件有专门的 Bug 管理系统，请最好到这些指定系统中提交。好比，对于前端开发工程师来讲，下面这些 Tracker 系统很重要。

• jQuery Tickets
• WebKit Bugzilla
• Mozilla Bugzilla

还有各个开源类库的 Issues 库，好比 SeaJS 的是：seajs/issues

最很差的途径是

• QQ 、阿里旺旺、微信等群组。这些群组主要是用来工做或休闲的。对开源项目来讲，在这些地方提问，做者通常不会关注，效率很是低。
• 微博、Facebook 等社交网络。很多人在微博上经过 at 或私信询问 SeaJS 问题，这些我常常看不到。看到了，也不情愿回复。微博是扯淡、交流情感的地方，通常是写代码写累了，才去逛逛，不多会有在社交网络上回答技术问题的心情。

经过正确的途径提交问题，通常可让你的问题获得及时准确的回复。

使用明确、有意义的标题

抱着平和对等的心态，找到合适的途径后，就得静下心来将遇到的问题写成文字。书写文字不是一件简单的事情，咱们能够从遵循一些简单的规则开始。

首先是标题要简洁清晰，要言之有物。好比

我遇到了一个 Ajax 问题
SeaJS 在个人浏览器上运行不了

上面的标题很糟糕，光看标题做者没法知道发生了什么事。当开源社区的问题不少时，上面这类标题，常常会让做者直接忽视或将优先级降到很低。更稳当的标题是

Ajax 请求未返回正确的 responseXML
SeaJS 2.0 在 IE6 上运行时抛错

明确、有意义的标题，能够帮助做者肯定问题具体是什么类型、预估须要多少时间解决、是否如今立刻解决等。一个好的标题，也有利于社区知识的沉淀和后期搜索。标题有如一我的的颜面衣着，虽然不是关键，但在嘈杂的信息社区中，这很重要。

遵循良好的模板

若是社区提供了问题模板，必定要仔细看下。好比 Google Code 社区，当你建立一个问题时，会自动提供如下模板：

What steps will reproduce the problem?
该问题的重现步骤是什么？
1.
2.
3.

What is the expected output? What do you see instead?
你期待的结果是什么？实际看到的又是什么？


What version of the product are you using? On what operating system?
你正在使用产品的哪一个版本？在什么操做系统上？


Please provide any additional information below.
若是有的话，请在下面提供更多信息。


遵循这个模板去描述问题，常常能省不少事。做者通常也很是欢迎经过模板提交的问题。若是社区没有提供模板，也能够本身遵循以上模板来提交。

下面针对问题内容，具体说说一些须要注意的点。

语法正确、格式清晰

虽然咱们不是做家，但正确的语法、清晰的格式，可让读者赏心悦目，也就更有心情帮你一块儿思考解决问题。

对于不少须要代码来描述的问题，要尤为注意格式，好比

seajs.use('jquery',function($){$(document).ready(function() { /* ... */ })});

可读性不如

seajs.use('jquery', function($) { $(document).ready(function() { // ... }); });

GitHub 的 Markdown 语法能够很好地支持代码排版、语法高亮等，建议书写代码时，必定要先阅读下说明：GitHub Flavored Markdown。这能让你的内容看起来很专业，社区也就更有意愿会去帮助你，不然糟糕的排版，常常带来的是发帖以后的石沉大海。

描述事实、而不是猜想

事实是指，依次进行了哪些操做、产生了怎样的结果。好比

我在 Windows XP 下用 IE6 打开 seajs.org 后，点击“5 分钟上手 SeaJS”，这时浏览器弹出脚本错误提示，例子显示不正确。

上面是一段比较好的事实描述（更好的是把错误提示也截图上来），而不要像下面这样猜想：

SeaJS 在 IE6 下运行不正常，我怀疑是源码第 213 行有问题。

上面的描述，会让做者一头雾水、甚至很恼火。尽可能避免猜想性描述，除非你能先描述事实，在事实描述清楚以后，再给出合理的猜想是欢迎的。

对于前端项目来讲，若是能提供可重现错误的在线可访问代码，那是最好不过的。一旦你这么用心去作了，做者每每也会很用心地立马帮你解决。

描述目标、而不是过程

常常会有这种状况，提问者在脑壳里有个更高层次的目标，他们在自觉得能达到目标的特定道路上卡住了，而后跑来问该怎么走。好比

SeaJS 的 parseMap 方法在遇到 map 的多个配置项同时匹配同一个路径时，应该容许用户指定是所有生效仍是仅第一个匹配的配置项生效。

上面这个问题的背后，提问者实际上想解决的是如何经过 SeaJS 来作版本管理。提问者选择了经过 map 的方式来实现，但这过程当中遇到了问题，所以跑过来继续怎么走。然而，若是只是描述过程，每每会把做者也绕进去。

实际状况倒是，提问者选择的路自己就是一条崎岖之路，对于要解决的问题，实际上有更好的方式。这种状况下，描述清楚目标，讲清楚要干什么很是重要。

在描述本身是怎么作以前，必定要先描述要作什么。提问题时，What 每每比 How 更重要。

要有具体场景

不管在开源社区，仍是微博、知乎等平台上，有一种很是常见的问题：

如何维护 JavaScript 代码？
如何使用 SeaJS 进行模块化开发？

这类问题还有不少，往往遇到，只能笑笑，而后悄悄地忽略掉。所以这类问题很难回答，就以下面这些问题同样：

如何才能让生命有意义？
如何战胜淘宝？

这类提问者，通常比较浮躁，常常对问题自己也没有通过思考。踏实的提问者，不会让问题浮在空中没法回答，而会在具体场景中让问题落地：

个人项目有 20 多个 JS 文件，接下来还会急剧增长。目前遇到如下问题……（省略五百字）…… 请问如何维护？

仔细检查、确保准确

是人都会犯错误，特别是在如此快节奏的互联网环境下。好不容易把问题描述清楚时，不要急着马上提交。在提交前，至少保证从头至尾再仔细阅读一遍，好比语法错误、错别字、标点符号、排版等等。作到这些，不光是尊重别人，也是尊重本身。

提问后

提交问题后，建议经过邮件等方式订阅回复。互联网上最有效的沟通方式是异步沟通，不要期待做者立刻回复，也不要心烦意乱着急地等待。出去看看天，数数云朵，你会逐步明白什么是风轻云淡。

尽量补充信息

在接收到回复时，仔细阅读。最常常的状况是，社区回复的，常常不是你想要的。好比

根据你的描述，问题没法重现。可否提供具体使用环境和重现步骤？

这时要淡定。仔细看看本身提交的问题描述是否足够清晰，若是有可补充的信息，尽可能补充，以帮助做者能尽快定位问题。好比

很抱歉，我前面有一步描述不正确，实际状况是我是在 IETester 中运行的……

谦和淡定的交流，不光能帮助你解决问题，还有助于你结交更多朋友。

适当的总结

当问题终于解决时，建议对问题进行总结。能够编辑原帖，也能够经过博客等方式总结。你的总结，会让遇到一样问题的朋友们受益，而且对本身的技能也是一种提升。前端业界，不管国内仍是国外，有不少牛人之因此成为牛人，很大程度上都是由于有总结思考的好习惯。

不要忘记感谢

最后，记得感谢。不少开源软件的做者，都是利用业余时间在创做代码。你的感谢，聚集许许多多你们的感谢，会让开源社区充满爱与力量。

延伸阅读

• 如何有效地报告 Bug
• 提问的智慧
• 回答的智慧

---

最后的最后，若是你承认这篇文章，欢迎以各类形式转载。你的传播，能让整个开源社区更美好。

 

原文地址：https://github.com/seajs/seajs/issues/545