给开源项目贡献代码
我最早的开源贡献可以追溯到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
给开源项目贡献代码