open-source-best-practice

open-source-best-practice copied to clipboard

思考：PR 的 review 过程中，如何证明自己的观点？

1

* 很明显的、约定的观点，需要证明吗？ * 这里，关键在于“很明显”、“约定的”这样的结论是谁下的。某个人觉得是“约定的”，不代表其他人也这么认为。那么，总是有一些公开的、公认的资料可以查询，例如：[维基百科](https://zh.wikipedia.org/wiki/Wikipedia:%E9%A6%96%E9%A1%B5)。 * 我“感觉”某个地方不对、不合适，该怎么提 PR 或者 comment？ * “感性”的回答，可能很难得出一致的讨论结果。我们需要尽可能给出“理性”的证据来证明自己的观点。 * 如何防止 review 过程中有无限的 comment 持续发生的 * 热烈讨论，不代表应该无限去讨论。因此，讨论的技巧、取舍、妥协都是需要的。

LinuxSuRen

建议：或许Review的“礼仪”部分更适合放在PR中

1

Review部分多是关于reviewer的，但利益这段更像是对PR的创建者说的。

wjsvec

* https://hacktoberfest.digitalocean.com/ * https://summerofcode.withgoogle.com/ * https://summer.iscas.ac.cn/

LinuxSuRen

适合做为 good-first-issue 的案例收集

2

## 案例1 https://github.com/kubesphere/ks-devops/pull/302 原因：首先，这个问题并不“要命”；其次，修改起来也很容易；及时修改这个PR可能不需要很长时间来做，但能把这个机会让给社区贡献者的话，意义和价值更大 另外，项目的maintainer要把自己的

LinuxSuRen

LinuxSuRen

* 看着还不错，以后可能会用到，收藏备用 * 有耳目一新的感觉，表示支持（声援） * 朋友的项目，友情支持

LinuxSuRen

参与开源，在某种程度上可以认为是在参与某种社交活动。而在涉及到人与人之间的互动，“礼仪”就会成为避不开的话题。 以 GitHub 平台为例，很多情况下，我们是通过 issue 或者 PR 来和开源项目的维护者、用户进行交流、互动。邮件，是异步沟通的一个重要工具，贡献者可以通过多种方式（包括：watch 一个开源项目、订阅 issue、订阅 PR 等）关注到某个项目。如果说，贡献者在 issue 或者 PR 时，对自己的评论内容不加思索就发出的话，可能为导致很多其他贡献者收到大量没有必要的邮件通知。 PR 是一个非常容易遗忘的地方。作为开发者，尽量避免在代码自测通过之前提交 PR，大量缺乏实际意义的提交记录会让项目维护者感觉到很疲惫。 代码强制推送带来的问题？ 持续更新中。。。

LinuxSuRen

https://github.com/firstcontributions/first-contributions/blob/master/translations/README.chs.md

LinuxSuRen

教程：如何使用日历（订阅、添加事件等）

2

考虑在不同的终端、操作系统下使用日历： * Windows * macOS * Linux 可能遇到的问题

LinuxSuRen

当社区用户提了一些 issues 后，可能长时间都没有人来响应，但有一些可能还是比较有价值的。 对 issues 响应慢，甚至石沉大海的坏处可能有： * 可能会打击贡献者的积极性 * 社区也有可能会失去某些很有价值的 issues 这些issue如果有人互动起来的话，有可能让更多的贡献者参与进来。然而对于这类issue，社区贡献者可能会感觉到很无奈，找不到很好的办法。

LinuxSuRen