我最早的开源贡献可以追溯到 1980 年代中期，当时我们的组织首次连接到 UseNet，我们在那里发现了贡献的代码以及分享其开发和支持的机会。
今天，有无数的贡献机会，从贡献代码到制作操作视频。
我将直接跳过贡献代码的整个问题，除了指出我们许多编写代码但不认为自己是开发人员的人仍然可以贡献代码。相反，我想提醒大家，有很多非代码方式为开源做贡献，并谈谈三种替代方案。
提交错误报告
一种重要且具体的贡献类型可以最好地描述为“不怕提交像样的错误报告”以及与之相关的所有后果。有时，提交像样的错误报告非常具有挑战性。例如
- 错误可能难以记录或描述。当计算机启动时，可能会闪过一条带有各种无法识别的代码的长而复杂的消息，或者屏幕上可能只出现一些“奇怪的行为”，而没有产生任何错误消息。
- 错误可能难以重现。它可能仅在某些硬件/软件配置上发生，或者可能很少被触发，或者精确的问题区域可能不明显。
- 错误可能与非常特定的开发环境配置相关联，该配置太大、太混乱且太复杂而无法共享，需要费力地创建精简的示例。
- 在向发行版报告错误时，维护人员可能会建议改为向上游提交错误，当发行版支持的版本不是上游社区主要关注的版本时，这有时会导致大量工作。（当发行版中提供的版本落后于官方支持的发布版本和开发版本时，可能会发生这种情况。）
尽管如此，我还是劝告有志于成为错误报告者的人（包括我）坚持不懈，努力使错误得到充分记录和确认。
入门的一种方法是使用您最喜欢的搜索工具来查找类似的错误报告，查看它们的描述方式、提交位置等等。另一个需要了解的重要事项是您的发行版（例如，Fedora 的在此处；openSUSE 的在此处；Ubuntu 的在此处）或软件包（LibreOffice 的在此处；Mozilla 的似乎在此处）定义的正式错误报告机制。
回答用户的问题
我潜伏并偶尔参与各种邮件列表和论坛，例如Ubuntu 质量控制团队和论坛、LinuxQuestions.org 和 ALSA 用户邮件列表。在这里，贡献可能与错误的关系较少，而与记录复杂用例的关系更多。看到有人挺身而出，帮助他人解决特定问题，这对于每个人来说都是一种很棒的感觉。
撰写关于开源的文章
最后，我真正喜欢贡献的另一个领域是撰写关于使用开源软件的文章；无论是操作指南、针对特定问题的不同解决方案的比较评估，还是只是大致探索感兴趣的领域（就我而言，是使用开源音乐播放软件来欣赏音乐）。类似的选项是制作教学视频；可以轻松录制桌面，同时演示一些非常棘手的桌面操作，例如使用 GIMP 创建一个引人注目的徽标。而那些会说双语或多种语言的人也可以考虑将现有的操作文章或视频翻译成另一种语言。
4 条评论