ECLIPSE开源政策系列 – 21 – Eclipse项目手册

原文链接：https://www.eclipse.org/projects/handbook/

 

概览

本文为你提供创建一个新的Eclipse开源项目或成为某个已有项目的提交者所需的信息。

Eclipse开发过程(Eclipse Development Process ，EDP)是Eclipse项目和提交者的基础文档。它描述了我们处理开源软件的方式。Eclipse开发流程并未规定任何特定的开发方法论；它更关注开源项目生命周期的更多方面，包括评审、发起投票和选举的过程、为项目带来新的提交者等诸如此类的信息。本文将会详细说明Eclipse开发过程的某些关键点。

原则

Eclipse开发过程的四条核心原则包括：

● 透明度；

● 开放性；

● 优才制度；以及

● 供应商中立性；

我们将前面三条称为“开源约定准则”。

透明度指一个项目的讨论、会议纪要、审议、项目计划、新特性计划以及其它内容都是开放、公开和便于访问的。

Eclipse的开放性远超过“开放的书籍”(它是透明的同义词)所代表的含义。项目对所有人都是开放的；Eclipse向所有人提供了同样的机会。所有的参与者都需要遵守相同的规则；没有会将任何潜在的贡献者排除在外的规则，当然，也包括市场上的直接竞争者。

Eclipse遵循优才制度。谁的贡献大，谁就会承担更多的责任。如果对项目作出了一些高质量的贡献，则可能会收到邀请加入项目成为提交者。Eclipse中领导角色的选取也是基于贡献价值并需要受到同僚的一致认可。对应的贡献必须在公开可用的论坛上进行展示。提交者和项目领导通过选举来产生。

雇佣身份身份与某人是否能参与Eclipse的某个开源项目无关。雇佣并不保证提交者的身份；提交者身份必须得到所有人的认可。

供应商中立性在维持一个公平的环境方面与开放性的理念类似。我们不会允许任何供应商控制一个项目，并且凡是具有雇佣身份的人都不会被拒绝参与项目。由于项目资源中将会包含独立供应商各自主张各种资产所有权的版权声明，因此项目自身必须保持供应商中立。

品质和知识财产的洁净度也都是重要的原则。

品质意味着在整个社区范围内都可以称为高可扩展框架和示范性工具，它们都以一种开放、包容并且富有预见性的过程进行开发。从“消费角度”来看，Eclipse 品质意味着对于用户来说是良好的作品(示范性工具不仅使用起来很酷/强大，并且展现出多种可能)，对于采用者来说也已经万事俱备。从“创作角度”来看，Eclipse品质意味着采用了一个透明、开放的过程，对技术领袖的加入采取了开放和欢迎的态度，无论他们隶属的机构是什么。

知识财产(Intellectual property ，IP)是指任何可以从Eclipse服务器(包括源码管理系统、网站以及下载服务器)上获取的东西。其中包括(但不限于)源码、图片、XML和配置文件、文档等等。关于我们的知识财产管理方式和作为提交者的责任都有严格的规则。

由Eclipse项目产生的代码被众多组织用于构建产品。这些Eclipse技术的采用者需要得到一些保证来确保其产品对应的知识产权是干净的：对代码声明版权的组织或个人应该是合法的版权持有者，并且版权持有者合法地允许代码在项目使用的许可之下可用。作为一个提交者，你必须谨慎确保没有复制代码并将其不经意地声明为自己所有。

启动一个Eclipse开源项目

Eclipse开源项目的启动首先需要一个项目建议书，该提议应对整个社区都是可用的以便进行评审。在社区评审期结束后，我们需要进行一个创建评审，并且随后配置项目资源。

