如何以非代码形式贡献开源
开源 贡献

> 
> 事实上，有无穷无尽的方法来为开源做贡献，其中一个简单的方法就是回答我们的投票问题。
> 
> 
> 


![](/data/attachment/album/202204/26/190136sd2nmv19m5vn905m.jpg)


你是如何参与开源贡献的呢？我们组织了一个投票，结果如下：


* 提交错误报告 - 67 票（35%）
* 解答用户的问题 - 39 票（20%）
* 写作（指南、故事、文档等） - 73 票（38%）
* 其他 - 12 票（6%）


我的第一次开源贡献可以追溯到 20 世纪 80 年代中期，当时我们的机构第一次连上了 [UseNet](https://en.wikipedia.org/wiki/Usenet)，在那里我们发现了贡献代码，以及在其开发和支持过程中和别人分享的机会。


在今天，我们有无尽的贡献开源的机会。无论是贡献代码，还是制作一个视频教程，都是贡献的一种途径。


不过，我将直接跳过整个贡献代码的部分。诚然，我们中有许多写代码但不认为自己是开发者的人，他们也可以 [贡献代码](https://opensource.com/article/19/2/open-science-git)。但是，我更想提醒大家，还存在很多 [非代码形式可以贡献开源](https://opensource.com/life/16/1/8-ways-contribute-open-source-without-writing-code)。接下来，我会谈到其中的三种。


### 提交错误报告


有一种重要而具体的贡献形式，它可以被描述为“不要畏惧 [提交一个像样的错误报告](https://opensource.com/article/19/3/bug-reporting)”以及 [与此相关的所有后果](https://producingoss.com/en/bug-tracker.html)。有时，要 [提交一个像样的错误报告](https://opensource.com/article/19/3/bug-reporting) 是很有挑战性的。比如说：


* 某些错误可能很难记录或描述。当计算机启动时，屏幕上可能会出现又长又复杂的信息，其中包含各种不能理解的代码。或者屏幕上可能显示有一些“异常行为”，但是却没有提供具体的错误信息。
* 某些错误可能很难重现。它可能只发生在某些特定的硬件/软件配置上，或者它可能很少被触发，或者错误的产生场景不明确。
* 某些错误可能与一个非常特殊的开发环境配置有关，但是这个配置庞杂混乱，无法分享，需要先耗费大量精力创建一个精简后的例子才行。
* 当向发行版报告一个错误时，维护者可能会建议将该错误提交给上游，这有时会需要付出大量的工作，因为发行版所提供的版本不是上游社区感兴趣的主要版本。（当发行版提供的版本落后于官方支持的发布和开发版本时，就会有这种情况发生）。


尽管如此，我还是鼓励那些潜在的错误报告者（包括我）继续努力，并尝试让错误得到完整的记录和确认。


但如何开始呢？你可以使用你最喜欢的搜索工具寻找类似的错误报告，看看它们是如何描述的，它们被归档在哪里，等等。你也可以留意你使用的发行版（例如，[Fedora](https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/)、[openSUSE](https://en.opensuse.org/openSUSE:Submitting_bug_reports)、[Ubuntu](https://help.ubuntu.com/stable/ubuntu-help/report-ubuntu-bug.html.en)）或软件包（[LibreOffice](https://wiki.documentfoundation.org/QA/BugReport)、[Mozilla](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines)）的错误报告页面，它们定义了正式的报告机制，你可以按步骤为他们报告相关错误。


### 解答用户的问题


我潜伏在各种邮件列表和 [论坛](https://ubuntuforums.org/) 里，偶尔也会冒个泡，例如 [Ubuntu 质量控制团队](https://wiki.ubuntu.com/QATeam) 和 [论坛](https://ubuntuforums.org/)、[LinuxQuestions.org](https://www.linuxquestions.org/)，以及 [ALSA 用户的邮件列表](https://www.alsa-project.org/wiki/Mailing-lists) 等。在这里，我的贡献可能与错误报告的关系不大，更多的是记录复杂的用例。不过，看到有人热心帮助他人，解决他人在某个问题上的遇到的麻烦，对每个人来说，这都是无疑一种很棒的体验。


### 从事开源相关的写作


最后，另一个我非常喜欢贡献的领域是 [撰写](https://opensource.com/users/clhermansen) 关于使用开源软件的文章。无论是使用指南，还是对某一特定问题的不同解决方案进行比较评估，或者只是笼统地探索一个感兴趣的领域（就我而言，是使用开源音乐播放软件来享受音乐）。一个类似的选择是制作一个教学视频。你很容易就可以做到边演示一些复杂的桌面操作（比如用 GIMP 创建一个绚丽的标志），边 [录制桌面](https://opensource.com/education/16/10/simplescreenrecorder-and-kazam)。而那些精通两种或多种语言的人，也可以考虑将现有的使用指南或视频翻译成另一种语言。


（LCTT 译注：读了这篇文章，你是不是想要马上投身于开源贡献呢？那么请考虑加入“Linux 中国翻译组（LCTT）”吧！我们有能帮助你快速上手翻译的 [维基](https://lctt.github.io/wiki/intro/lctt.html)，有热心友爱的 QQ 群，你甚至还能够在我们的官网上获得属于自己的译者专页……心动了吗？那就立刻行动起来吧！阅读 [维基](https://lctt.github.io/wiki/intro/lctt.html) 以了解如何加入我们。）




---


via: <https://opensource.com/article/19/4/contribute-without-code>


作者：[Chris Hermansen](https://opensource.com/users/clhermansen) 选题：[lkxed](https://github.com/lkxed) 译者：[lkxed](https://github.com/lkxed) 校对：[校对者ID](https://github.com/%E6%A0%A1%E5%AF%B9%E8%80%85ID)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
My earliest open source contributions date back to the mid-1980s when our organization first connected to [UseNet](https://en.wikipedia.org/wiki/Usenet) where we discovered the contributed code and the opportunities to share in its development and support.

Today there are endless contribution opportunities, from contributing code to making how-to videos.

I'm going to step right over the whole issue of contributing code, other than pointing out that many of us who write code but don't consider ourselves developers can still [contribute code](https://opensource.com/article/19/2/open-science-git). Instead, I'd like to remind everyone that there are lots of [non-code ways to contribute to open source](https://opensource.com/life/16/1/8-ways-contribute-open-source-without-writing-code) and talk about three alternatives.

## Filing bug reports

One important and concrete kind of contribution could best be described as "not being afraid to file a decent bug report" and [all the consequences related to that](https://producingoss.com/en/bug-tracker.html). Sometimes it's quite challenging to [file a decent bug report](https://opensource.com/article/19/3/bug-reporting). For example:

- A bug may be difficult to record or describe. A long and complicated message with all sorts of unrecognizable codes may flash by as the computer is booting, or there may just be some "odd behavior" on the screen with no error messages produced.
- A bug may be difficult to reproduce. It may occur only on certain hardware/software configurations, or it may be rarely triggered, or the precise problem area may not be apparent.
- A bug may be linked to a very specific development environment configuration that is too big, messy, and complicated to share, requiring laborious creation of a stripped-down example.
- When reporting a bug to a distro, the maintainers may suggest filing the bug upstream instead, which can sometimes lead to a lot of work when the version supported by the distro is not the primary version of interest to the upstream community. (This can happen when the version provided in the distro lags the officially supported release and development version.)

Nevertheless, I exhort would-be bug reporters (including me) to press on and try to get bugs fully recorded and acknowledged.

One way to get started is to use your favorite search tool to look for similar bug reports, see how they are described, where they are filed, and so on. Another important thing to know is the formal mechanism defined for bug reporting by your distro (for example, [Fedora's is here](https://docs.fedoraproject.org/en-US/quick-docs/howto-file-a-bug/); [openSUSE's is here](https://en.opensuse.org/openSUSE:Submitting_bug_reports); [Ubuntu's is here](https://help.ubuntu.com/stable/ubuntu-help/report-ubuntu-bug.html.en)) or software package ([LibreOffice's is here](https://wiki.documentfoundation.org/QA/BugReport); [Mozilla's seems to be here](https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writing_guidelines)).

## Answering user's questions

I lurk and occasionally participate in various mailing lists and forums, such as the [Ubuntu quality control team](https://wiki.ubuntu.com/QATeam) and [forums](https://ubuntuforums.org/), [LinuxQuestions.org](https://www.linuxquestions.org/), and the [ALSA users' mailing list](https://www.alsa-project.org/wiki/Mailing-lists). Here, the contributions may relate less to bugs and more to documenting complex use cases. It's a great feeling for everyone to see someone jumping in to help a person sort out their trouble with a particular issue.

## Writing about open source

Finally, another area where I really enjoy contributing is [ writing](https://opensource.com/users/clhermansen) about using open source software; whether it's a how-to guide, a comparative evaluation of different solutions to a particular problem, or just generally exploring an area of interest (in my case, using open source music-playing software to enjoy music). A similar option is making an instructional video; it's easy to

[record the desktop](https://opensource.com/education/16/10/simplescreenrecorder-and-kazam)while demonstrating some fiendishly difficult desktop maneuver, such as creating a splashy logo with GIMP. And those of you who are bi- or multi-lingual can also consider translating existing how-to articles or videos to another language.

## 4 Comments