如何向开源社区提问题

如何向开源社区提问题使用软件产品,或多或少都会遇到问题。对于商业产品,我们可以咨询客服寻求帮助。对于公司自己研发的产品,我们可以直接请教专家同事。但对于开源软件,在遇到问题时,如何才能及时有效地寻求帮助呢? SeaJS 为例,说说我心目中的最佳实践。提问前遇到问题时,心里都很着急。在决定向开源社区提交问题前,最好先做做以下功课:尝试从官方文档中找到答案确保自己阅读过至少一次官方文档。这样在遇到问题时,如果能回忆起只言片语,就可以再去读一遍相关文档,问题往往也就解决了。Google 是你的朋友对于成熟的开源项目,你遇到的问题,很可能别人也遇到过。这时通过 Google、StackOverflow 等网站的搜索服务,可以帮你快速定位并解决问题。永远记住,地球上的你并不孤单,包括你遇到的问题。挖掘 Bug 宝藏开源软件一般都会有自己的 Bug 管理方案,比如 WebKit、V8、jQuery、SeaJS 等等。从它们的官网上找到 Bug 管理地址,然后通过搜索看看有无你遇到的问题。对于活跃社区来说,这一招经常很管用。比如 jQuery 的 Bug Tracker,通过右上角的 Search Tickets 可以找到非常多有用的信息。一个运作良好的 Bug 库,经常是一座巨大的宝藏。SeaJS 是直接通过 GitHub Issues 来管理,你可以在 Issues 中找到很多信息。求助身边的朋友如果你使用的开源软件,在朋友圈或同事圈里也有人使用,那么抬起你的脚、或拿起你的电话,真挚诚恳的探讨不会遭遇拒绝,而会增进友谊。不要犹豫,你的内心渴望面对面交流,你的朋友也是。如果以上 4 步都无法解决你遇到的问题,也别犹豫,立马向开源社区提交问题就好。提问时平和对等的心态

项目马上要上线了,请务必帮忙解决
这是我的邮箱,请及时联系我

另外,也不要把自己摆在乞食者的位置,比如

冰天雪地跪求解答
救命啊,我的网站挂了

通过正确的途径提交如果遇到问题的开源软件有专门的 Bug 管理系统,请最好到这些指定系统中提交。比如,对于前端开发工程师来说,下面这些 Tracker 系统很重要。
  • jQuery Tickets
  • WebKit Bugzilla
  • Mozilla Bugzilla
  • 还有各个开源类库的 Issues 库,比如 SeaJS 的是:seajs/issues最不好的途径是
  • 微博、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 的多个配置项同时匹配同一个路径时,应该允许用户指定是全部生效还是仅第一个匹配的配置项生效。

    实际情况却是,提问者选择的路本身就是一条崎岖之路,对于要解决的问题,实际上有更好的方式。这种情况下,描述清楚目标,讲清楚要干什么非常重要。在描述自己是怎么做之前,一定要先描述要做什么。提问题时,What 往往比 How 更重要。要有具体场景无论在开源社区,还是微博、知乎等平台上,有一种非常常见的问题:

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

    这类问题还有很多,每每遇到,只能笑笑,然后悄悄地忽略掉。因此这类问题很难回答,就如下面这些问题一样:

    如何才能让生命有意义?
    如何打败淘宝?

    这类提问者,一般比较浮躁,经常对问题本身也没有经过思考。踏实的提问者,不会让问题浮在空中无法回答,而会在具体场景中让问题落地:

    我的项目有 20 多个 JS 文件,接下来还会急剧增加。目前遇到以下问题……(省略五百字)…… 请问如何维护?

    仔细检查、确保准确是人都会犯错误,特别是在如此快节奏的互联网环境下。好不容易把问题描述清楚时,不要急着立刻提交。在提交前,至少保证从头到尾再仔细阅读一遍,比如语法错误、错别字、标点符号、排版等等。做到这些,不光是尊重别人,也是尊重自己。提问后尽可能补充信息在接收到回复时,仔细阅读。最经常的情况是,社区回复的,经常不是你想要的。比如

    根据你的描述,问题无法重现。能否提供具体使用环境和重现步骤?

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

    谦和淡定的交流,不光能帮助你解决问题,还有助于你结交更多朋友。适当的总结不要忘记感谢延伸阅读
  • 如何有效地报告 Bug
  • 提问的智慧
  •  

    相关内容推荐