新手也能做出简单但有意义的贡献吗？一些非常规建议 #hacktoberfest

将 `brew docs` 作为 `open https://docs.brew.sh` 的别名 #13834

你好，人类👋🏻

所以你想为开源项目做贡献吗？太棒了。

听起来是不是压力很大？这也很正常。

Hacktoberfest旨在降低一些门槛，但它不可能完全消除门槛。因此，我认为分享一些关于如何做出更简单但更有意义的贡献的指导可能会有所帮助。

在我们开始之前

请记住，我在这里提出的只是我个人的建议。一些聪明人可能会持不同意见。这就是为什么我的建议末尾会加星号*的原因。

实际上，我的指导大多是伪装成提问的形式。目的是引导你提出更好的问题。如果你觉得我的答案有用，我很高兴。如果你认真思考后找到了不同的答案，我也很高兴，并向你表示祝贺。

那么，我们先不谈编程。

不要只关注技术方面。

这里有很多关于各种主题的好文章，例如#github #hacktoberfest #typescript #beginners #html #css #react #vue #kotlin #swift #golang

技术固然重要，但以我的经验来看，它并非全部。我在一篇我个人非常喜欢、也略显怪异的文章中谈到了另一个方面：参与开源项目就像跳探戈。

正如我在帖子中所说，当你上舞蹈课时，总会遇到一个奇怪的时刻，老师会说出这样的话：

女士们先生们，现在
请从这些陌生人中挑选一位舞伴
，然后亲密地共舞吧！🕺🏻💃

这本身就很尴尬。有些人试图通过只和同一个舞伴跳舞来规避这个问题。但这根本无法避免。你必须学会​​如何才能做得更好。

秘诀在于培养同理心。

那么，如何培养同理心呢？

我花了很长时间才培养出自己的同理心，直到我发现了一个小秘密：

体验舞伴的双重角色
。当你开始学习探戈这类社交舞蹈时，如果你是男性，你很可能学会了如何扮演领导者的角色；如果你是女性，你很可能学会了如何扮演追随者的角色。体验这两种角色之间微妙的差别，会让你发生奇妙的改变。通过感受同一场舞蹈的两种角色，你必然会对舞蹈有更深刻的理解。同时，你也会更容易与舞伴产生共鸣。

这个比喻很明显：如果你只是维护者或贡献者，你就无法真正理解开源软件。

所以这是一个长期计划，但短期内你真的应该专注于与维护者建立人际关系。

参与开源项目就像跳探戈

让-米歇尔 🕵🏻‍♂️ 法亚德 ・ 2019 年 10 月 11 日

#hacktoberfest #开源 # 茶水间闲聊 #动力

这就引出了我的下一个观点。

不要发送拉取请求*

什么？Hacktoberfest 的全部意义不就是要提交 4 个（？）pull request 吗？

算是，也不算是。这四个 PR 是一种游戏化策略，旨在引导你学习如何为开源项目做贡献。真正的目标是让你更擅长为开源项目做贡献。

如果你和开源维护者交谈，他们可能会告诉你，当一个贡献者怀着美好的愿望，独自在地下室里长时间地进行修改，直到 PR 最终完美无缺时，他们会感到很遗憾！

可惜事情并没有那么简单：

• 维护者可能最近生活非常忙碌，比如刚生了第一个孩子。
• 维护者实际上并不维护这个代码库，因为我们每个人都有太多旧项目需要处理，根本没时间去完成它们。
• 维护者可能几个月前就修复了这个问题，花费了大量精力去修复它。问题只是在另一个分支上。
• 维护者可能会觉得你的 PR 背后有一个正确的想法，但你不知道的是，其实有一个简单十倍的解决方案可以解决这个问题。
• 而 Git 就是 Git，总是碍事。

这就是为什么参与开源项目有时会让人感到如此沮丧的原因。对所有参与者来说都是如此。

幸运的是，有一个简单的解决方法。

永远不要直接向一个陌生项目提交 PR，即使项目来自陌生人。
你应该先创建一个 issue，解释你为什么认为某个地方需要改进，然后让维护者告诉你这是否合理，如果合理，他们会指导你如何以最简单的方式进行改进。

请再读一遍，这才是让你的贡献更简单、更有意义的关键。

我可以分享我最简单也最有意义的贡献作为例子：

我在这里注意到一个很小的细节，但它可能是一个真正有意义的改进。我本来可以提交一个 pull request，但我没有。

相反，我运用了“从为什么开始”的原则。

从“为什么”开始

我为能参与到这个精彩的Homebrew项目中感到非常自豪。你会发现它很简单。而这正是我要说的重点。它如此简单真是太好了。

一切都始于一个问题：

将 `brew docs` 作为 `open https://docs.brew.sh` 的别名 #13834

jmfayard 发布了2022年9月9日

请提供所提议功能的详细描述

brew docs作为快捷方式open https://docs.brew.sh

另外，更新 brew help

$ brew help
（……）
更多帮助：
  brew 命令
  brew help [命令]
  酿造
-   https://docs.brew.sh 
+ brew 文档

推出此功能的动机是什么？

懒惰是程序员的三大美德之一，这是 Larry Wall 的定义。

懒惰这种品质会让你竭尽全力减少整体能源消耗。它会让你编写省力程序，供他人使用，并记录你编写的内容，这样你就不用回答那么多相关问题了。

该功能如何才能与至少 90% 的 Homebrew 用户相关？

