开源项目礼节

772次阅读
没有评论

Google 开发者在线课程 开始学习
开源项目礼节

以下内容来自 MDN Web Docs:https://developer.mozilla.org/zh-CN/docs/MDN/Community/Open_source_etiquette

开源项目礼节

如果你从未在开源项目(open source project,OSP)工作过,在你开始向 MDN Web 文档(或其他开源项目)贡献之前,我们推荐你阅读这篇文章。这里有一些可供实行的最佳实践,来帮助确保你和其他项目贡献者感到受重视和安心,并保持生产力。

这篇文章不会教到你所有如何为开源项目做贡献的技巧,这篇文章的目标主要是为了让你为开源项目贡献时,有一些好的出发点。

你为什么要为开源项目贡献?

当你开始向开源项目做贡献时,反思一下为什么要做这些贡献。你的回答很有可能就是“我太无聊了,想找点有工作量的事情消磨时间”,这没什么问题,但其实还可以更深一步。

下面这些理由可能会更好:

  • 我总是使用这个工具,并且找到了一个错误,或想要帮助解决它。
  • 我想帮助其他人更加顺利地使用这个工具。
  • 我想帮助其他人更加顺利地向项目做贡献。
  • 我想提升个人技能水平。
  • 我想公开展示我在大学课程中学习到的技能。
  • 我想公开展示我的技能,以便增加找到工作的机会。

有些理由是“自私自利”的——这都没什么问题。如果在花费了一些时间在免费的项目上,期待有所收获才是正道。另外,有了这些明确的贡献理由可以让你更加轻松地决定首先从什么起步。

你在项目中的存在应该是具有成效的,且不应该阻止其他具有成效的工作。

请保持礼貌和友好,避免使用煽动性或冒犯性语言

总而言之,就是”善待他人“。这是我们为任何开始做开源项目贡献的人提出的第一条建议。

善待项目中的其他贡献者,可以营造出和谐而富有成效的氛围。这包含:

  • 感谢那些帮助过你的人。
  • 在适当的时候向人们表示祝贺(例如:他们完成了第一个拉取请求(pull request),或修复了一个难度极高的 bug)。
  • 始终以尊重的态度回应他人,即使你感觉到这些问题的回答是明显的,或者询问人在重复自己的工作。
  • 试着帮助人们下次更好地工作,例如:在拉取请求审查及回答问题时,说”这是错的“或”这是所需的答案“远不如说”这样做没问题,但我觉得如果你尝试像这样做会更好,这里有一篇博文阐述了更多的想法“或”你可以在这里找到答案,也可以查看这个链接,了解更多常见问题的答案“来得有用。

你和其他贡献者在这里(或者说,应该在这里)是因为他们想为项目做出积极得贡献,但除此之外,你不能对他们作任何假设,这包括他们的:

  • 对项目的了解和构建项目用到的技术
  • 性别、性取向、年龄、语言、所在地、政治观点、宗教信仰或其他个人属性
  • 参与开源项目的经验
  • 信任
  • 期待
  • 幽默感

因此,你需要尽可能保证你所写的内容符合主题,远离具有潜在争议的题材,如宗教或政治。即使你不同意某人的观点,或不喜欢他们所做的决定,也要保持支持和尊重的态度。

并且,你要克制住任何脏话及冒犯性的语言,即使它没有明确地指向任何人。参与时不需要这样,且一些人会对此相当敏感。

需要注意的是,任何一个好的开源项目都会有相应的规则来保护它的贡献者,以避免他们在贡献时感到不自在。这在 GitHub 中往往以 CODE_OF_CONDUCT.md 文件的形式给出。

例如,MDN 的代码库受影响广泛的 Mozilla 社区参与准则的管理。通常在 MDN Web 文档库中轻微的攻击性行为(比如持续不合主题的讨论或破坏性行为,或举止粗鲁)会收到一次 repo 内的警告,然后是最后一次警告,最后就是临时或永久的封禁。更加严重的行为问题,如仇恨言论、对其他贡献成员的威胁,将不受容忍,且可能立即遭受封禁处理。

如果你收到任何令你不舒服的内容,总是可以使用行为准则(code of conduct)中提及的机制进行举报。

选择有效的贡献

想清楚你在项目中要做什么。比如,我们会有一个在贡献者任务面板上记录的一些议题(issue)列表,根据任务的种类分开显示。

你也可以通过创建拉取请求来修复在阅读 MDN 文章时一眼扫到的问题。

