Google Drive
Gist
Clipboard
欢迎孵化器导师们或是踩过坑的同学们协力创作
吴晟：导师的多元化，不应该主要导师都来自项目捐赠公司，希望适当考虑非中国导师 (Justin 在邮件列表，针对 OzHera 也提出了出问题)
个人认为，有一些严重的问题是需要在导师和项目负责团队的沟通中识别并警惕的。
姜宁：突然发现这些都是负面的描述，我觉咱们需要改成正向的要求来牵引大家。
姜宁：我觉得还可以加上 一条警惕 KPI 项目。
Xuanwo 丁皓：“警惕 KPI 项目” 这样的提法感觉不太好实操，容易陷入到技术无关的攻讦里面去。我在想是否能换成更具体的，比如说社区运作不透明，外部贡献少甚至是没有，外部用户少甚至是没有，软件运行不起来等等
姜宁：KPI项目是一个概述，需要和项目leader沟通项目进基金会的目的。 如果只是到ASF镀个金的KPI任务型项目，大家就不要浪费时间，可以直接 say no。 我这边感受最深的是 Weex 项目， 刚刚进孵化器的事情有很多人，和项目聊毕业准备没有人搭理， 接着就一个个的离开，最后只能把项目关了。
Xuanwo 丁皓：明白，不过从人性角度考虑，项目 leader 在沟通项目进基金会的时候不会说自己图 KPI 来的
姜宁：这是和项目负责人面谈的时候需要提前识别的问题。
tison：最基础的，Proposal 通常需要项目负责人起草，如果草案东拼西凑，有明显虚假内容或大量市场材料，指出后还不能改正的，基本也没什么把项目进行下去的能力和决心。实话说，因为起草需要用英文，且一般 champion 会给到一些可以借鉴的 proposals，这个情况并不罕见。
Xuanwo 丁皓：我提议增加一个这个要求，并希望导师对孵化项目进行一些最基础的 check，比如说能构建，能运行。以 ozhera 为例，ozhera 历史上从来没有独立发布过版本，唯一的 1.0 是整个 mone 项目发布的，其独立性存疑。与此同时，就像我在邮件列表中反馈的那样，git clone 下来都会有报错的，所以我提议增加这个要求。
吴晟：文档应该加上编译文档，部署文档，导师应该有人进行过验证，应该加上这个重要的条件。
姜宁：这些建议已整理到Q7的回答中
It depends。参见 Q1 第 4 条，原则上不鼓励。但是如果它是基于一个或者多个开源项目的 fork 和组合，有自己独特的技术价值，仍然可以支持。
姜宁：这块如何实操是一个问题， 在孵化器的毕业标准也没有相关的定义。 这块需要Mentor对项目所在领域有比较深的认识。
Xuanwo 丁皓：沿用我对 Committer 的要求 “Make decision bravely, know when to ask for help”，实操层面上：
- 没有明显 fork 痕迹的，显然没有问题。
- 部分模块 copy 其他项目的，参考 InLong 和基金会外 Fury 的案例。
- 重度依赖其他项目的，参考 Hadoop 生态圈的早期的强绑定项目。
- 直接就是 fork 的，参考 Pekko。
这些这里就不展开了，如果对照以后还不清楚，建议是 “ask for help”。请参与过相似项目孵化或其提案讨论的导师一起 Review。吴晟：
ask for help+1， 同时项目应该能够听取 mentor 的要求。Oz 在收到 mentor 的反馈后，依然在没有改进的情况下，将一个没有认真检查的 proposal （抄袭的别人的项目名还在）发到的正式邮件列表，这明显是 Champion、项目、mentor 出现明显的理解偏差的。姜宁：开源社区反感 fork 项目的原因是这会分散有限的社区资源， 原则上基金会是不支持 fork 项目进入孵化器的。 但是由于 License 修改而由社区成员自发fork 的项目除外。
吴晟：原则上不应该鼓励接受fork。License临时变更，是一个特殊场景，目前国内应该碰到的可能性很小。因为这个必须是fork前，有大量用户，还有一批人愿意，且有能力接过来维护的。即使 Pekko，我觉得活跃度也是不大的。这个 Fork 也很难成功。
tison：同意“不鼓励 fork”，我在 “倡议：ASF 项目孵化 101” 上面评论里说的顺序也是先考虑没有 fork 的。我们应该是一个高内部认同的组织来维持品牌，不能靠底线法律，也就不太应该把精力全花在讨论怎么样的项目刚刚好擦过底线。
tison：这里我认为可以把例外情况分成两类：
- 项目核心作者（们）有丰富的开源经验。例如 Arrow 甚至是直接以 TLP 方式运作。这种开源经验是经年的且持续的，而不是刚开始或者过去好几年前曾经边缘参与过不到几个月。
- 除此以外，建议先在孵化器之外实践（ASF 的）社群理念至少数月，明确 ASF 的路径甚至开源的路径是否适合本项目。
否则看着哪哪都不对，项目负责人（因为缺少开源经验）具体 challenge 也答不上来，只是拍胸脯说我信 Apache Way，我想搞好，这个至少对 Chapiom / Mentors 是个很大的风险。
吴晟：Apache Way 对很多项目挑战非常大，甚至成熟的 Zipkin 尝试后，也因为文化差异退出。支持 <2>，至少应该看到能够公开运作的项目，而能够透明的沟通。
tison：我本想写 “独立运作数月或 1-2 年”，后来想想能独立运作数年的，其实很多早已有自己的文化的做事方式，来 ASF 容易回头退出。不过这完全是另一个 context 的事情，国内也有独立运作不错的项目，大多没想过进入 ASF。
吴晟：我觉得1年左右是一个比较好的时间。主要评估的公开沟通，如果保持的还是内部沟通，外部同步。或者没有外部参加讨论，没有公开的资料。那么基本上，这和 ASF 的期待还是很远（从社区工作模式上）
It depends。参见 Q1 第 2 条和第 3 条，项目现在状态距离毕业条件较远没有关系，只要项目负责人真诚、虚心愿意改进，项目团队有意愿和行动来遵守 ASF 的项目治理要求。
不是的，把被拒绝时指出的问题改进仍然可以再次提案
详细内容请参考 mentor 指导手册（IPMC 新项目基础实施设置指南）
吴晟：Champion 作为进入 incubator 动作的第一责任人（mentor 更多的进入后的工作），需要对项目的状态，初始社区的规模、透明度、技术架构、可能的领域机会有一个清楚的认识。我们不需要要求的一个已经成功的项目，但是版权清晰（比如这次项目的 UI 抄袭问题，实际上已经证明存在），文档清楚，尝试英语运作（ASF 要求），能够公开讨论等有明确的了解和评估。不能把这些认为，我们可以加入孵化器之后再处理。上面提到的文档明确，可编译，也应该在审查范围。
姜宁：文档内容已放到Q7里面回答。
领路人（Champion）需要扮演好项目与基金会的沟通桥梁作用。 领路人要熟知 ASF 的捐赠流程，以及 ASF 项目成熟度评估模型，领路人需要帮助项目进行一些基本的自我评估，并完成孵化提案的评审工作。由于非盈利组织的资源有限，在邀请项目 Mentor 的过程中， 领路人需要意识到充分完备的项目评估会帮助我们节省有限的孵化资源。
参考孵化器领路人的职责，结合实际案例列举了以下具体的工作内容：
这里只结合项目自身社群活跃度进行考察，对孵化项目发展密切相关的技术定位，发展战略，商业策略不在ASF孵化器的评估考察范围之内，但是作为mentor大家可以结合自身对行业的了解自行进行判断。
注：上述几点和项目社区（而非公司）的品牌建设有一定关系
姜宁：在孵化前不一定强要求
在 ASF 孵化指导中，对孵化器导师的职责 有明确的指导。分为三个层面， 面向被孵化的项目， 面向孵化器项目管理委员会 IPMC，面向相关的保荐者（Sponsor）。
保荐者选择导师来积极监督小组成员，指导被孵化项目成员按照 Apache 的方式开展工作，并向保荐者和孵化器项目管理委员会（IPMC）报告其状态。所有导师必须是 IPMC 的成员。导师在 IPMC、保荐者和指定小组成员社区方面有以下责任：
-
Any changes
Be notified of any changes
-
Mention me
Be notified of mention me
-
Unsubscribe
Subscribe