作者：Jinhai ZHOU/JinhaiZ

每个较大的开源项目都有自己的风格指南: 关于如何为该项目编写代码的一系列约定 (有时候会比较武断). 当所有代码均保持一致的风格, 在理解大型代码库时更为轻松.

“风格” 的含义涵盖范围广, 从 “变量使用驼峰格式 (camelCase)” 到 “决不使用全局变量” 再到 “决不使用异常”. 英文版项目维护的是在 Google 使用的编程风格指南. 如果你正在修改的项目源自 Google, 你可能会被引导至 英文版项目页面, 以了解项目所使用的风格.

Eric Raymond

This document describes the working basics of PC-class computers, Unix-like operating systems, and the Internet in non-technical language.

如何成为一名黑客
——Eric S. Raymond esr@thyrsus.com
Wang Dingwei wangdingwei82@gmail.com 基于 Barret 的翻译更正而成。转载请注明出处。

目录

1. 为什么会有这份文档？
2. 什么是黑客？
3. 黑客的态度
4. 黑客的基本技能
5. 提高自己在黑客圈中的地位
6. 黑客和书呆子(Nerd)的联系
7. 向黑客的格调靠拢
8. 关于黑客、开源、以及自由软件的历史
9. 其它资源
10. FAQ（常见问题解答）

How To Ask Questions The Smart Way
Eric S. Raymond, Rick Moen

翻译者：2010 by Gasolin, 2015 by Ryan Wu

在黑客的世界里，当你拋出一个技术问题时，最终是否能得到有用的回答，往往取决于你所提问和追问的方式。

作者：Simon Tatham 专业的自由软件程序员
翻译：Dasn

引言

为公众写过软件的人，大概都收到过很拙劣的bug（计算机程序代码中的错误或程序运行时的瑕疵——译者注）报告，例如：

• 在报告中说“不好用”；
• 所报告内容毫无意义；
• 在报告中用户没有提供足够的信息；
• 在报告中提供了错误信息；
• 所报告的问题是由于用户的过失而产生的；
• 所报告的问题是由于其他程序的错误而产生的；
• 所报告的问题是由于网络错误而产生的；

这便是为什么“技术支持”被认为是一件可怕的工作，因为有拙劣的bug报告需要处理。然而并不是所有的bug报告都令人生厌：我在业余时间维护自由软件，有时我会收到非常清晰、有帮助并且“有内容”的bug报告。在这里我会尽力阐明如何写一个好的bug报告。我非常希望每一个人在报告bug之前都读一下这篇短文，当然我也希望用户在给我报告bug之前已经读过这篇文章。

Software Release Practice HOWTO

Eric Steven Raymond

This HOWTO describes good release practices for Linux and other open-source projects. By following these practices, you will make it as easy as possible for users to build your code and use it, and for other developers to understand your code and cooperate with you to improve it.

This document is a must-read for novice developers. Experienced developers should review it when they are about to release a new project. It will be revised periodically to reflect the evolution of good-practice standards.