关于开源那些事儿(1-3)

关于如何做一名优秀的开源贡献者,GitHub 官方发布过一篇指南《How to Contribute to Open Source》,它会给每一个新注册的用户推送这篇文章。以下内容就参考该文章,简单阐述为什么要参与开源,为什么要读源码,为什么有人热衷于读源码等一系列问题。

本篇主要讲述:如何在开源社区进行有效的提问?

当你在开源社区抛出一个技术问题时,最终是否会有人会给你做出回答,往往取决于你所提问的方式。不仅仅是开源社区,现在社群交流软件层出不穷,无论是生活中还是工作中遇到问题,大家都可以在网络上寻求他人的帮助。在社群交流中,有一部分人对那些提出问题的“新手”表现得更友好一些,但是大部分人并不屑于回答一些“基础”的问题,他们认为那些问题“通过你自身就能解决掉,要么稍微看一下技术文档,那么在搜索引擎上面搜索一下,就能找到答案”,如果你问出了一个“很基础的问题”,那么你就要做好没有人会有兴致给你解惑的准备。

大部分的技术大佬都喜欢富有挑战性的问题,或者能激发他们思维的“好问题”,如果你给了他们一个值得反复咀嚼思考的问题,那么他们会很感兴趣,并且对你感激不尽。好问题可以提高他们对项目的理解,好问题会暴露他们以前从没意识到或思考过的问题。

如果一个问题是你:不愿意思考,或者在提问之前没有尝试过其他的努力。那么就不要怪其他人藐视你的问题。对于其他人来说,一个不愿意自己思考,不愿意付出努力解决问题的人,是一个只想索取,从不付出的人,和那样的人交流只会浪费他们的时间(因为一个问题之后肯定会有另一个问题,他们不会自己思考,在解决完他们遇到的麻烦之前,他们会提出所有遇到的问题,一旦你对他们的一个问题作出解答,他们就会不断私信你接下来的另一个问题,直到你解决完他遇到的麻烦,如果下一次他们遇到了问题,也会直接私信你,他们乐此不疲,直到你回复他们并解决完他们遇到的麻烦,他们才会停止发送私信。),从而消耗他们用在其他有趣的问题和更值得回答的人身上的时间。

因为在参与开源项目的人中,大多数都只是想使用开源软件,他们对技术细节没有兴趣,对于他们而言,电脑只是工具,他们有自己更重要的事情去做,所以针对这些人员,一般情况下提出的问题都不会有什么可探讨的深度,开源社区的回复准则是:那些真正对此有兴趣并愿意主动参与解决问题的人。这是开源社区回答问题的准则,因为那些参与回答问题的人,大部分都是自愿的,从繁忙的生活中抽出问题解答疑惑,经常会被各种提问光顾,所以他们都会过滤掉一些意义不大的问题,特别是那些不愿意自己思考的懒惰家伙。

如果你觉得一个开源社区“过于冷血无情”,那么不妨思索一下自己在解决问题的过程中是否做出过努力。他们只帮助那些愿意自助的人。无知没有关系,但装白痴就是不行。

所以,你不必在技术上很在行才能吸引其他人的注意,但你必须表现出能引导你变得在行的特质 — 机敏、有想法、善于观察、乐于主动参与解决问题。如果你做不到这些,我们建议你花点钱找家商业公司签个技术支持服务合同,而不是要求开源社区个人用户无偿地帮助你。

提问之前:

一:需要做的准备:

  1. 尝试在你准备提问的论坛的旧文章中搜索答案。
  2. 尝试上网搜索以找到答案。
  3. 尝试阅读手册以找到答案。
  4. 尝试阅读常见问题文件以找到答案。
  5. 尝试自己检查或试验以找到答案。
  6. 向你身边的强者朋友打听以找到答案。
  7. 如果你是程序开发者,请尝试阅读源代码以找到答案。

当你提出问题的时候,请先表明你已经做出来诸如上述内容的努力,让其他开发者知道,你不是一个不劳而获浪费他人时间的乞讨者。

