给开源项目贡献代码_没有代码，您如何为开源做贡献？

给开源项目贡献代码

我最早的开源贡献可以追溯到1980年代中期，当时我们的组织首次与UseNet建立联系，在那里我们发现了贡献的代码，并分享了其开发和支持的机会。

如今，从贡献代码到制作入门视频，无穷的贡献机会。

我比指出，我们许多人谁写的代码，但不认为自己开发人员还可以将步正上方的贡献代码的整个问题，其他贡献代码 。 相反，我想提醒大家，有很多非代码方式可以为开源做出贡献，并讨论三种选择。

提交错误报告

最好将一种重要而具体的贡献描述为“不怕提交像样的错误报告”，以及与此有关的所有后果 。 有时要提交一份体面的错误报告颇具挑战性。 例如：

• 错误可能很难记录或描述。 当计算机启动时，带有各种无法识别的代码的长而复杂的消息可能会闪烁，或者屏幕上可能只是出现一些“奇怪的行为”而没有产生错误消息。
• 错误可能很难重现。 它可能仅在某些硬件/软件配置上发生，或者可能很少触发，或者确切的问题区域可能不明显。
• 一个错误可能与一个非常具体的开发环境配置有关，该配置太大，凌乱且难以共享，需要费力地创建一个精简的示例。
• 当向发行版报告错误时，维护者可能建议改为在上游提交错误，如果发行版支持的版本不是上游社区感兴趣的主要版本，则有时可能会导致大量工作。 （当发行版中提供的版本落后于官方支持的发行和开发版本时，可能会发生这种情况。）

尽管如此，我还是劝告那些可能的bug记者（包括我在内）继续努力，并设法使bug完全记录并得到认可。

一种入门方法是使用您喜欢的搜索工具查找类似的错误报告，查看其描述方式，归档位置等。 要知道的另一件事是发行版为bug报告定义的正式机制（例如， Fedora在这里 ; openSUSE在这里 ; Ubuntu在这里 ）或软件包（ LibreOffice在这里 ; Mozilla在这里 ）。

回答用户的问题

我潜伏着，偶尔参加各种邮件列表和论坛，例如Ubuntu质量控制团队和论坛 ， LinuxQuestions.org和ALSA用户的邮件列表 。 在这里，贡献可能与错误的相关性较小，而与记录复杂用例的相关性更大。 看到每个人都跳进来帮助一个人解决特定问题的感觉，对每个人来说都是一种很棒的感觉。

写关于开源

最后，另一个领域，我真的很喜欢贡献是写关于使用开放源码软件; 无论是操作指南，对特定问题的不同解决方案的比较评估，还是只是一般地探索感兴趣的领域（在我的情况下，使用开源音乐播放软件来欣赏音乐）。 类似的选择是制作教学视频。 在演示一些非常困难的桌面操作（例如使用GIMP创建醒目的徽标）的同时，很容易记录桌面 。 那些双语或多语的人也可以考虑将现有的how-to文章或视频翻译成另一种语言。

翻译自: https://opensource.com/article/19/4/contribute-without-code

给开源项目贡献代码