今日推荐开源项目：《如何写得简明易懂 git-style-guide》
今日推荐英文原文：《How do you contribute to open source without code?》
今日推荐开源项目：《如何写得简明易懂 git-style-guide》传送门：GitHub链接
推荐理由：在使用 Git 时会发挥作用的指南——有助于养成良好的习惯。这个项目着重于使用 Git 时应当养成的一些好习惯，这些习惯能够让你向其他人传达更清晰的信息，这在多人协作中尤其重要。它包括了如何描述分支，如何更清晰的描述提交等等，现在写的更清楚，几年之后再回来就不至于摸不着头脑了。
今日推荐英文原文：《How do you contribute to open source without code?》作者： Chris Hermansen
原文链接：https://opensource.com/article/19/4/contribute-without-code
推荐理由：一些不需要通过代码就能够帮助开源的手段
How do you contribute to open source without code?
My earliest open source contributions date back to the mid-1980s when our organization first connected to 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. Instead, I’d like to remind everyone that there are lots of non-code ways to contribute to open source 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. Sometimes it’s quite challenging to file a decent bug report. 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.)
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; openSUSE’s is here; Ubuntu’s is here) or software package (LibreOffice’s is here; Mozilla’s seems to be here).
Answering user’s questions
I lurk and occasionally participate in various mailing lists and forums, such as the Ubuntu quality control team and forums, LinuxQuestions.org, and the ALSA users’ mailing list. 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 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 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.下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/