二:准备好你的问题

在你点击提交按钮之前,请先将所有的问题都思考一遍,因为草率的提问只能得到草率的回答,或者根本不会有人愿意花费自己的时间去给你回答问题,越能表现出你在寻求帮助前为解决问题所付出的努力,你就越可能得到实质性的帮助。

三:不要自认为可以得到答案

绝对不能自以为够格从其他人那里得到答案,你没有为这种服务支付任何报酬,你需要靠你自己去获取一个答案,靠提出一个有内涵,有趣,有思维激励作用的问题。

另一方面,表明你愿意在找答案的过程中做点什么,比如:谁能给点提示?我的这个例子里缺了什么?以及我应该检查什么地方请把我需要的确切的过程贴出来更容易得到答复。因为你表现出只要有人给你指个正确的方向,你就有完成它的能力和决心。

在这里推荐一个开源社区:Stack Exchange ;以下是最常用的几个站:

  • Super User 是问一些通用的电脑问题,如果你的问题跟代码或是写程序无关,只是一些网络连线之类的,请到这里。
  • Stack Overflow 是问写程序有关的问题。
  • Server Fault 是问服务器和网管相关的问题。

近年来,开源社区已经成为回答技术和其他问题的主要渠道,尤其是那些开放源码的项目。

四:千万不要选错提问的场合,不同的项目组不要混淆,千万不要在其他项目组下面提问另一个项目中碰到的哪怕是类似的问题。

最典型的错误之一是在某种致力于跨平台可移植的语言、套件或工具的论坛中提关于 Unix 或 Windows 操作系统程序界面的问题。如果你不明白为什么这是大错,最好在搞清楚这之间差异之前什么也别问。

绝大多数人都会剔除掉那些搞不清场合并且很愚蠢的问题。在提问之前你应该知道,自己凭什么要让其他人花费自己的宝贵时间去给你解答问题。

五:不要乱发私信

开源的项目组意味着每个人都可能留下了自己的邮箱或者其他联系方式,给他人发私信提问题是不礼貌的。向陌生的人或论坛发送邮件最可能是风险最大的事情。举例来说,别假设一个提供丰富内容的网页的作者会想充当你的免费顾问。不要对你的问题是否会受到欢迎做太乐观的估计 — 如果你不确定,那就向别处发送,或者压根别发。

六:精确地描述问题

  • 仔细、清楚地描述你的问题或 Bug 的症状。
  • 描述问题发生的环境(机器配置、操作系统、应用程序、以及相关的信息),提供经销商的发行版和版本号(如:Fedora Core 4Slackware 9.1等)。
  • 描述在提问前你是怎样去研究和理解这个问题的。
  • 描述在提问前为确定问题而采取的诊断步骤。
  • 描述最近做过什么可能相关的硬件或软件变更。
  • 尽可能的提供一个可以重现这个问题的可控环境的方法。

尽量揣测其他开发者会如何提问,在你提问之前预先将开发者们可能遇到的问题回答一遍。以上几点中,当你报告的是你认为可能在代码中的问题时,给开发者们一个可以重现你问题的环境尤其重要。当你这么做时,你得到有效的回答的机会和速度都会大大的提升。

七:别动辄声称找到了 Bug

当你在使用软件中遇到问题,除非你非常、非常的有根据,不要动辄声称找到了 Bug。提示:除非你能提供解决问题的源代码补丁,或者提供回归测试来表明前一版本中行为不正确,否则你都多半不够完全确信。这同样适用在网页和文件,如果你(声称)发现了文件的Bug,你应该能提供相应位置的修正或替代文件。

请记得,还有许多其它使用者没遇到你发现的问题,否则你在阅读文件或搜索网页时就应该发现了。这也意味着很有可能是你弄错了而不是软件本身有问题。

编写软件的人总是非常辛苦地使它尽可能完美。如果你声称找到了 Bug,也就是在质疑他们的能力,即使你是对的,也有可能会冒犯到其中某部分人。当你在标题中嚷嚷着有Bug时,这尤其严重。