MDN 上的很多工作围绕于文档及示例代码的编写,不过,通过这些方式也可以作出贡献:

  • 对议题分流进行分类。
  • 修正错别字。
  • 改善语法,让页面内容更加易于理解。
  • 指导人们如何进行修复。

每个修复都是有用的,无论多么琐碎,我们都不会拒绝。尽管如此,尽量确保你的修复工作是有成效的。我们不建议做这些种类的贡献:

  • 出于自己的喜爱更新代码样式。
  • 出于自己的喜爱更新语言样式。
  • 将页面中的美式英语修改为英式英语。
  • 在没有任何问题的情况下,添加或移除一批标点符号。
  • 出于自己的偏好修改我们正在使用的测试框架。

在许多情况下,开源项目中存在的事情是有原因的。如果它有风格指南,你应该阅读;如果对某件事情是否有效有疑问,一定要先问清楚!

阅读手册

好的开源项目总会让贡献者文档随时可供查阅。对于 GitHub 项目,内容往往存在于仓库的 CONTRIBUTING.md 文件中,或者项目的 README.md 文件中。作为文档类项目,MDN content 有一个 README 文件和一整套对于网站本身的贡献者文档(请参阅为 MDN Web 文档做贡献)。

不要害怕寻求帮助,但总是尝试在提问之前,先自己寻找答案。这样可以让自己独立积累对项目的知识,而且不会给其他贡献者带来不必要的负担。

当然,文档并不总是完美的,如果某项解释很难查找,或者描述得不够出色,请提出 issue,或者创建拉取请求来尝试自己去修复它。

在哪里提问呢?

要始终弄清楚哪里是问问题的最佳地点。好的开源项目总会在它们的文档中明确指定这一点(请查看取得联系一节)。如果你想问一些普遍意义上的问题,请使用这些频道。不是所有问题都适合使用 GitHub issue,不合适的 issue 会使项目变得杂乱(请查看下述“要取得进展,不要捣乱”章节)。

要取得进展,不要捣乱

仔细思考你在项目中沟通的方式,确保它是有用的,且不会使其他贡献者的工作更加困难。提交拉取请求来修复 bug 是好事,但它们真的有用,且方便审查吗?提出 issue 和加入其他对话是好的,但你的 issue 和评论是符合主题的,还是只是徒增杂乱?

通常情况下,要:

  • 在每个议题(issue)中仅讨论一个主题,这样可以让议题集中且有效。
  • 在每个拉取请求(PR)中仅修复一个议题(issue):对你来说,这可能要多花点功夫,但审查一个明确的修复方案要容易得多。
  • 如果你有一个有用的观点,或能回答别人的问题,请向其他主题投稿。
  • 如果你不确定某样东西是否有用或有一个简单的问题,可以使用其他机制,如聊天室或论坛来提问。
  • 在提出问题之前,先阅读手册,尝试自己回答这个问题。

不要:

  • 试图同时讨论多个话题,或发表离题的评论,使问题复杂化。
  • 把多个修正塞入一个拉取请求(pull request)中,这使得审查难度增加,并引起怀疑(有些人可能试图在有效的更改中隐藏一些恶意代码)。
  • 开启很多个议题(issue),问一些含糊不清的问题。
  • 在询问之前不尝试自己解决问题。

开源项目(几乎)是民主的

开源项目是相当民主的,很多决定是投票得出的,而且只要你不妨碍其他人的贡献,可以自由地做出任何想要的贡献。

然而,有些事情将主要由一小群核心贡献者决定。你可以自由地提出反对任何决定的理由,但有时核心贡献者会做出与你的意见相反的决定,你需要尊重并接受这些决定。

了解项目中的核心贡献者是很有用的,这样你就可以知道在诸如拉取请求(pull request)或提出的议题(issue threads)中应该向谁寻求帮助。

耐心点、及时点

记住,很多人在用他们的业余时间运营于开源项目中,没有收入,且一般工作在开源项目的人都非常繁忙。如果你在等待拉取请求审查(pull request review)或问题的解答,请耐心一点。

合理的做法是等待几天,然后礼貌地与某人取得联系,询问他们是否有时间去看它。如果他们碰巧太忙,最好再等一个星期,然后再尝试跟进他们。

在一开始就苛求一些东西,如快速回复,是不合理的。

如果有人在等你为他做什么,你也应该得到同样的礼遇,但同时要尽量及时回应。如果你真的找不到时间,让他们知道,并要求维护者帮助你找到其他人来完成这个任务。

参见

 

Read More 

正文完
可以使用微信扫码关注公众号(ID:xzluomor)
post-qrcode
 
评论(没有评论)
Generated by Feedzy