今日推薦開源項目：《如何寫得簡明易懂 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://openingsource.org/2579/
加入我們：https://openingsource.org/about/join/
關注我們：https://openingsource.org/about/love/
