# 转化
一次又一次,某个位置上承担责任的志愿者(例如补丁管理员,翻译管理员等)无法执行该位置的责任。这可能是因为出现了超出他预期的工作,或者完全因为是许多外部因素:结婚、孩子出世、新的老板等等之类的。
当一个志愿者陷入这种境地,他通常不会立刻注意到。可能以很小的程度发生着变化,而且没有一个时刻可以自觉的认识到他已经无法完成这个角色的任务。相反,项目中的其他部分只是发现有一段时间未能听到他的消息了。然后他们会会立刻匆忙行动,而他则觉得长时间对项目的怠慢是有愧的,并立刻连夜赶工。然后就有更长的一段时间你无法听到他的消息,然后可能是或可能不是另一场慌乱。但是,很少有主动提出的正式辞职。志愿者用自己的业余时间工作,辞职意味着公开承认他的业余时间被永久的减少了。人们通常不愿意这样做。
因而,需要你和项目中的其他人发现发生的事情—或者说发现没有发生—,并能够询问哪个志愿者可以继续。这种询问必须是友好和100%无内疚的。你的目的只是找出真相,而不是让人难过。通常情况下,这个询问应当对项目的其他人可见,但是如果你知道一些必须私下进行的原因,也没有问题。公开进行的主要原因是如果志愿者回复说无法完成工作时,就可以为你的*下一次*公开发布提供一个上下文环境:请求一个新的志愿者完成该角色。
有时,一个志愿者无法完成其接受的工作,但是没有意识到或不希望承认这个事实。当然,任何人在一开始都会遇到困难,特别是当责任很复杂时。然而,如果某人不努力完成他接受的任务,即使所有人都给出全部的帮助和建议,最后唯一的解决方法只能是他放弃并让其他人来尝试。而且如果这个人没能看到这一点,需要有人告诉他。基本上来讲,我认为只有一种处理方法,但是需要一个多步骤的过程,每个步骤都很重要。
首先,确保你自己没有发疯。在私下与项目的其他人讨论,看看他们是不是和你一样认为问题很严重。即使你们已经肯定,这样也实现了让其他人知晓你们正考虑让这个人退出的目的。通常不会有人反对—他们会很高兴你肩负这个尴尬的任务,这样他们就不必动手了!
下一步,*私下*联系有问题的志愿者并友好和直接的告知他,你所发现的问题。为了效果,要尽可能提供多的实例。确保能够指出人们是如何不愿继续帮助的,而问题一直存在得不到改善。请确保花较长的时间编写该邮件,对于此类邮件,如果你无法支持你所说的,最好就什么都不要说。要说明你会找一个新的志愿者充当这个角色,但也要指出有许多方法可以支持这个项目。在这个阶段,不要说你已经为此与其他人进行了谈话;没有人希望被告知有人在准备接替他。
之后,可以有许多其他不同的方法。最可能的反应是他们可能会认可你,或者在某种程度上会争论,并愿意退出。如果是这个情况,建议他自己作出声明,然后你可以跟从他的文章寻找一个替代者。
或者,他可能认可自己的问题,但是请求多一点的时间(或者再多一次机会,例如离散任务角色的发布管理员)。如何响应这个情况需要您的判断,但是无论您如何做,不要仅仅因为感到无法拒绝这种请求而表示同意。这样会延续痛苦,但不会有所减轻。这通常是拒绝这种请求的好原因,换句话说就是已经给了足够多的机会,而现在就是得到的结果。这是我告知某人无法肩负发布管理员角色的邮件:
~~~
>如果您希望别人替代我,我会有好的将这个角色交给下个人。我有个
>不情之请。我希望再尝试一次发布来证明我。
>
我完全能够体会您的想法,但是在这种情况下 ,我们无法“再试一次”。
这不是第一次或第二次发布,而是第6或第7次... 我知道你也对结果
不够满意(因为我们之前已经讨论过)。所以我们已经有效的完成了
再次尝试的程序。最终,总有一次是最后一次... 我认为[上一次发布]就是
了。
~~~
在最坏的情况下,志愿者可能完全不同意。然后你需要接受事情变得尴尬并预先准备。现在是与其他人讨论此事了(但在得到他们的允许前,还是不能说是谁,因为这些对话是机密的)的时候了,也是你认为项目不应该这样继续下去的时候了。坚持,但不要威胁。请注意,大多数角色的转换可能始于某个新人已经开始了它的工作,而*不是*老人结束了他的工作。例如,如果争论事关角色,譬如说问题管理员,在任何时刻你和其他有影响的人可以请求一个新的问题管理员。可以不必是之前做这些事的人停止了工作,只要他没有妨害(故意或其他原因)新志愿者的努力。
有一个充满诱惑力的想法:为何不去尝试不必告知人们辞职,而仅仅是为他寻找一些帮助?为什么不可以有两个问题管理员、补丁管理员或任何角色?
尽管理论上听起来很不错,但通常不是一个好方法。是什么让管理员角色可以工作—是什么使之发挥作用,实际上—应该是非集中化。能够以非集中式完成的工作通常已经这样做了。有两个人肩负管理员角色会带来两个人的交流负担,也可能会带来不可靠的互相依赖(“我以为你带了急救箱!” “我?我以为*你*带了急救箱”)。当然,也有例外。有时两个人可以配合的极好,或者任务本身就可以轻松的分散给多个人。但当你见到某人挣扎于某个他不适合的角色时,通常并不会起太大作用。如果他一开始就能够重视这些问题,之前就会寻求此类帮助。在任何情况下,让一个人持续做一件不会让人关注的事情都是失礼的。
让某个人隐退的重要因素是隐私:给他空间作出决定,而不要让他感觉大家都在关注和等待。我曾经犯过这种错误—非常明显的错误,回想起来—也就是同时向所有的三方当事人发送邮件,征求Subversion发布管理员,接替另外两个志愿者。我已经与两个人私下有所交流,也知道他们希望肩负这个责任。所以我认为,有些天真有些迟钝,通过向他们同时发送邮件开始了转换过程,省去了时间和争辩。我设想现在的发布管理员已经完全意识到了问题,也会立刻理解我的用意。
我错了。当前的发布管理员被冒犯了,完完全全的冒犯了。被人要求交出工作是一回事,而在*大庭广众*之下被要求交出工作则是另外一回事。当我意识到我的行为有些冒犯,我做出了道歉。他最终有礼貌的退出,并继续参与这个项目。但是他的感情受到了伤害,无需再说,对新志愿者来说也不是一个吉利的开始。
- 前言
- 为什么写这本书?
- 谁应该读本书?
- 资料来源
- 致谢
- 免责声明
- 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. 版权