提问时,即使你私下非常确信已经发现一个真正的 Bug,最好写得像是做错了什么。如果真的有 Bug,你会在回复中看到这点。这样做的话,如果真有 Bug,维护者就会向你道歉,这总比你惹恼别人然后欠别人一个道歉要好一点。

八:描述问题症状而非你的猜测

告诉其他人你认为……或者说你猜测……并不会给其他人带来什么帮助,如果你的推断如此有效,还用向别人求助吗?,因此要确信你原原本本告诉了他们问题的症状,而不是你的解释和理论;让其他人来推测和诊断。如果你认为陈述自己的猜测很重要,清楚地说明这只是你的猜测,并描述为什么它们不起作用。

例子:

蠢问题

我在编译内核时接连遇到 SIG11 错误, 我怀疑某条飞线搭在主板的走线上了,这种情况应该怎样检查最好?

聪明问题

我的组装电脑是 FIC-PA2007 主机板搭载 AMD K6/233 CPU(威盛 Apollo VP2 芯片组), 256MB Corsair PC133 SDRAM 内存,在编译内核时,从开机 20 分钟以后就频频产生 SIG11 错误, 但是在头 20 分钟内从没发生过相同的问题。重新启动也没有用,但是关机一晚上就又能工作 20 分钟。 所有内存都换过了,没有效果。相关部分的标准编译记录如下…。

九:描述目标而不是过程

如果你想弄清楚如何做某事(而不是报告一个 Bug),在开头就描述你的目标,然后才陈述重现你所卡住的特定步骤。

经常寻求技术帮助的人在心中有个更高层次的目标,而他们在自以为能达到目标的特定道路上被卡住了,然后跑来问该怎么走,但没有意识到这条路本身就有问题。结果要费很大的劲才能搞定。

蠢问题

我怎样才能从某绘图程序的颜色选择器中取得十六进制的的 RGB 值?

聪明问题

我正试着用替换一幅图片的色码(color table)成自己选定的色码,我现在知道的唯一方法是编辑每个色码区块(table slot), 但却无法从某绘图程序的颜色选择器取得十六进制的的 RGB 值。

第二种提问法比较聪明,你可能得到像是建议采用另一个更合适的工具的回复。

十:询问有关代码的问题时

别要求他人帮你调试有问题的代码,不提示一下应该从何入手。张贴几百行的代码,然后说一声:它不能工作会让你完全被忽略。只贴几十行代码,然后说一句:在第七行以后,我期待它显示 <x>,但实际出现的是 <y>比较有可能让你得到回应。

最有效描述程序问题的方法是提供最精简的 Bug 展示测试用例(bug-demonstrating test case)。什么是最精简的测试用例?那是问题的缩影;一小个程序片段能刚好展示出程序的异常行为,而不包含其他令人分散注意力的内容。怎么制作最精简的测试用例?如果你知道哪一行或哪一段代码会造成异常的行为,复制下来并加入足够重现这个状况的代码(例如,足以让这段代码能被编译/直译/被应用程序处理)。如果你无法将问题缩减到一个特定区块,就复制一份代码并移除不影响产生问题行为的部分。总之,测试用例越小越好。

一般而言,要得到一段相当精简的测试用例并不太容易,但永远先尝试这样做的是种好习惯。这种方式可以帮助你了解如何自行解决这个问题 —— 而且即使你的尝试不成功,开发者们也会看到你在尝试取得答案的过程中付出了努力,这可以让他们更愿意与你合作。

如果你只是想让别人帮忙审查一下代码,在信的开头就要说出来,并且一定要提到你认为哪一部分特别需要关注以及为什么。

十一:去掉无意义的提问句

避免用无意义的话结束提问,例如有人能帮我吗?或者这有答案吗?或者 在吗?和你好?。

首先:如果你对问题的描述不是很好,这样问更是画蛇添足。

