# Chapter 6. 交流
将代码写清楚的能力或许是开源环境中最重要的一项技巧。从长期来看,这不仅仅取决于编程天赋。即使是优秀的程序员,如果没有好的沟通技巧,在同一时间也只能完成一件事,即使如此也很难让其他人注意。但一个糟糕的程序员如果善于交流,则可以协调并说服许多人做很多事情,对于项目的方向和动力起着重要的作用。
无论从哪个方向看,编写好代码的能力和与其他人交流的能力看起来毫不相关。编码能力和描述技术问题的能力则有一些关系,但是描述技术问题只是项目交流中很小的一部分。更重要的是移情到其读者的能力,可以像其他人那样去看待自己的文章和回复,可以让他人以同样的客观性看待自己的文章。同样重要的是发现某种媒介或交流方法不再有效,这或许是因为它并没有随用户数量的增多而扩展,然后花时间去解决它。
在理论上很明显—但因为开源软件开发环境的受众和交流机制引起的混乱,在实践中的非常困难。一个给定的想法必须在邮件列表中作为bug跟踪系统的注释或代码的说明发布出来?当在一个公共论坛回答一个问题时,应该如何假定读者的知识水平,只是为咨询问题的“读者”解答,而是为所有会看到回复的读者?如何让开发者与其他用户保持建设性的联系,而避免陷入特性请求、虚假的bug报告和一般的聊天。如何知道一个媒介达到了容量的限度,你该如何做呢?
针对这些问题的解决方案都只能是部分的,因为任何特定方案都会随项目结构的成长或变化而废弃。他们也经常是*专门的*方案,因为他们需要随机应变。所有的参与者需要意识到交流在何时,如何陷入困境,并立刻参与到解决方案中去。帮助人们完成这件事是管理开源项目的重要任务。本小节后面的部分会讨论如何引导你自己的交流,以及如何在项目中为所有人维护交流机制的优先级。[[22](#)]
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 1. 介绍
- 历史
- 现状
- 2. 起步
- 从你拥有的开始
- 选择许可证并应用
- 设置风格
- 通告
- 3. 技术基础设施
- 一个项目需要什么
- 邮件列表
- 版本控制
- Bug跟踪
- IRC / 实时聊天系统
- RSS供稿
- Wikis
- 网站
- 4. 社会和政治的基础架构
- 慈善独裁者
- 共识为基础的民主(Consensus-based Democracy)
- 写下所有的内容
- 5. 金钱
- 参与的类型
- 长期雇佣
- 作为一些个体出现,而不是一个整体
- 公开你的动机
- 钱不能让你可爱
- 契约
- 资助非编程活动
- 市场营销
- 6. 交流
- 人如其文
- 避免常见的陷阱
- 刺儿头
- 处理成长
- Bug跟踪系统中无对话
- 公开性
- 7. 打包、发布和日常开发
- 版本号
- 发布分支
- 稳定发布版本
- 打包
- 测试和发布
- 维护多发布线
- 发布和日常开发
- 8. 管理志愿者
- 从志愿者中获取最多
- 像分担技术任务一样分担管理任务
- 转化
- 提交者
- 荣誉
- 分叉
- 9. 许可证,版权和专利
- 术语
- 许可证的方面
- GPL和许可证兼容性
- 选择一个许可证
- 版权分配和所有权
- 双许可证模式
- 专利
- 深入资源
- A. 自由版本控制系统
- B. 自由Bug跟踪系统
- C. 为什么我要关注车棚的颜色?
- D. 报告bug的样例指导
- E. 版权