使用Web表单(译者注：位于https://projects.eclipse.org/create/project-proposal，需要登录后方可访问)来创建一个新的项目建议书。在表单中提供项目介绍。所有的建议书都会以草稿(draft)模式被创建，并且仅允许初始作者和在建议书中被指定为项目领导或提交者的人访问。只有被指定为项目领导的人才可以编辑建议书。

注意保存项目建议书的URL。在建议书开放给社区评审之前，我们不会提供文档的公开链接。

在我们将其开放给社区评审之前，项目建议书至少包括项目的描述，范围声明，以及未来成员清单(项目领导和提交者们)。

当你认为项目建议书已经准备好了时，请向Eclipse管理组织(Eclipse Management Organization，EMO)的邮箱emo@eclipse.org发送一个消息，告知项目建议书已经准备好公开评审了。EMO将会对项目建议书进行评审，并且可能会在启动社区评审之前给出反馈。

在社区评审阶段开始时，EMO将会在各个渠道上发布项目建议书(项目活动新闻页面、Twitter、项目建议书论坛、博客以及向Eclipse基金会成员和提交者发布email消息)。EMO将会在Eclipse基金会的问题追踪系统中打开一个记录——一个Bugzilla实例——来追踪项目建议书的评审进展；项目建议书的作者和项目领导将会被复制到对应的记录中。

项目建议书至少会开放两周以便进行社区评审。

Eclipse基金会持有所有Eclipse项目的商标。在任何新项目创建之前都需要分配商标。如果你已经有了一个基于项目名称的商标，那么该商标必须分配给Eclipse基金会。注意商标分配过程可能是一件非常耗时的事情(它可能需要几个小时、几天或者几周，这取决于项目名字相关的事宜)。如果你现在持有该商标，则将会要求你填写一个商标转移协议。

项目建议书必须列出两名从架构委员会选出的导师。架构委员会的成员具有丰富的Eclipse基金会工作经验，并且非常了解Eclipse开发过程。如果你已经与愿意帮助你的项目的导师取得了联系，请在项目建议书中列出他们。否则，EMO将会直接与架构委员会根据需要指定导师。导师会在项目的孵化阶段帮助你；他们在项目毕业后完成其使命。

如果项目名称的商标已经得到了担保，导师已经被指定完毕，并且项目建议书内容已经完成，则EMO会发起一个创建评审。该评审至少会持续一周，它每个月会有两次，一般会在每个月的第一和第三个星期三结束。创建评审可能会与社区评审阶段重叠。

创建评审一般都会成功。由于在开始评审之前很多工作都已经完成了，评审工作一般都会轻松完成。

在创建评审之后，EMO将会启动配置过程。要了解提交者状态，则在配置过程中必须完成一些提交者文书工作。文档工作的确切要求与多种因素有关，包括独立雇员状态以及Eclipse基金会雇员的成员状态。

如果你在创建评审结束时能按时完成文档工作，那么我们就可以快速地完成配置过程。当我们启动配置工作时，提交者将会收到一封介绍邮件；在收到那些介绍邮件之前请不要发送任何文档。

配置完成后

网站管理员将会发送一个通知来宣布配置过程完毕。在你提交任何代码到项目代码库之前，你必须提交项目的初始贡献以及第三方库清单以便IP组进行评审。

在其项目页面(如果有)上显示孵化标识；在得到IP组的批准前请不要向你的项目源代码库提交任何代码。一旦得到了IP组批准，你就可以为你的第一个发布构建版本并生成里程碑版本。只有IP组对你的初始贡献和第三方库的使用情况审批通过后，你才能发布正式版本。

项目阶段

所有的新项目在开始时均处于孵化阶段(在孵化阶段的项目被称为正在孵化中)。项目处于孵化阶段与项目代码品质没有太大的关系；倒不如说，由于建立项目周边的三大社区需要的开放和公开的过程(开发者、采用者、使用者)，孵化阶段更多是表示项目组正处于该实践过程之中。

为了通知潜在消费者项目处于孵化状态，在孵化状态的项目必须使用孵化商标：

● 在项目的主要下载页面上显示孵化标识；

● 在构建和里程碑版本的所有可下载文件的文件名(如果技术上可行)中包含单词“孵化(incubation)”；

● 如果技术上可行，则在功能特性中(例如：关于对话框、功能列表、安装器)也要包含单词“incubation”。

对于普通用户界面元素并没有孵化状态商标要求。

对于产生OSGi产物(Artifacts)的项目，要在Bundle名称、feature名称和p2仓库中包含单词“incubation”。

单词“incubation”不应该被包含到技术命名空间之中(尤其是当项目脱离孵化阶段时可能会导致误解)。例如：一个OSGi Bundle的Bundle-SymbolicName或一个Java包名称。

遵循前面列出的孵化状态商标要求的孵化中项目能更好地利用并行IP过程。它们能更好地产生里程碑构建、发布版本以及扩展其社区。

Eclispe项目的生命周期大半都是处在成熟阶段。一个成熟的项目意味着它是开源世界的一名优秀公民，具备开放、透明以及任人唯贤的行为特点。它会周期性和有规划地发布完全知识产权的可扩展框架和典型工具。项目会积极地培养三类社区：开发者、采用者和用户。当项目编码完毕(例如有了稳定的API)并且项目组已经掌握了根据Eclipse开发过程来运作开源项目，那么项目可以选择从孵化阶段毕业进入成熟阶段(Mature Phase)。

常见问题和解答

1. 我如何才能找到架构委员会导师？

你不需要亲自寻找他们。关注建议书的内容。在建议书开放给社区进行评审后，我们会从架构委员会中招揽导师。

2. 建议书在发布后我还能进行修改吗？

是的。在创建评审启动之前你随时都可以进行修改。

3. 我应在何时提交代码以供IP组评审？

在项目配置完毕后可以提交你的代码(初始贡献)以便评审。Eclipse网络管理员将会在配置完毕后通过邮件通知你。

4. 新项目必须使用Git吗？

是的。Git是目前新项目唯一允许使用的源代码管理系统。

5. 我能够在GitHub上托管项目吗？

新项目可以使用 GitHub。官方项目代码库必须移到GitHub上的 Eclipse Organization之下。与所有的Eclipse项目代码库一样，官方代码库遵循相同的知识产权尽职调查规则和流程。

6. 我应该让项目孵化多久？

这取决于很多因素。社区期望是一个因素。团队的开源经验是另一个因素。如果你的团队是一个新的开源团队，那么相对一个拥有成熟代码基的经验丰富的团队来说，在孵化阶段待久一点可能会更好。尽管一般来说，项目应当要规划在一年内脱离孵化期。

7. 引入到Eclipse之中的成熟项目代码也需要经过孵化期吗？

是的。所有的新项目都必需从孵化阶段开始。记住孵化阶段不仅仅与项目代码有关，更是与项目团队学习如何运作一个开源项目有关。如果对于项目团队和社区来说都很有意义，那么经验老道的团队可以选择快速地结束孵化阶段(例如发布第一个版本)。

8. 所有这些术语(例如EMO)都是什么意思？

请参考词汇表。

项目资源和服务

Eclipse基金会旗下的开源项目需要使用这些Eclipse基金会服务：

● 所有的项目问题必须在Eclipse Bugzilla实例中进行跟踪；

● 源代码必须在分配给项目的源码库中进行维护(例如一个EclipseGit或者 Gerrit实例，或者在GitHub上的Eclipse Organization)；

● 项目所使用的所有第三方库必须被Eclipse IP组跟踪和批准；

● 下载包必须通过特定的下载服务器进行分发；

● 开发者(提交者)使用由Eclipse提供给项目的dev列表进行联络；

● 项目必须保持其项目元数据(Project Metadata)及时更新。

源码管理

你的项目必须使用由Eclipse基金会指定给项目的源码库维护源码。项目代码通过分配给该项目的分发渠道(例如下载服务器)进行分发，这些官方代码库必须是所有项目代码发布的专用来源。

为了使你的项目以开放的方式进行运作，潜在的贡献者必须能够以最通用的方式访问代码基线，因此所有正在进行中的开发都必须定期地提交到这些标准代码库中。

贡献者许可协议(Contributor License Agreement ，CLA)

Eclipse基金会使用贡献者许可协议(Contributor License Agreements ，CLA)来改进知识产权(Intellectual Property ，IP)管理和工作流程。所有不是Eclipse项目提交者的贡献者都必须签署CLA。

如果你已经具有了某个项目的提交者身份，那么在对该项目进行贡献时不需要签署CLA。

Git提交记录

Git提交记录需要使用专用格式。必须使用真实作者的证书来填写Author信息域。作者的电子邮件地址必须与Eclipse基金会档案记录相符(大小写敏感)。

提交信息被分为如下三部分：

1. 一行(最多72个字符)摘要；

2. 描述信息；

3. 页脚。

提交记录样例：

1. 作者的电子邮件地址必须与Eclipse基金会账户的电子邮件地址匹配。

2. 最佳实践：在提交信息中包含相关的Bug ID。

3. Gerrit的Change Id (仅当使用Gerrit进行代码审查时)。

4. 使用Also-by条目来增加其他的作者。

5. 非提交者必须使用与Author信息域中相同的电子邮件地址来签名结束提交信息。

概要(summary)行在列出的Git提交的许多地方都有使用，请确保这行是正确的。描述(describe)区域应该用来提供关于提交的更多细节。页脚区域用来提供额外的域与值。

如果bug id包括在概要行中(格式为”Bug 12345 – xxx“或者”[12345] xxx”)Gerrit代码评审将自动在对应的Bigzilla记录中添加一个指向Gerrit记录的链接(当然这样只应用于推送到Gerrit的提交)。

变更id(Change-Id)是用来在Gerrit代码评审中关联一个改变的新版与其原始版评审。只有当代码库由Gerrit管理时这个域才需要被指定。

为一次提交中的每个额外作者都创建一个独立的Also-by 域。如果一次提交通过结队编程署名，或者这次提交是由多个开发者署名的多次提交，则应当应用此域。

由非提交者提供的提交必须在页脚有Signed-off-by域，表示作者知晓贡献被提供给该项目所依据的相关条款。除此之外，非提交者必须有Eclipse基金会账户以及且必须签署过贡献者许可协议(Contributor License Agreement)的文件。

Git

那些想在Eclipse forge上使用Git的项目，会被分配一个路径，在此路径下可以按需求创建足够多的Git仓库。通过“Open a bug”来向网站管理员申请创建一个新的项目Git库。另外，有shell账户的提交者可以自己创建仓库。

创建一个新的Git仓库

> initrepo /gitroot/project/org.eclipse.repo.name.git

为了保持一致，仓库的名字必须以.git结尾。

要设置仓库的描述内容，可以使用sftp或者scp命令复制一个文本文件到 /gitroot/project/org.eclipse.repo.name.git/description。Git仓库描述内容应该限制在一两个句子组成的一段话以内。

只有项目提交者可以向Eclipse Git仓库推送内容。推送中如果包含与需求不一致的提交，推送将会被拒绝。

你可以在Git服务器上直接浏览Eclipse仓库。

Gerrit代码评审

Gerrit为Git版本控制系统提供基于网页的代码评审和仓库管理。许多项目使用Gerrit来减少障碍和鼓励项目贡献。通过“ Open a bug”来向网站管理员申请在Git仓库中配置Gerrit。

项目提交者可以通过Gerrit直接向Git仓库推送提交(例如向主分支推送)。

在Gerrit仓库中任何人都可以向refs/for/*分支推送评审。推送中如果包括与需求不一致的提交，推送将会被拒绝。用于评审的提交应该包含一个Change-Id

你可以在Gerrit服务器上直接浏览Eclipse仓库。

GitHub

项目可以选择性地将部分或全部的规范源代码仓库移动至GitHub上的Eclipse组织。

在GitHub上托管代码的项目不允许使用GitHub问题或维基。

通过“Open a bug”来向网站管理员申请为你的项目创建一个新的Git仓库，或者移动一个已有Git仓库。网站管理员将在你的GitHub仓库中安装一些hooks。

提交者hook可以给指定的项目提交者授予GitHub托管项目仓库的写入权限。项目提交者必须使用他们提交给Eclipse基金会的电子邮件地址作为他们GitHub的电子邮件地址。

贡献者许可证协议(CLA)hook将检查从GitHub拉取内容的请求，以确保贡献者在文件中有合法的CLA，并且提交的内容有按要求被进行“签订”。项目提交者应只能以合并的方式拉取“绿色”请求。

GitHub API并没有提供一个能绝对拒绝合并的方法；我们做能做的是警告你那些贡献者没有签署CLA:

除非你确认在文件中贡献者确实拥有合法CLA，否则不要合并。(例如通过CLA查询工具确认他们有CLA)。

你必须手动检查以确保提交信息在页脚包含需要的“由xxx签署”的声明。

网站管理员会在Eclipse基金会硬件上创建并维护所有GitHub托管仓库的镜像。

问题追踪工具

Eclipse项目必须使用Eclipse基金会提供的问题追踪工具。项目团队可能倾向于使用Eclipse Bugzilla或者Eclipse基金会管理的GitHub项目仓库。

根据Eclipse基金会董事会的指令，你需要就使用GitHub问题追踪工具得到PMC的批准。

如果想为项目申请GitHub问题追踪工具，在Community/GitHub中建一个bug，然后发送链接到你的PMC邮件列表来申请批准。

第三方库

Eclipse项目必须为其所使用的所有第三方库向知识产权小组(IP team)进行注册。

论坛与对外交流

所有项目都分配了一个用户论坛，作为用户、采纳者社区和项目开发者之间的联系点。

EMO强烈鼓励通过其他渠道与社区进行联系与交流：你的项目组了解你的社区并知道与他们沟通的最佳办法。

项目网站

项目网站是联系项目与社区的一个极佳的方法。许多项目选择使用项目管理基础架构(PMI)作为项目网站，但如果需要，一个项目也可以在Eclipse基金会托管服务器上托管一个网站。

项目网站源文件托管在Git仓库，由Eclipse基金会维护。通过“Open a bug”向网站管理员申请为项目创建一个网站。

相反的，为项目指定网站托管服务是不被允许的。不由Eclipse基金会托管的网站会被认为是第三方网站，必须遵循Eclipse标识与商标准则(Guildlines for Eclipse Logo & Trademarks)。(Eclipse基金会声称项目名称商标的拥有权)

构建版本

Eclipse基金会可提供和托管构建服务，也就是所谓的通用构建基础架构(CBI)，强烈推荐使用该服务，但并不严格要求。

无论你的项目是否选择使用提供的构建资源，经过适当的努力从源代码构建项目组件，对社区成员来说都是可能的。

签名的组件

从技术角度上来说，所有可下载的组件都必须包含一个由Eclipse基金会提供的证书签名是合理的。

下载

项目组件(例如下载)可以通过第三方服务(例如Maven中心库)被发布，但Eclipse基金会提供的基础架构必须被考虑作为主要的项目下载源。

项目提交者可以上传项目组件至下载服务器上的项目路径。

提交者文书

Eclipse基金会须要确保所有拥有代码、网站、问题追踪系统写入权限的提交者了解他们在Eclipse知识产权安全防护方面的角色。Eclipse基金会同样须要确保在对项目中扮演变更者角色的人有精确的记录。为了确保提交者了解他们的角色，和Eclipse基金会有精准的记录，提交者必须要提供声明表明他们已经阅读、理解并愿意遵守提交者协议的文档，并要求他们的雇主签署他们同意新提交者在项目许可协议下能参与Eclipse并贡献。

所有的提交者都必须完成提交者调查问卷并提供如下描述的文档。

提交者问卷

提交者问卷是一个所有新提交者都必须完成的在线表格。表格提供了两条不同的路径：一条是为提供了签署成员提交者协议的成员公司工作的提交者，另一条是为了其他的人。

只有当你是新项目的初始提交者，或者通过现有项目的选举，被选举成为为一个项目的提交者时，才可以访问提交者问卷。

只有签署过成员提交者协议的成员公司才会被作为成员公司列在提交者问卷中。

文档

所需要文档确切性质取决于你的雇佣状态。

文档必须被打印、签署然后通过传真(使用表格中的传真号码)或者扫描图片回复邮件至 emo-records@eclipse.org。

成员提交者协议

成员提交者协议(MCA)由成员公司使用，并适用于公司中作为提交者参与Eclipse基金会项目的雇员。

如果你的雇员提供了签署的MCA，你可能不需要任何其他的文书。

MCA使提交者文书变得容易，特别是如果你为一个雇佣了多个提交者的公司工作。有MCA的情况下，公司可以一次提供签署文档，而不是为每一个雇员都签署一次(作为个人提交者协议的要求)。

如果你的雇主没有准备提供MCA，与你的管理团队商量来决定由谁代表公司签署MCA。在提交者选举完成或者新项目创建之前提供MCA，可以使提交者供给过程更简化。如果你与你的管理团队不确定你的雇员是否有MCA，询问 EMO 记录。

如果你的雇主是可以提供签署MCA的成员公司，你必须完成个人提交者协议与Eclipse提交者雇员同意表格。

个人提交者协议

个人提交者协议(ICA)由没有被成员提交者协议覆盖的提交者使用。

你在以下情况需要提供一个ICA：

● 你为一个没有签署成员提交者协议的成员公司工作；

● 你为一个不是Eclipse基金会成员的公司工作；

● 你是自己雇佣自己或者没有被雇佣；

● 你是一个学生。

如果你提供一个ICA，并且被雇佣或者自己雇佣，你同样需要提供一个Eclipse提交者雇员同意表格。

Eclipse提交者雇员同意表格

适用于ICA的提交者当参与Eclipse基金会项目时，必须提供一个Eclipse提交者雇员同意表格(ECECF)签署雇员的同意书。

你在一下情况需要提供ECECF：

● 你为一个没有签署成员提交者协议的成员公司工作；

● 你为一个不是Eclipse基金会成员的公司工作；

● 你是自己雇佣自己。

如果你自己雇佣自己、自己拥有公司或者在另一家公司拥有所有或者部分拥有权，并且有权签署并提交ECECF，则应当如此做。

反之，你可以为公司安排你的主要商业消费者代理来为你签署和提交ECECF。

已有的提交者

如果你已经是一个现有Eclipse基金会项目的提交者，则附加的文书可能并不需要。如果需要的话EMO IP组会向你询求附加的文档。

如果MCA或者ECECF已经明确适用于新项目，或者MCA或ECECF(对所有项目)是通用的，则不需要附加的文书。

如果你所使用的MCA和ECECF不包括新项目，则候选人必须提供上文中所描述的文档。

未被雇佣或者学生

如果你并没有被雇佣或者是一个学生，发送便条至emo-records@eclipse.org解释你的未被雇佣或者学生的状态。

我们需要这个电子邮件因为大多数提交者被一个公司雇佣，Eclipse司法组假设每个人都是这样，因此例外需要被说明。

常见问题

1. 如果我没有填写文书会怎样？

你将没有源代码库写入权限的登录名和密码。对不起，没有例外。

2. 如果我不能说服雇主填写文书将会怎样？

Eclipse董事会坚定认为如果你是受雇的，则你必须是以上描述的场景之一。如果你并不确信能使你的雇主完成必要文件的填写，则你将不能拥有项目源文件的写入权限。即使你是在你的业余时间从事Eclipse项目的工作，董事会的立场也不会改变。我们意识到这样会防止一些有才华和理想的人能提交到项目，但这是我们用于减小IP风险的策略。

3. 当与管理组讨论这些文档时，我可以从哪里获得帮助？

EMO与执行理事非常乐意与你你的管理者以及高层管理讨论这些(和其他)法律文件，来帮助他们了解为什么这些文档是所有参与人(Eclipse基金会、你与你的雇主)的最佳风险减小解决方案；如需帮助，请联系我们：license@eclipse.org

4. 提交的文档可以使用什么格式？

Eclipse基金会接受以下格式的表格提交：

● 打印, 签署, 并将表格邮寄至Eclipse基金会;

● 打印, 签署, 并将表格传真至Eclipse基金会

● 打印, 签署, 并将表格的扫描件作为附件发邮件至Eclipse基金会

5. 发送扫描文档应该使用什么电子邮件地址？

将扫描文档通过邮件发送到emo-records@eclipse.org

6. 如果提交者修改雇主怎么办？

如果你修改雇主，请联系emo-records@eclipse.org

知识产权

我们希望Eclipse项目都采取必要的预防措施来降低对采用者产生知识产权问题的风险。那些整合你项目中的代码的公司，他们确信在协议内那些项目中的代码可以被合法地发布；Eclipse知识产权小组所管理的知识产权尽职调查过程便是用于解决该问题的。

所有的提交者都必须熟知Eclipse知识产权政策。

初始贡献

代码源头的跟踪是非常重要的(我们需要掌握所有的最后“落户”到我们的代码仓库中的代码的源头)；为了达到这个目的，所有的新项目，在将代码提交到项目源码仓库之前都必须提供一个初始贡献。

知识产权小组会评审你的初始贡献以确保这些代码可以以Eclipse的名义进行发布；知识产权小组同时也会评审相关代码以确保不存在不适当的复制、并确保许可被正常地使用等等；作为这个过程的一部分，知识产权小组会研究所有代码的源头；这个过程所耗费的时间，取决于贡献物的大小。

当一次发布所包含的知识产权(包括项目代码贡献以及第三方依赖库)完成尽职调查之后，项目才可以进行此发布。

创建一个贡献调查表，以便向知识产权小组提交初始贡献供其评审。

项目代码贡献知识产权小组不会评审移动至Eclipse项目的代码的历史记录；知识产权小组会对项目代码的快照进行审核，该快照中初始贡献必须是第一次被提交到Eclipse代码仓库中；如果你的项目使用了一个已经存在的GitHub代码仓库，网络管理小组会协助你将历史数据转移到隐藏分支中。

项目组维护的一些代码贡献(比如提交到项目源码仓库并由项目小组维护的贡献)必须通过知识产权小组的评审；知识产权尽职调查过程会帮助你决定某个贡献是否需要知识产权小组来评审；如果你仍然不确定，向你的项目导师或者项目管理委员会寻求帮助。

所有的项目代码贡献都必须被记载在项目的知识产权日志当中以便追踪。

创建一个贡献调查表，以便向知识产权小组提交项目代码贡献供其审查。

第三方库

项目代码中所依赖的第三方库需要通过知识产权小组的检查和批准。

知识产权小组必须对存在如下几种情况的第三方库进行评审：

● 项目组件中的Java/OSGi manifest文件里有对第三方库的直接引用(无论是引用的组件还是库里面的包);

● 项目代码中包含有对第三方库中的包的引入声明；

● 项目代码通过反射或其他方法引用了一个库中的接口与实现；

● 项目代码通过OSGI服务对一个指定的实现或者服务进行了引用；

● 项目代码调用了命令行工具。

包含但不仅限于上述情况。

第三方依赖库审核指南 可以帮助你决定如何对第三方库进行分类。

当一次发布所包含的知识产权(包括项目代码贡献以及第三方依赖库)完成尽职调查之后，项目才可以进行此发布。

所有权创建一个贡献调查表以便向知识产权小组提交第三方库供其评审。

贡献物的作者对贡献物中包含的知识产权拥有所有权；作为贡献过程的一部分，贡献者需要在项目许可的条件下对他的贡献物进行许可授权。

著作权和许可标题

所有的源文件都必须包含一个文件标题，该标题用于描述软件的著作权和许可有效期。

样例如下:

1. 列出初始版权拥有者；该拥有者必须是法人实体(例如，公司或者个人)；如果其他组织有做贡献，请包含在“其他”里面。

2. 列出项目许可。

3. 可选择性地列出贡献者的名字以及他们的贡献的性质。

你的项目不是一个法人实体，所以将其列为版权所有者是不合适的。

版权的所有者要么是某个个体，要么是他们的雇主。大部分的雇佣协议都规定了雇员所创造的知识产权属于雇主，所以雇主一般也会被列在版权所有者的名单中。

许可更多信息请查看 默认的Eclipse基金会版权和许可公告.

Eclispe的顶级项目为其项目定义了一套标准许可。如果你的项目有非标准许可的需求，你可能需要对Eclipse董事会做相关陈述，以便获得他们的批准；该陈述只需要简单地描述项目的情况以及为什么会考虑到使用特殊的许可。

贡献调查表

贡献调查表(Contribution Questionnaires，CQ)是Eclispe提交者和知识产权小组之间的主要交互接口。

当一个提交者完成关于贡献物或者第三方库的调查表时，CQ便开始了。从字面上来说,CQ是一个经过修改的Bugzilla实例(名为IPZilla)上的一条记录，该记录记载了审批过程中的相关步骤。CQ记录是提交者和知识产权小组之间的主要通信渠道。CQ记录是持续不间断的。

你可以通过IPZilla查看已经存在的CQ。值得注意的是，IPZilla只能被提交者、Eclipse基金会成员公司代表以及其他特别指定的个体所访问。根据Eclipse知识产权尽职调查过程的相关定义，被Eclipse项目维护的所有重要的代码贡献都需要一个CQ。

第三方库的CQ是特定版本的。这就是说，同一个库的不同版本是需要不同的CQ的；项目组需要为项目代码中直接使用的每个第三方库创建CQ(无论该库是否直接被该项目组所发布)。如果你的代码通过其他的Eclipse项目的源码间接使用了某个第三方库，你则不需要为这个第三方库创建CQ；

并行知识产权流程对于那些项目提交者正在进行的工作，一般是不需要CQ的；如果你想要了解更多的信息，请查阅知识产权尽职调查过程文档；

并行知识产权流程允许Eclipse项目在得到知识产权小组批准之前，使用项目源码贡献以及第三方库。在实际运用中，在通过了知识产权小组初步审核的情况下，并行知识产权流程允许某个项目在知识产权尽职调查完成之前，直接检入代码贡献到他们的源码库中，并对第三方依赖库进行构建；

在并行知识产权流程中存在一些风险。知识产权小组对项目的初步审核结果建立在对贡献的一次粗略的检查之上；但是在进行全量评审的时候，他们可能会发现一些需要解决的问题。例如，这可能需要从源码库中完全地移除贡献中的某些部分(包括历史数据);

并行知识产权表现为两种完全不同的方式：处于孵化阶段的项目可以利用并行知识产权流程来处理项目源码和第三方库；处于成熟阶段的项目可以利用并行知识产权流程来处理那些在之前的版本已经通过审核的第三方库的新版本。

在使用并行知识产权流程时，项目依然需要提交CQ。不同的是，一旦CQ通过了许可兼容性评审，项目组便可以通过IPZilla检入代码并开始工作。

在进行发布之前，所有此次发布包含的知识产权都必须完全通过批准.

附加CQ

许多的第三方库已经被批准在Eclipse项目中使用。其中有很多是可以立即通过 Orbit Project访问到的。当这些库已经确认可以被所有的项目使用时，对他们的使用必须被记录在案。对使用进行记录是为了在尽职调查的过程中发现问题时能够减少该问题带来的影响。

在这种情况下, 可以在CQ队列的顶端创建一个附加CQ；因为尽职调查的相关工作已经完成，附加CQ的批准一般会非常的迅速。

贡献调查流程

第三方库的CQ创建流程开始于对已有CQ的搜索。如果对于同样的库和版本已经存在一个CQ，那么就创建一个快捷CQ。快捷CQ在被EMO知识产权小组处理之前，必须得到该项目的项目管理委员会的批准。

如果找不到已经存在的CQ, 就创建一个新的CQ。创建之后，第三方库的源码必须被附加到记录中。项目管理委员会必须尽快审批该记录。如果该项目满足使用并行知识产权流程的条件，知识产权小组会对该记录进行一次粗略的审查，如果该CQ满足相关要求，便会尝试批准对该库进行使用，同时并行进行全量审核。

知识产权小组在对库进行深入分析时，可能需要你的协助。当分析工作完成并且知识产权小组做出决定后，他们会指出下一步操作。下一步操作可能是当该库被拒绝时，该库或者该库的某些部分会从项目的VCS中移除。大多数情况下，该库会得到批准，因此CQ也会被标记。

值得提醒的是，该过程可能会花费一定的时间。处理CQ过程消耗的实际时间取决于许多的因素，包括CQ队列的长度、贡献物的本质以及贡献物的大小。

知识产权日志

知识产权日志是对项目的知识产权贡献的记录。例如其中包括关于代码工作的，特别是对当前代码基做出贡献的所有提交者(无论是过去的还是现在的)的名单。

知识产权日志是官方版本周期的一个重要组成部分。你需要在计划发布版本或者进行重构评审之前提交你的知识产权日志。我们建议你实时更新你的知识产权日志而不是到最后需要时才忙着去补充。知识产权日志包含了关于你项目的许多重要信息，以便于让使用者知道所有的源码来自何处、谁拥有所有权等等。

特别需要指出的是, 该日志需要记录如下信息：

● 许可；

● 过去和现在的提交者；

● 第三方库；

● 来源于项目组以外的贡献(比如非提交者提交的贡献)

知识产权日志产生器

自动化知识产权日志工具可以使用Eclispe基金会可访问的信息自动生成知识产权日志。比如，提交者列表是通过项目自己提供的信息所生成的，这些项目通常会将相关信息从源码库中提取出来。

知识产权日志生成器从多个地方提取相关信息来组成知识产权日志：

● 项目所使用的第三方库信息来源于IPZilla;

● Dash将扫描项目源码库以获取提交者活动信息；

● Dash同时也会扫描Git 库以获取贡献信息；

○ 如果你按照处理Git贡献的相关指南操作，通过Git的任何分支接收的贡献都会自动出现在知识产权日志中；

● 以补丁的形式被Bugzilla接收的贡献会被标记为iplog+，并自动出现在知识产权日志中；

● 许可信息会从基金会数据库中获取；

想要充分利用知识产权自动生成工具，你需要：

● 实时更新你的项目元数据；

● 按照处理Git贡献的相关指南进行操作；

● 在Bugzilla中对知识产权贡献进行标记；

● 在合适的地方创建CQ

贡献需要被记录在Git或者Bugzilla其中之一，不能都记录。在Git的提交物中设置作者证书是一种首选的方式。知识产权日志生成器还没有智能到能识别重复记录的程度。

你的项目元数据将会用来在测定源码库中的标识，Dash需要扫描这些标识来找出提交者的信息。需要特别指出的是,你需要在“源码库章节”中详细地描述出源码库位置路径的列表。

自动化知识产权日志工具通过搜集一些来源于Git和Bugzilla的信息，生成“贡献者”章节。该章节列出了来源于非提交者的贡献(这是时间敏感的，所以当前的提交者在成为提交者之前提交的贡献也会包含其中)。只有非提交贡献才会记录在生成的日志中。

非提交者通过Git进行的提交 是通过提交记录中的作者证书进行识别的；作者字段必须设置为提交的实际作者。

或者，你也可以将Bugzilla的附件加上iplog+的标记。设置这个标记是为了表明提交该bug的人是贡献者。为了遵从网站使用条款，附加贡献的人也必须是授权该贡献可被访问的人。 你需要确认该情况是发生在将你的代码包含到项目库并标记入口之前。

你也可以将所有的Bugzilla入口进行iplog+的标记。如果你这样做了，那就是向自动知识产权日志工具说明在bug记录中非提交者的每一个评论都代表一个潜在的贡献。你的理智告诉你，要求贡献者提供并附加可以被单独标记的补丁是一个良好的做法。标记整个bug代表当一个进行中的维护问题作为来自非提交者的新的评论被添加到该bug时需要将其显示在生成的日志当中。

只有当某个bug被标记为FIXED或者CLOSED时，被标记的贡献才会出现在Bugzilla中；

该日志中的“第三方软件”章节来源于IPZilla。知识产权小组会标记你的贡献，因此该贡献会出现在日志中；如果第三方软件没有正确地显示，请联系Eclipse管理组织的知识产权小组进行更正。

常见问题

1. 我们真的需要这样做吗?

是的.

2. 对应知识产权日志，你们将如何处理?

知识产权日志评审包含两大阶段。在第一阶段，EMO会做一个技术评估以确保该项目的产物有在知识产权日志中做出合适的清点。在这个评估的过程中，可能会要求你进行协助以便解决一些不一致的问题。在第二个阶段，知识产权小组降会评审该日志以确保和他们的记录是相匹配的。当知识产权小组审批通过时，知识产权日志的评审便结束了。

3. 我应该在什么时候提交知识产权日志进行评审？

知识产权日志应该在发布评审或者重构评审的计划结束日期的两周之前进行提交。注意，你的评审日期和你实际发布版本的日期可能是不一样的。

4. 有其他原因需要提交知识产权日志进行评审吗？

通常情况下是没有的。如果知识产权小组需要在发布或重构评审之外进行知识产权日志评审，他们将会通知你。一般来说是没有必要在一个评审环境之外提交知识产权日志进行评审的。然而，比较好的做法是，自己定期地对产生的知识产权日志进行评审，以便于精确地反映出你的项目状态。

5. 我该如何修复生成的知识产权日志中的问题？

知识产权日志的产生是建立在Eclispe基金会服务器上的数据之上的。如果该日志存在错误，对应的数据应当被修复。如果你发现了一些问题，请将相关备注发送至emo@eclipse.org.

选举

项目中的角色分配基于在可公开访问的论坛中所展示出的贡献来分配，并以选举的形式来进行。选举过程首先是提名，其中包含贡献声明。贡献声明形式多样，但是一般来讲需要指明该被提名人已对项目产生的影响。

一个人的雇佣状况与其是否可参与Eclipse的开源项目无关。例如，雇佣状态并不能保证获得提交者身份；提交者的身份必须靠每个人自己争取。

提交者选举

提交者选举以被提名人的业绩声明开始。业绩声明应包括指向由被提名人做出的贡献的链接(例如git提交记录、gerrit评审、pull 请求或者Bugzilla记录)。

使用开发者入口(developer portal) 来选举一个提交者。

只有项目提交者可以在提交者选举中进行投票。一场成功的选举必须获得至少3个+1赞成票。任何提交者都可以投-1票来否决该选举。对于只有3个或少于3个提交者的项目，所有的提交者都必须投票。提交者选举将持续一周时间，但如果项目的所有提交者都投了+1票，该选举将会提前结束。

在提交者投票成功结束后，项目的PMC将会评审选举结果，然后决定是批准还是否决该选举。选举可能被否决，例如如果PMC认为业绩声明还不足够充分。

在PMC批准选举之后将会自动启动文书工作(paperwork)过程。

项目领导选举

与提交者选举类似，项目领导选举也是以业绩声明开始。该业绩声明应专注于该被提名人所表现出的领袖气质，而不应该仅专注于具体的代码贡献。

例1 项目负责人业绩声明

在初始贡献之前，Sounak一直都参加了Ogee项目的开发。作为主力开发之一，他一直都扮演着重要的角色。至于提交数量，Sounak目前是Ogee的顶级提交者：http://git.eclipse.org/c/ogee/org.eclipse.ogee.git/stats/?period=q&ofs=10。除此之外，Sounak还负责项目的页面和构建。在0.6发布版中，他还为我办理了评审手续。最后我还想提一下他为了推动Ogee在OData社区中的发展而在odata.org发布的一篇博客：http://www.odata.org/blog/eclipse-ogee。

项目领导一般也是提交者，一个项目可以有多个项目领导(称之为联席领导)。

使用在项目的管理页面中Committer Tools区域的Nominate a Project Lead链接来启动一次项目负责人选举。

只有项目提交者可以在项目领导选举中投票。一次成功的项目领导选举必须获得至少3个+1赞成票。任何提交者都可以通过投-1票来否决该选举。对于只有3个或少于3个提交者的项目，所有的提交者都必须投票。提交者选举将持续一周时间，但如果项目的所有提交者都投了+1票，该选举将会提前结束。

在提交者投票成功结束后，项目的PMC将会评审选举结果，然后决定是批准还是否决该选举。PMC批准过的选举将会交由EMO/ED作为任用建议。最终的决定权在EMO/ED。

PMC成员选举

顶级项目的PMC成员被任命的方式根据不同的PMC有所不同。有的PMC在顶级项目中设置了来自各个子项目的代表。其它PMC更特别一些，会启动一个类似于项目领导选举的选举。

在所有情况下，PMC负责人向EMO/ED提出任命PMC成员的建议。最终决定权在EMO/ED。

PMC领导选举

PMC领导不是选举出来的，他们由EMO审核、Eclipse董事会批准并由EMO/ED任命。

常见问题

1. 我们真的需要这么做吗？

是的。

发布

Eclipse项目都会有正式发布。它们由计划开始，由社区评审结束。只要你愿意，你可以发布多个未来版本。一般的做法是在3-6个月前指定版本。

发布版本大致分类如下：

● 主发布版本，包括API的变化(可能会破坏向下兼容性)

● 次发布版本，增加新的功能，但API与前面的版本兼容

● 服务发布版本，仅包括bug修复，不会包含显著的新功能

对于所有的主发布版本和次发布版本，你都必须要组织发布评审。但对于修复bug/服务发布版本，发布评审并不是必需的。

每个主发布版本和次发布版本都需要项目计划。该计划应大体列明该版本发布的目标是什么。由于对社区来说，项目计划是一个参与项目的重要手段，因此需要在发布周期开始时就制定项目计划。通过尽早制定计划，你能帮助潜在的贡献者们决定他们如何更加有效地做出贡献，也让项目的采用者可以准备他们自己的开发时间表和开发主题。在发布周期内是可以对计划进行改变的。

使用项目管理基础架构(Project Management Infrastructure(译者注：原文为Interface，应该是笔误)) 来创建一个新的发布记录。在发布周期刚开始时，你的计划至少应包括版本号、日期和简短的说明。可以把该简短说明理解为是一次“电梯演讲”：你将如何在乘电梯的15秒之内描述该版本？在发布周期内计划的各方面都可以变更(包括日期)。如果你确实需要变更计划，请确保该变更是通过你项目的开发列表或其它项目渠道沟通过的。

发布记录里的Plan标签页包含许多用于收集计划信息的字段。为版本发布计划收集信息的数量因不同的顶级项目有所差异，因此请征询你的PMC的意见。

定期发布构建版本是发布周期中很重要的一部分。构建版本在社区参与方面有重要的意义：采用者可以帮助测试你的以及他们自己的代码，这样他们就可以为最终版本做好准备。每个里程碑至少构建一个发布版本(越多越好，取决于你的项目发布周期的长短)，并且请在发布于记录中记录每个里程碑的计划时间点。每天夜间和每周都生成集成构建版本也是很常见的做法。请确保你的项目下载页为社区获取你的构建版本提供了必要的信息。

你项目的所有知识产权贡献都必需经过知识产权团队(IP Team)的批准后才可以发布(包括第三方库和由项目维护的代码贡献)。

发布评审

发布评审是你的发布版本对社区的一次正式公布，也是对反馈的一次请求。事实上经验表明，那些对你的项目感兴趣的个人和组织都会在整个发布周期内跟随开发进展，并且一般都已经在开发周期内提供了反馈(也就是说，他们一般不会在评审期间提供反馈)。考虑到这一点，评审通常作为对项目在发布周期内所取得的进展的一次回顾，发现潜在的可改进的地方，展示该项目在以一个公开和透明的方式运作，并确保已执行了开发过程和知识产权尽职调查过程。

发布评审会持续一周，并且总会在周三给出结论。

我们把评审总结安排在每个月的第一个和第三个周三进行。你的发布日期无需与评审日期一致(你可以根据需要来设置发布日期)。但是，必须要评审通过以后你才可以正式发布。

一次发布评审需要评审文档和一份知识产权(IP)日志检查。评审过程必须至少在预期的评审日期之前两周开始启动。

在评审开始之前认真准备评审文档。发布记录中不仅会包含你的项目计划，还会包含一个评审(Review)标签页，上面有与评审相关的字段。与计划(Plan)字段一样，所有的评审字段都是可选的，并且你需要提供的细节详细程度因不同的顶级项目而异。你可以在发布周期内评审信息(不需要等到结束的时候)。

评审材料必须经过PMC的批准；可以向PMC的邮件列表发送一封邮件来请求批准。PMC将会进行反馈或者是简单地回复“+1”来表示批准。

点击发布记录页面中在Committer Tools下面的”Send Email to the PMC”链接可以很方便地与PMC取得联系。

提交IP日志以便IP团队进行评审。IP团队必须在我们安排评审之前审批该IP日志，因此尽早提交IP日志很重要。IP日志生成器会自动通过IPZilla中的贡献调查表、项目源码库中的提交物、以及我们数据库中的其他信息来收集项目组已经提供给IP团队的信息。请在将IP日志提交给IP团队进行评审之前进行仔细检查。

点击发布记录页面中在Committer Tools下面的“Generate IP Log”链接可以很方便地打开IP日志生成器。

用于生成IP日志的信息应始终保持最新(不要等到发布周期的最后再修正)。

在此过程中的任何环节，你都可以通过点击发布记录页面上部的“Schedule a review for this release(为该版本安排一次评审)”链接来请求启动一次评审。这将会让你选择一个评审日期。接下来你必须要跟进EMO以批准该评审。

EMO应该会注意到你已经创建了发布记录、联系过你的PMC并提交了IP日志来应对IP团队的评审，EMO将会一步步启动实际的评审。然而，如果在该过程中出现了很大的变故，请发送电子邮件至emo@eclipse.org来说明你的意图。

EMO将在安排的截止日之前结束评审，并将结果告知项目组。

毕业评审

毕业评审的目的是确认该项目拥有可工作并且可展示的代码基线，并且拥有高度活跃和多样的社区；拥有根据Eclipse Development Process完全开放运作的采用者、开发者和用户社区；并且对Eclipse来说是一种信誉并在更大的Eclipse社区内运转良好。

毕业评审通常与发布评审结合在一起进行(通常，但并不是必须与1.0版发布一起)。在顺利完成毕业评审以后，项目将会离开孵化阶段成为一个成熟项目。

对于毕业评审，发布评审文档必须补充以包括以下内容：

● 拥有稳定API的可运行代码；

● 围绕项目已经建立的有成长性的社区；

● 不同的多组织提交者/贡献者/开发者活动；

● 使用开源规则进行开放式运作；

毕业评审文档应表明项目成员已经理解了作为一个Eclipse项目的约束和保障。也就是说，该项目“了解了Eclipse的方式”。

常见问题

1. 发布评审可以失败吗？

从技术上来讲答案是肯定的。发布评审是可以失败的。但在我们的历史上，这极少发生。我们充分准备来让发布评审获得成功。

2. 我们真的需要这么做吗？

是的。

3. 我们应该多久发布一次？

这很大程度上取决于你的项目的性质和社区及利益相关者的期望。如果你不确定，请联系你的导师和顶级项目来获得指导。

4. 我们应在评审上付出多少努力？

付出努力程度因团队性质和社区及利益相关者的期望而不同。一般来说，一个团队不应该在发布评审的形式方面花费超过几个小时。如果工作量看起来有点太多了，那可能是你太过拼命了。请联系你的项目导师、顶级项目的PMC，或者是EMO来获得指导。

5. 应该如何为评审提交IP日志？

点击IP Log generator上的Submit按钮。你需要用项目提交者的身份登录才有权限使用该按钮。

6. 在提交IP日志以后是否还可以接受新的贡献？

简短的回答是“是”。尽管接受新的贡献吧。如果你在提交IP日志以后需要一个新的贡献调查表(不管是第三方库还是代码贡献)，请询问IP团队看是否需要重新提交IP日志。

7. 我应该如何获得PMC的批准？

通过顶级项目的PMC邮件列表发送一封邮件给PMC，内附指向发布记录的链接。请注意发布记录页面上的Committer Tools下方有一个“Send Email the PMC”的便捷链接。

8. 我现在需要做一次发布了，您是否可以快速跟踪评审？

尽管我们确实会尝试尽可能的通融，但答案仍然是否定的。我们有一个明确定义的流程，包含可预测的日期。因此请相应地做好计划。

9. 在孵化阶段的项目是否可以做版本发布？

可以。实际上，我们鼓励项目在孵化阶段至少做一次版本发布。

10. 孵化项目在版本名称上有什么限制？

孵化阶段的项目通常使用小于1.0的版本号。然而，这仅是一个惯例并不是规则。如果使用高一点的版本号对于你的社区和使用者都有意义，那就可以这么做。如果你不确定，请询问你的顶级项目的PMC。

11. 我应该怎样给里程碑版本命名/版本号？

里程碑版本应该包含以“Mn”为后缀的名称/版本号(例如，EGit3.2的第二个里程碑版本可能会命名为“egit-3.2M2”)。孵化阶段的项目可能会为它们的毕业评审发布里程碑版本，比方说“myProject-1.0M2”。

12. 我要如何获取帮助？

联系你的导师(对于孵化阶段的项目而言)、顶级项目PMC或者EMO。

项目管理基础设施(PMI)

Eclipse项目管理基础设施(PMI)将项目管理活动整合到统一的位置和使其拥有一致的体验。

项目管理基础设施的主题：

提高一致性。配置信息/数据驱动的项目网站，发布版本、评审、计划之间的直接链接应保持一致。信息——包括基础项目元数据、项目计划和发布评审信息——会被收集到一起并以统一的数据格式保存(而不是任意格式的多个文档)。

所有内容都在一个地方。项目领导者和提交者可以在项目信息页编辑项目信息。尽可能消除掉从一个地方链接另外一个地方的文字/信息的情况。与评审、选举等相关的注释和讨论需要直接与被讨论的事项连接在一起。

快速上手。在默认情况下，项目具有一个数据驱动的网站，包括指向项目发布版本、评审和下载等内容并与其一致的链接。项目可以选择覆盖默认页面并提供自己的定制化的页面。建立一个项目站点仅需进行一些配置，无需通过专用API进行PHP编程。

项目元数据？

项目提交者和项目领导者有责任维护其项目的元数据。此信息是成为一个Eclipse项目的重要组成部分。

项目元数据包括：

1. 相对静态的结构信息，例如项目描述和范围、项目邮件列表和新闻组的名称，bugzilla产品、源代码库等。

2. 历史信息，例如以前版本的下载、发布评审的幻灯片和IP日志等。

3. 状态和未来的前瞻性信息，例如项目和里程碑计划、当前版本中计划的新特性、发布日期等。

PMC成员和Eclipse基金会的工作人员也可以代表一个项目修改上述内容。

查看

提供了一个查看目前所有Eclipse项目的完整列表的入口点。由此你可以直接链接到项目信息页面。导航选项可以帮你从一个项目转到另一个项目。

命令和工具

提交者可以访问几个只有提交者可以使用的命令和工具。选择的命令是否可用是上下文相关的；只会展示那些对登录用户有用的命令。

编辑项目元数据

提交者有权编辑由项目页面管理和显示的信息。项目页面分为多个章节。当你进入页面的编辑模式时，你将会看到针对每个字段内容的帮助信息(请注意帮助文本目前是位于字段的下面)。

一些字段的描述如下：

描述和范围

描述应该是一个包含3到5句话的简单段落(这适合和很多其他项目显示在一起)。通常一个简单的段落比较适合作为描述。

如果需要更多的段落来对项目进行完整的描述，可以设置成为摘要。可以指定”显示摘要”链接来精确的设置一个摘要以区别于详细描述，或者可以在描述内容中插入一个强制换行来将上面部分作为摘要。

提供摘要使你可以控制你想要显示的内容。在一些显示很多项目的视图中，系统会不自然地将太长的描述截取一小段，这可能导致描述看起来很奇怪。

下载范围适合于有更多选择性的用户。一般来说，范围应该直接从项目提案中获取。项目成员有权修改项目范围的文字，但是需要小心避免改变文字的含义。如果范围的含义需要修改，应该联系PMC进行一个潜在的调整审查。

你可以在项目的”下载”章节提供下载信息。

第一个条目就是”下载地址”。它在项目页面上显示为一个大按钮。你放置在这里的内容需要由项目团队来决定。它可以是一个网页链接、一个文件下载链接、或者其他对项目和社区有意义的内容。

可选的文字可以和下载按钮一起出现，也可以链接到0个或多个Eclipse市场、update/p2网址或其他下载地址。每个链接可以有一个可选标题(否则显示链接本身)。请注意我们并没有验证链接是否有效。

Eclipse基金会强烈建议所有的项目创建一个维护和Eclipse市场的显示。

资源仓库

项目可以指定0个或者多个资源仓库。这些显示在”贡献此项目”章节。

这些指定的内容用于检索已知存在的资源仓库的数据库(这个数据库由一个发现过程在每晚更新)。这些在数据库中找到的仓库将和一些附加信息一起展示(包括仓库镜像的链接、Gerrit等)。不管它们指向的是否是真实的仓库，所有你提供的信息都将被展示。如果数据库中不包含你的资源仓库，PMI将假定这些链接是正确的，并尽可能展示出来。

资源仓库应该使用文件系统路径来展示，例如/gitroot/egit/egit.git。资源仓库显示的名称则是从URL中的最后部分提取出来的。

如果Git仓库中存在一个描述信息文件，其内容则会自动的显示在仓库名称之下。

我们用来识别仓库的脚本也试图识别仓库对应的Gerrit接口。如果存在，就会用Gerrit地址替换Git地址。如果仓库使用了Gerrit，就只会显示Gerrit地址。否则”git://”和”ssh://”地址都会显示。

仓库是以他们指定的顺序显示的。可以在编辑界面通过拖动条目到期望位置来改变排序。所有通配符匹配都是基于名称的字母顺序排序并显示在列表尾部的。你可以使用通配符来匹配多个仓库，例如/gitroot/virgo/*。注意这些通配符仅仅工作在托管在Eclipse基础设施上的仓库(例如，它们不会工作在基于GitHub的仓库上)。

你需要提供一个贡献消息，它显示在章节的顶部。这也是社区找到项目代码的主要方式。任意的文本都是允许的，但是我们建议你将内容压缩为一个简单的段落，仅仅包含几句话以及一个指向更多信息的链接。

公司标志

在以下情况下，公司标志有时候会出现在项目页面：

● 公司必须是Eclipse基金会的成员

● 公司需要将其标志上传到Portal

● 至少有一个提交者是该公司的雇员

● 该提交者必须属于该项目

● 该提交者必须是活跃状态(过去三个月中至少提交了一次)

如果所有这些条件都满足，而公司标志却没有显示出来，这很可能是因为项目元数据没有包含指定源代码仓库的正确信息。

构建技术

项目可以指定一个文字、链接和采用的构建技术的章节。指定该信息能够帮助社区中的成员更容易地了解你的构建。链接可以包含Hudson构建的直接链接，构建说明页面，或者项目团队认为能够帮助社区构建该项目的任何其它内容。

技术类型

项目可以指定该项目出品的技术类型。这里使用更加广义的术语，如”OSGi”或”Runtime”。这些各种各样的技术类型在编辑界面以复选框的形式呈现。这些信息用于为不同的项目形成联系以便辅助导航和发现。

点击其中一个技术类型，将会引导用户进入一个项目列表页面。该页面列出了出品该技术类型的项目及其描述信息和项目标志(如果指定了的话)。

发布和审查

项目、发布和审查是分别记录的。每个项目记录明显地呈现了一个项目的信息。一个项目可能有多个发布。一次发布的信息呈现在一个发布记录中。发布记录也同时包含一些审查信息。审查信息包含在这里面，是因为并不是所有的发布都需要审查(项目可以选择提供一些审查类型信息作为发布记录的一部分)。一个项目可以有多个审查记录。因为发布审查是最常见的审查形式，所以大部分的审查记录都包含在发布记录中。

尽管如此，一个审查记录并不一定需要和发布关联。一些审查是和提案关联的。还有些审查没有任何关联(比如结束审查)。

每次发布都在数据库中有自己的记录。记录都和一个单独特定的项目有直接关联。一个项目的发布记录都会呈现在项目页面。一个已经存在的发布可以像项目一样被编辑。任何已经登陆的项目成员(提交者或项目领导者)都可以点击编辑按钮。

为每次发布创建一个单独的记录。不要为里程碑创建发布记录。为你的发布在计划信息中输入里程碑信息。

描述一个项目领导者或提交者可以通过点击项目页面的”提交者命令”中的”创建一个新的发布”来创建一个发布。这会打开一个对话框要求你指定一个日期和名称。这些信息可以在后续修改。

在描述区域描述本次发布。描述信息通常应该是一个简洁的段落，来描述发布的关注点(例如，增加的功能，修复的bug等)，这些信息应该使用适合聚集的格式(例如，一个页面展示一次同步发布中所有相关项目的发布信息)。描述信息还应该提供足够的信息来鼓励读者点击”查看更多”链接。

问题

发布记录将自动的产生一个目标bug列表。

为了产生这个列表：

● 确认项目元数据中设置了正确的Bugzilla产品信息

● 设置Bugzilla中的”目标里程碑”与你发布的名称匹配

与本次发布相关的所有项目的bug都应该包含在内。Bugzilla中的bug是使用产品和组件分组的。匹配算法应该尽可能模糊，例如一个名为”3.5”，”3.5.0”，或者”3.5 (Luna)”的发布应该和名为”3.5”，”3.5M1”，”3.5M2”，”3.5.0M3” 等的目标里程碑匹配，但不和”3.5.1”匹配。

计划

项目计划信息属于计划章节。这些信息通常应该在开发周期的早期提供出来，使各个社区能够理解和参与这次发布。总是希望计划能够渐进明细。注意所有项目都需要为每个或大或小的发布版本提供一个计划(服务发布可以不需要计划)。

里程碑

为每个发布里程碑填写名称、时间和可选的描述信息。

项目每次发布通常应该包含多余一个里程碑。为了包含更多的里程碑，点击”添加另一项”按钮。请注意里程碑可以拖动排序。让名称字段为空可以删除该里程碑。

审查

发布有一个审查章节能够提供审查相关的信息。如果你在这里提供信息，发布记录本身可以被视作审查文档，就不再需要其他的文档了。

审查页面的每个区域都包含一个小的帮助信息来描述你提供的信息的类型。

所有的或大或小的发布都需要审查。服务发布(例如，不修改公共API或添加新功能的bug修复发布)不需要审查。

如果一个发布需要审查，你可以通过点击”安排一个审查”来添加。按钮上面的下拉列表包含多个审查日期的选项。选择最适合你的那个。

如果一个审查已经开始安排，或者发布日期没有提供足够的时间来执行审查，就不会出现日期选项了。如果一个审查已经安排，就会显示一个审查的链接。

你可以编辑审查文档，但是不是一定要这么做。如果一个审查不适合作为发布记录的一部分，一个自由格式的文件字段可以被用来为审查提供特定的信息。这个字段用于一些其他类型的审查(例如重建或终止审查)。我们决定为发布审查保留这个字段而不是废弃，让它在需要的时候发挥作用。

当审查被显示时，它将自动包含发布记录中的审查信息。在页面的顶部将显示审查特有的信息，同时在页面余下区域显示发布记录中包含的审查信息。

在你想修改审查记录的元数据时，这可能会让你迷糊。你只要记住关于发布的审查信息是记录在发布记录中的就行了。

加入一个同步发布

项目不能自己加入到一个同步发布(如Luna)中，而只能由EMO加入(有一个开放的bug来扩展计划委员会成员的能力)。

要加入一个同步发布：

1. 创建一个发布记录

○ 最初至少提供一个描述

○ 发布的日期通常应该和同步发布的日期匹配

2. 向计划委员会发送一个记录(Eclipse项目通常通过跨项目问题开发邮件列表来实现)，包括你项目的名称，发布的名称和数量，以及偏移量。

偏移量是指在一个里程碑聚集过程启动后到你的项目二进制包可用的天数。例如，如果你的项目二进制包依赖于另一个+1项目的二进制包，那么你的项目就很可能是+2项目。

词汇表

架构委员会(AC)

对于妨碍Eclipse持续的技术成功和创新、广泛采用和未来成长的问题，Eclipse架构委员会(AC)通过识别和抓住这些问题以服务于社区。这涉及技术架构、开源过程和社会方面。我们有来自所有社区的利益相关者组成的最好的技术领导团体，促使项目成功并健康、过程简单并顺利以及社区生气勃勃并有用户粘性是委员会的目标。

架构委员会导师

Eclipse架构委员会(AC)是一个由大量丰富经验的Eclipse提交者组成的。所有的新项目必须有至少两个来自AC的导师。你的项目导师将帮助你找到你在Eclipse开发过程或Eclipse社区中可能遇到的问题的答案。如果你的导师无法回答你的问题，他们可以利用整个AC和EMO的智慧。

董事会

Eclipse基金会商业和技术上的事务都由董事会直接管理。

提交者

提交者是软件开发者，他有权编写代码并提交到项目源代码仓库。提交者有责任保证提交到项目源代码仓库的代码有足够好的质量。更进一步的说，他们必须确保提交到Eclipse源代码仓库的代码在知识产权方面是干净的。这一点会在下面做更详细的讨论。

社区

社区是一种模糊的术语。社区是集中在你的项目周围的一些个体或组织。对于一些项目来说，社区非常大。但其他一些项目的社区可能很小。开发社区是成为Eclipse项目的一个非常重要的部分，我们可以从社区中获取反馈、贡献和新点子，最终还有新的提交者来帮助你实现你的共同愿景。整个Eclipse社区由各个独立项目的社区联合组成。

贡献调查表(CQ)

和非提交者提交一个内容的重大贡献到Eclipse项目相比，提交者需要填写一份CQ，并提交到知识产权团队来批准。除了EMO外，相关PMC也需要提供技术审查以及批准贡献。一般来说，项目提交者提交的正在进行的开发不需要EMO或PMC的批准。当有疑问时，参考Eclipse知识产权尽职调查过程。

贡献者

贡献者是任何对项目提供贡献的人。贡献一般是以代码形式呈现，但也可能是对一个问题的描述、对文档的完善以及在论坛中回答问题等等。

冲刺过程

冲刺过程是一些原稿和过程的集合，用来收获项目的图表、知识产权日志等数据来进行宣传。

开发列表Dev-list

每个项目都有一个开发列表。所有的提交者都必须订阅该列表。开发列表是项目提交者之间首要的沟通方式，也是Eclipse基金会的自动化系统和项目沟通的方式。

生态系统

一个商业化生态系统是一些公司、组织和个体为了共同利益一起工作的系统。现在已经有了一个巨大的生态系统，其中有很多公司将他们重要业务都基于Eclipse技术。这包括将Eclipse代码应用到产品中，提供支持以及其他服务。你可以通过满足一些商业兴趣的需要、保持开放和透明、响应反馈等来成为一个生态系统的一部分。最终，成为一个商业生态系统的一部分是确保你的项目长寿的一个好方法：那些将业务构建在你的项目之上的公司会很乐意为你的项目做出贡献。

Eclipse

这是一个很困难的术语。对于这个大社区中的大部分人来说，”Eclipse“代表着基于JDT项目并由Eclipse打包项目打包的一个Java IDE。尽管如此，”Eclipse”这个术语还代表着Eclipse基金会、eclipse.org网站、社区、生态系统，当然还有Eclipse项目(任何一个托管在Eclipse基金会上的顶级项目)。有点疑惑? 没错。

Eclipse管理组织(EMO)

Eclipse项目管理组织(EMO)由Eclipse基金会职员与架构和计划委员会组成。EMO负责为项目提供服务、促进项目审查好热解决问题等等。EMO是Eclipse开发过程的维护者。联系EMO的最好方式是通过Email (emo@eclipse.org)。如果你有项目领导者、导师或者PMC回答不了的问题，那就问EMO。

EMO执行董事

EMO执行董事 (EMO/ED) 是Eclipse基金会的最高老板。他最终负责Eclipse基金会所有运作的事务。

EMO 知识产权团队

EMO知识产权团队(简称IP团队)负责实施Eclipse基金会的知识产权政策。

EMO记录

EMO记录团队代表Eclipse基金会负责管理提交者文书工作和其他记录。通过Email (emo_records@eclipse.org) 联系EMO记录团队。

孵化阶段

孵化阶段的目标就是建立一个功能完整的开源的项目。由此而论，孵化就是开发过程、社区和技术。孵化是一个阶段而不是一个地点：新项目有可能从任何已存在的项目中孵化出来。

知识产权尽职调查过程

知识产权尽职调查过程定义了知识产权添加到项目中的过程。所有Eclipse提交者都必须熟悉该过程。

知识产权记录

知识产权记录是项目知识产权贡献的记录。它包含一个列表，记录着所有提交者过去和现在的代码工作情况，尤其是谁对当前的代码做出了贡献。

成员公司

Eclipse基金会和Eclipse社区是有我们的成员组织来支持的。通过他们的支持，Eclipse基金会提供IT开源社区，知识产权、导师和市场服务。

并行知识产权

并行知识产权过程是指允许一个Eclipse项目在知识产权团队完全批准之前使用项目代码贡献和第三方库。

计划委员会

计划委员会负责跨项目计划、架构问题、用户界面冲突和所有其他协作和集成问题。计划委员会通过合作的评估、优先次序和折衷来履行职责。

项目

项目是实际工作发生的地方。每个项目都有代码、提交者和资源，资源包括网站、源代码仓库以及构建和下载服务器上的空间等。一个项目可能是其他一个或多个项目的父项目。每个子项目都有它自己的标识、提交者和资源。项目可能但不是必须拥有一个专用的网站。项目有时候也会被称为子项目或组件。Eclipse开发过程会将项目、子项目和组件术语视为等同。

项目领导者

项目领导者是一个责任重于权力的职位。项目领导者直接负责项目的整个发展。他们拥有并管理着项目的开发过程、协调发展、促进项目提交者之间的讨论、确保Eclipse知识产权政策被项目遵守等等。如果你有关于你项目、Eclipse开发过程或其他任何疑问，你可以咨询项目领导者。

项目管理委员会(PMC)

每个顶级项目都由一个项目管理委员会(PMC)管理。PMC有一个或者多个领导者以及众多成员。PMC有很多职责，包括提交者选举的最终批准以及知识产权贡献的批准。实际上，PMC监督顶级项目下的每个项目。如果你有项目领导者不能回答的问题，可以问PMC。

项目管理接口(PMI)

项目管理接口(PMI)是跟踪Eclipse项目状态和进展的系统。项目提交者可以修改PMI中展示的信息，包括项目描述以及项目发布信息。自动化系统使用这个信息来产生项目的仪表板和图表信息，知识产权日志等。

顶级项目

一个顶级项目(TLP)实际上是一个做实际工作的项目容器。一个顶级项目不像通常一样包含代码：它更多的是包含其他的项目。每个顶级项目定义了一个宪章，除了其他事情外，还定义了其包含的不同类型的项目范围。顶级项目是由PMC管理的。

网络管理员

网络管理员团队负责维护Eclipse基金会和Eclipse工厂的IT基础设施。你可以直接通过email(webmaster@eclipse.org)来联系网络管理员团队。

工作组

Eclipse工作组提供了一个中立厂商管理结构来允许各组织在新技术开发上免费合作。

获取帮助

如果你有任何疑问，或者不明确你作为项目领导者或提交者的责任，请联系你所在项目的导师或EMO。

本文最后更新于2015-08-18 15:09:59 -04:00。