其次:由于这样问是画蛇添足,其他人会很厌烦你 —— 而且通常会用逻辑上正确,但毫无意义的回答来表示他们的蔑视, 例如:没错,有人能帮你或者不,没答案

一般来说,避免用 是或否对或错有或没有类型的问句,除非你想得到是或否类型的回答。

十二:即使你很急也不要在标题写紧急

这是你的问题,不是我们的。宣称紧急极有可能事与愿违:大多数开发者会直接删除无礼和自私地企图即时引起关注的问题。更严重的是,紧急这个字(或是其他企图引起关注的标题)通常会被垃圾信过滤器过滤掉 —— 你希望能看到你问题的人可能永远也看不到。

有半个例外的情况是,如果你是在一些很高调的地方,也许值得这样去做。在这种情况下,如果你有时间压力,也很有礼貌地提到这点,人们也许会有兴趣回答。

当然,这风险很大,因为开发者们兴奋的点多半与你的不同。譬如从 NASA 国际空间站(International Space Station)发这样的标题没有问题,但用自我感觉良好的慈善行为或政治原因发肯定不行。事实上,张贴诸如紧急:帮我救救这个毛绒绒的小海豹!肯定让你被开发者们忽略或惹恼他们,即使他们认为毛绒绒的小海豹很重要。

十三:礼多人不怪,有礼貌会对你有所帮助

彬彬有礼,多用谢谢您的关注,或谢谢你的关照。让大家都知道你对他们花时间免费提供帮助心存感激。

坦白说,这一点并没有比清晰、正确、精准并合法语法和避免使用专用格式重要(也不能取而代之)。开发者们一般宁可读有点唐突但技术上鲜明的 Bug 报告,而不是那种有礼但含糊的报告。(如果这点让你不解,记住我们是按问题能教给我们什么来评价问题的价值的)

然而,如果你有一串的问题待解决,客气一点肯定会增加你得到有用回应的机会。

十四:问题解决后,加个简短的补充说明

问题解决后,向所有帮助过你的人发个说明,让他们知道问题是怎样解决的,并再一次向他们表示感谢。如果问题在新闻组或者邮件列表中引起了广泛关注,应该在那里贴一个说明比较恰当。

最理想的方式是向最初提问的话题回复此消息,并在标题中包含已修正已解决或其它同等含义的明显标记。在人来人往的邮件列表里,一个看见讨论串问题 X问题 X - 已解决的潜在回复者就明白不用再浪费时间了(除非他个人觉得问题 X的有趣),因此可以利用此时间去解决其它问题。

补充说明不必很长或是很深入;简单的一句你好,原来是网线出了问题!谢谢大家 – Bill比什么也不说要来的好。事实上,除非结论真的很有技术含量,否则简短可爱的小结比长篇大论更好。说明问题是怎样解决的,但大可不必将解决问题的过程复述一遍。

对于有深度的问题,张贴调试记录的摘要是有帮助的。描述问题的最终状态,说明是什么解决了问题,在此之后才指明可以避免的盲点。避免盲点的部分应放在正确的解决方案和其它总结材料之后,而不要将此信息搞成侦探推理小说。列出那些帮助过你的名字,会让你交到更多朋友。

除了有礼貌和有内涵以外,这种类型的补充也有助于他人在邮件列表/新闻群组/论坛中搜索到真正解决你问题的方案,让他们也从中受益。

至少,这种补充有助于让每位参与协助的人因问题的解决而从中得到满足感。如果你自己不是技术专家或者开发人员,那就相信我们,这种感觉对于那些你向他们求助的大师或者专家而言,是非常重要的。问题悬而未决会让人灰心;开发者们渴望看到问题被解决。好人有好报,满足他们的渴望,你会在下次提问时尝到甜头。

思考一下怎样才能避免他人将来也遇到类似的问题,写一份文件或加个常见问题会不会有帮助。如果是的话就将它们发给维护者。

十五:如果其他人回复了,但是你看不懂

如果你看不懂回应,别立刻要求对方解释。像你以前试着自己解决问题时那样(利用手册,常见问题,网络,身边的高手),先试着去搞懂他的回应。如果你真的需要对方解释,记得表现出你已经从中学到了点什么。