用户收益

它让 90% 的 Homebrew 用户更容易访问https://docs.brew.sh上的文档。

或许还能找到他们需要的信息，那就太好了。

维护者的益处

对于 Homebrew 的维护者来说，Homebrew 用户能够自行查找所需文档，这多少算是一件好事。他们不必重复编写太多内容。

当然，很多用户仍然不会阅读文档，但现在维护者可以回复了。

这在$ brew docs[此处应填写章节编号]部分有详细记录。Common Issues

这种回复能让用户下次更有可能阅读文档。没错，它只是提醒用户“请阅读手册”，但我希望它是那种鼓励用户“阅读友好手册”的“请阅读手册”，而不是那种“请阅读该死的手册”的“请阅读手册”。

文档编写者的益处

作为一名技术文档编写者，我知道这是一项艰苦的工作，我也知道当更多的用户真正使用文档并从中受益时，我会感到非常高兴。

考虑过哪些替代功能？

已将https://docs.brew.sh添加到书签

但我太懒了，懒得把东西添加到书签，也懒得正确使用浏览器书签。

在 GitHub 上查看

我在这里不仅提出了一项功能请求，还非常清楚地解释了我想要这项功能的动机。那就是：懒惰，这是人之常情之一。

接下来发生的事情简直太棒了。Hombrew项目负责人MikeMcQuaid立即回复了我们。

我非常欣赏并赞同这种坦诚承认自己懒惰的做法。考虑到实现这个功能所需的代码量如此之少，我肯定会审核相关的 PR。

不久之后，一些比我更精通Homebrew的聪明人立刻提出了多种解决方案。我很庆幸自己没有说出我脑海中的那个方案，否则可能会引发完全不同的讨论。

一旦建立了这种联系，我就完全准备好亲自实现这个 PR 了。结果证明，我甚至都不需要这么做，因为Try MacCabe 很快就把它处理得比我做得更好。

我现在用的是我的MacBook Pro，它brew docs完全按照我的预期运行。

那么我们从中能学到什么呢？

我们了解到，重要的是专注和沟通，
而不是努力的多少。

这就引出了我的下一个观点，一个可能存在争议的观点。

不要学习git命令行界面*

许多聪明人坚信gitCLI 是一切的基础，你绝对应该花大量时间去钻研它，并在不可避免地犯错时从 Stack Overflow 复制粘贴答案。

告诉你，如果你git mess --up经常这样做，也不要感到压力。即使是拥有多年 Git 经验的人，也仍然会git mess --up定期执行一些操作。

我不是说他们错了，我是说我把注意力放在了其他事情上。

我专注于学习这些概念。

因此，关键在于什么能帮助人们学习这些概念，什么又会阻碍他们学习。在我看来，Git CLI 的复杂性是学习的一大障碍。我相信应该让简单的操作变得容易，并帮助开发者避免犯错。

与你可能想的不同，这并非图形用户界面（GUI）应用程序与终端应用程序之争。
如果你喜欢终端，我推荐使用GitHub CLI和/或LazyGit。
如果你喜欢图形用户界面应用程序，我推荐GitHub Desktop，或者我个人认为IntelliJ、WebStorm、PHPStorm、RubyMine、PyCharm 等软件中出色的 Git 集成。

所有这些 Git 应用在设计时都以简洁易用为原则。它们将帮助你专注于最重要的事情：学习概念。

学习 Git 概念，而不是命令。

Nico Riedmann ・ 2019年6月2日

#git #教程 #初学者 #学习

再次声明，这只是我个人的建议，并非适用于所有人。如果你是一位资深的 C 程序员，从事类似 Linux 内核项目（特别是 Bazaar 风格）的项目，那么 Git 命令行工具是最佳选择，因为它正是为他们而设计的。

现在来说说真正重要的事情。

帮助维护人员从新手的角度看待问题

“真正的发现之旅不在于寻找新的风景，而在于拥有新的视角。”——马塞尔·普鲁斯特

查看一个开源项目的代码库，它有成百上千次的提交，并且已经存在了好几年，这让人感到非常畏惧。

你可能想知道，自己究竟该如何做出有意义的贡献？

这是一个很好的问题，感谢你的提问。

事实证明，从维护者的角度来看，有些事情对我们来说真的很难。我们知道人们对我们项目的第一印象至关重要。问题在于，我们并不擅长察觉这类问题。我们对自己的项目了解得太深，知道太多细节，以至于很难设身处地地站在初次接触项目的人的角度去看待它。

事实证明，在这方面你比我们强得多。

你绝对想不到，只有极少数用户有勇气给我们提供这种反馈。

所以我的建议是：

• 选择一个你喜欢的开源项目，并且该项目的目标受众似乎是你。
• 试着像一个新用户那样去体验一下这个项目，你只有有限的时间来评估它。
• 创建一个 issue（参见之前），告诉维护者你刚刚试用了这个项目，你对 xxx 和 yyy 印象深刻，但另一方面，你对其他一些方面有一些比较基础的问题。他们会很乐意收到详细的反馈吗？

如果你尝试了，请告诉我结果如何。

结论

我从来没有什么有趣的结论可以得出，今天也不例外。

另一方面，我有个请求。我知道我应该把文章分享到社交媒体上，让更多人看到并受益。但我不太擅长社交媒体。所以，如果您喜欢这篇文章，而且您也熟悉推特、Reddit 等平台，如果您能帮我分享一下，我将不胜感激。