比方说,如果我回答你:看来似乎是 zentry 卡住了;你应该先清除它。,然后,这是一个很糟的后续问题回应:zentry 是什么? 的问法应该是这样:哦~~~我看过说明了但是只有 -z 和 -p 两个参数中提到了 zentries,而且还都没有清楚的解释如何清除它。你是指这两个中的哪一个吗?还是我看漏了什么?

以上就是在开源社区中进行提问需要注意的地方,下面有一些常见的例子:

以下是几个经典蠢问题,以及开发者们没回答时心中所想的:

问题:我能在哪找到 X 程序或 X 资源?

问题:我怎样用 X 做 Y?

问题:如何设定我的 shell 提示?

问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

问题:我的程序/设定/SQL 语句没有用

问题:我的 Windows 电脑有问题,你能帮我吗?

问题:我的程序不会动了,我认为系统工具 X 有问题

问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

问题:我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢?


问题:我能在哪找到 X 程序或 X 资源?

回答:就在我找到它的地方啊,白痴 —— 搜索引擎的那一头。天哪!难道还有人不会用 Google/Baidu 吗?

问题:我怎样用 X 做 Y?

回答:如果你想解决的是 Y ,提问时别给出可能并不恰当的方法。这种问题说明提问者不但对 X 完全无知,也对 Y 要解决的问题糊涂,还被特定形势禁锢了思维。最好忽略这种人,等他们把问题搞清楚了再说。

问题:如何设定我的 shell 提示??

回答:如果你有足够的智慧提这个问题,你也该有足够的智慧去 RTFM,然后自己去找出来。

问题:我可以用 Bass-o-matic 文件转换工具将 AcmeCorp 档案转换为 TeX 格式吗?

回答:试试看就知道了。如果你试过,你既知道了答案,就不用浪费我的时间了。

问题:我的{程序/设定/SQL 语句}不工作

回答:这不算是问题吧,我对要我问你二十个问题才找得出你真正问题的问题没兴趣 —— 我有更有意思的事要做呢。在看到这类问题的时候,我的反应通常不外如下三种

  • 你还有什么要补充的吗?
  • 真糟糕,希望你能搞定。
  • 这关我有什么屁事?

问题:我的 Windows 电脑有问题,你能帮我吗?

回答:能啊,扔掉微软的垃圾,换个像 Linux 或 BSD 的开源操作系统吧。

注意:如果程序有官方版 Windows 或者与 Windows 有互动(如 Samba),你可以问与 Windows 相关的问题, 只是别对问题是由 Windows 操作系统而不是程序本身造成的回复感到惊讶, 因为 Windows 一般来说实在太烂,这种说法通常都是对的。

问题:.我的程序不会动了,我认为系统工具 X 有问题

回答:你完全有可能是第一个注意到被成千上万用户反复使用的系统调用与函数库档案有明显缺陷的人,更有可能的是你完全没有根据。不同凡响的说法需要不同凡响的证据,当你这样声称时,你必须有清楚而详尽的缺陷说明文件作后盾。

问题:我在安装 Linux(或者 X )时有问题,你能帮我吗?

回答:不能,我只有亲自在你的电脑上动手才能找到毛病。还是去找你当地的 Linux 使用群组者寻求实际的指导吧。

注意:如果安装问题与某 Linux 的发行版有关,在它的邮件列表、论坛或本地使用者群组中提问也许是恰当的。此时,应描述问题的准确细节。在此之前,先用 Linux 和所有被怀疑的硬件作关键词仔细搜索。

问题:我怎么才能破解 root 帐号/窃取 OP 特权/读别人的邮件呢?

回答:想要这样做,说明了你是个卑鄙小人;想找个黑客帮你,说明你是个白痴!

 

本文来自投稿,不代表微擎百科立场,如若转载,请注明出处:https://www.w7.wiki/code/2329.html

发表评论

登录后才能评论