我们努力降低进入项目的门槛。这在一定程度上是通过不要求新的贡献者在被接纳为提交者之前“证明自己”来实现的。相反，我们假设他们是好的，直到被证明不是，这个原则适用于任何人，没有任意的歧视。我们认识到每一个贡献都是宝贵的，并且我们认识到每一个添加的过程都会拒绝一些潜在的贡献。
通过将项目组织为核心、插件、模块和其他独立部分，可以降低进入门槛，从而减少协作和交流的需要。我们试图让每个人都有自己的地盘，在那里他们可以有效地工作，而不会被讨论和妥协所阻碍。我们相信每个人都有权利在自己的插件中表达自己的想法。
较低的准入门槛也在一定程度上通过认识到人们不断前进来实现。项目中的许多代码都是由原作者以外的人维护的。我们鼓励新的贡献者接管那些没有被积极维护的现有项目。我们认为，“老”贡献者理应得到“新”贡献者的尊重，但“老”贡献者的不作为不应阻碍“新”贡献者做出改变。
我们努力降低准入门槛，并不意味着每个人都有平等的发言权。也就是说，我们看重那些对项目贡献更多的人精英．贡献不应该仅仅被狭隘地解释为代码更改，而是包括帮助社区中的其他人、进行PR、运行基础设施等活动。
詹金斯项必威国际有限公司目使用麻省理工学院的许可作为我们开发代码的首选许可证。除非另有说明，所有的代码都是MIT许可的。
的詹金斯的核心必威国际有限公司是完全在麻省理工学院许可下的，我们的基础设施代码(运行项目本身)，以及许多插件。我们鼓励托管插件使用相同的MIT许可证，以简化用户的故事，但插件可以自由选择自己的许可证，只要它是osi批准的开源许可证。
不要将其与专有插件混淆——我们认可并鼓励人们自己编写插件供内部使用，而不必提供源代码。但是Jenkins项目不会托管这样的插件。必威国际有限公司
为了进一步澄清项目周围的知识产权，我们要求核心提交者签署一份贡献者协议。这个CLA与Apache的CLA相同，只是将“Apache”替换为“SPI”。该协议明确地将一组权利分配给SPI，例如有效的联合版权所有权、专利授权，以及承认您拥有做出更改的必要权利。
将这些权利分配给SPI有助于Jenkins对任何特定供应商保持中立，也会让法律部门感到高必威国际有限公司兴，特别是在希望使用Jenkins的大型组织中。
cla有两种类型。每个核心贡献者都需要签署一份个人CLA (ICLA),在这种情况下,你作为一个个体不拥有你贡献的工作(比如当你的公司分配你的工作詹金斯,因此贵公司拥有你生产的努力),公司还需要签署一份企业班(CCLA)。必威国际有限公司看到在Apache中讨论更多细节．CLA表单可以从以下url获取:
为了平衡额外的开销和较低的进入门槛，这个策略只适用于核心，尽管我们欢迎任何愿意为他们的插件工作提交CLA的人。
提交cla的详细信息记录在infra-cla自述．
Jenk必威国际有限公司ins项目严重依赖于第三方库。我们相信，尽可能重复使用比彻底改造更好，这样我们宝贵的资源就可以用在其他地方。
必威国际有限公司Jenkins作为一个整体需要是一个开源项目，所以我们一直限制自己只使用第三方库osi已批准的开源许可(如Apache Software License、BSD License、MIT License、Eclipse Public License、Lesser GNU Public License等)此外，为了尽可能广泛地重用核心，我们拒绝所谓的版权许可将整个许可证限制为特定的许可证(例如GNU公共许可证)。为此，我们指定以下许可证作为我们可以依赖的已批准的许可证。其他许可证需经董事会批准:
在核心中，构建过程确保所有依赖项库的许可证都被考虑在内。换句话说，我们要求依赖项POMs以Maven的方式声明它们自己的许可证，或者使用许可证完成脚本在POM缺少该信息的地方提供一个。如果库是双许可的，那么还会使用完成脚本来选择特定的许可。这样做是为了使第三方库许可证的摘要列表不包括左拷贝许可证。
结果被打包到核心中，从那里可以看到在应用程序中．在war文件中也可以使用XML格式。
当涉及到第三方许可政策时，插件不一定遵循同样的程序。它们显然需要遵守它们使用的库的许可证，但例如，它们不需要运行与核心使用的相同的许可证完成方案。
我们鼓励插件遵循与核心相同的第三方许可政策。你可自行更改，风险自负。例如,请参见FSF对带有非GPL内核的GPL插件的看法．
看到商标和归因详情页面。
治理委员会由五个人组成，他们在必要时充当项目的公共代表，例如与外部实体(如SPI或CDF)进行接口。
如果争议不能通过定期的项目社区会议解决，委员会还作为最终决策权。董事会的决策能力更具有象征性和尊敬性，它像英国女王一样“统治”，而不是独裁。
的治理委员会Page提供进一步的信息，包括当前董事会成员的名单，以及如何联系董事会。
治理委员会的选举过程可以在董事会选举过程
基础架构管理员拥有对运行的各种服务器和构建代理的根访问权必威国际有限公司jenkins-ci.org和其他的子域。他们保持服务器正常运行，安装新软件，协调镜像，处理密钥和证书，并确保我们能够继续大量编写代码。
由于这项工作的敏感性质，基础架构管理员只能通过邀请，而且有些活动是秘密进行的。基础架构管理员经常指派其他人来分配对系统的部分访问权限，以完成某些任务。
部分公共基建部门的行政人员名单可在此查阅:基础设施管理员
核心提交者是那些有推送访问权的人Jenkins的主必威国际有限公司要存储库生产必威国际有限公司jenkins.war．要成为核心提交者，需要签署贡献者许可协议．在被授予提交访问权之前，不需要有经过验证的贡献历史，但这并不意味着其他核心提交者永远不会恢复您的更改。
CLA签署人的名单保存在这里:https://github.com/必威国际有限公司jenkinsci/infra-cla
社区中人与人之间的交流对项目的统一性至关重要。参与Jenkins项目的人们必威国际有限公司在不同的地方进行交流。有一个宣传和推广以公共传播为重点的特殊利益集团。以下列出了一些沟通渠道。
我们鼓励邮件列表作为开发人员和用户讨论的主要方式，因为它们具有异步性和搜索归档的能力。项目网站列出活动邮件列表及其用途．
必威国际有限公司詹金斯项目使用IRC和Gitter通道实时交互式通信。这也是活跃成员相互联系的地方。
@必威国际有限公司jenkinsci是Jenkins项目的官方Twitter帐户，由贡献者团队运行(必威国际有限公司JEP-10)．还有一个@必威国际有限公司jenkins_release用于自动插件发布公告的帐号，以及由meetup群组等子社区运行的其他帐号。
有多个特殊利益集团在社区。这些小组专注于特定的主题，并组织专门的沟通渠道，包括聊天、邮件列表和定期会议。
本节总结了我们在项目中运行的关键基础设施服务。看到必威国际有限公司詹金斯的基础设施页面获取服务的完整列表和更多细节。
必威国际有限公司Jenkins网站(Jenkins .io)是由Jenkins项目自行托管的。它遵循“基础架构即代码”的方法，每个人都可以通过提交一个pull请求来为网站和内容做出贡献。它的源代码可以找到在这里．
我们的大部分代码都在GitHub上。必威国际有限公司jenkinsci和必威国际有限公司jenkins-infra是我们存放大部分代码的组织。可以找到更多关于GitHub组织和存储库结构的信息在这里．
基础架构管理员运行LDAP服务器和一个小的前端程序允许用户在jenkins.io上创建账户。必威国际有限公司此帐户用于访问Jenkins项目运行的服务:问题跟踪器、Maven存储库、CI实例等。必威国际有限公司
我们的主要bug跟踪器由infra管理员维护。这将使用上面描述的LDAP服务器进行访问。
我们运行一个必威国际有限公司詹金斯实例对于Je必威国际有限公司nkins核心和插件的持续集成。还有一些其他的Jenkins实例可以自动发必威国际有限公司布和基础架构管理。
必威国际有限公司Jenkins项目提供了一个公共社区驱动的路线图。它聚集了所有领域的关键计划:特性、基础设施、文档、社区等。我们不承诺交付日期，我们不保证一个倡议将被实施。所有倡议都取决于贡献，我们邀请所有感兴趣的各方加入我们，为实现路线图目标作出贡献。
的必威国际有限公司詹金斯核心的代码、模块和库的集合必威国际有限公司jenkins.war二进制文件。官方核心库托管在GitHub上。
Jenk必威国际有限公司ins核心由一组长期的提交者维护，他们审查并集成提交的变更GitHub的请求．他们还协调了詹金斯的释放。必威国际有限公司看到必威国际有限公司Jenkins核心维护者指南有关角色、角色的职责和维护流程的更多信息。
核心提交者通常使用他们自己的判断来决定要做什么。核心提交者应该注意等待的pull请求，并尝试快速地对它们采取行动。
Jenk必威国际有限公司ins项目为Jenkins核心提供了两个发布线。对于这两行，我们提供了多个发行版，包括必威国际有限公司jenkins.war， Docker映像、安装程序和本地包。用户可以下载它们在这里．
插件是由开发插件的人自主开发的。每个版本都有自己的存储库，自己的Jenkins-on-Jenkins作业，自必威国际有限公司己的问题跟踪组件，并维护自己的发布计划。
一些插件是由少数人积极维护的，它们可能有自己的本地文化，比如不同的编码约定，额外的提交策略。我们这样做是为了让人们对自己的努力有归属感和归属感，这样他们就不会觉得自己必须遵守外部决定的规则。
由于许多这样的本地文化是隐式的，通常很难从一个给定插件的外部操作文化中区分出来。安全的经验法则是，在提交之前先联系现有的开发人员(但如果在一周内没有及时的响应，那么你应该放心提交。)较少维护的插件往往没有这样的本地文化，所以在这些情况下，如果您觉得幸运的话，可以提前提交更改并同时发送警告(并接受更改被恢复的可能性)。
维护人员信息应该列在插件的wiki页面的信息框中。如果你不知道该联系谁，最好的备选方案是开发人员的邮件列表。
每个发布的插件都有自己的页面https://plugins.必威国际有限公司jenkins.io/,如这．这些页面提供了关于插件的文档和信息:安装统计、更新日志、已知问题等。文档可以从插件的GitHub存储库中检索，也可以从现已弃用的wiki.jenkins.io中检索。必威国际有限公司看到插件文档页面在开发人员指南中了解更多关于它如何工作的信息。
在詹金斯核心，必威国际有限公司我们大致遵循太阳编码约定在源代码中，我们使用4个空格的缩进，不使用制表符。如果您提交的更改不会对代码格式造成太大的改变，因为这会减轻代码审查工作，那么通常会更实用和更受欢迎。尝试在不同的提交中提交格式更改和功能更改。
话虽如此，我们不相信严格的编码约定，我们也不想拒绝贡献，因为他们的代码格式与我们使用的不匹配。所以把这看作是信息。
必威国际有限公司Jenkins插件和其他组件可以定义它们自己的代码约定。
看到拉请求清单查看向Jenkins提交代码的指南。必威国际有限公司
当您有这样做的许可证，并且该许可证与MIT许可证兼容时，您可以从其他地方复制代码到Jenkins。必威国际有限公司
最典型的情况是原始代码是在开源许可的某个子集下获得许可的，比如ASL、BSD和MIT许可。Copyleft许可，即使它们是开源的，也不能被复制，例如EPL和GPL。特别是，这意味着我们可以在MIT许可下复制Oracle Hudson的源代码，但不能在EPL下复制Eclipse Hudson的源代码。
要复制的代码必须清楚地标明它所在的许可，在复制时，您需要在标题中维护版权/许可属性。还请指明副本的来源，作为提交消息的一部分。
有时，有必要对我们使用的库进行错误修复和更改。如果库对Jenkins很重要，对我们的用户影响也很大，那么我们就选择维护必威国际有限公司本地补丁集到上游库，就像Linux发行版为其包维护这些补丁一样。
我们通常打算将这些本地补丁集成到上游，所以我们会向上游提交罚单并提供我们的差异。当这工作正常时，这允许我们在未来的某个时间点回到原始的上游版本。这些补丁集在我们的git库中作为一个并行分支进行维护。
在某些情况下，所谓的“临时”补丁集由于各种超出我们控制的原因变得更加持久，比如上游的开发停止了，但那只是因为事情就是这样发展的，而不是因为我们一开始就打算这样做。使用分布式版本控制系统，维护Jenkins的并行补丁版本就不像以前那么困难了。必威国际有限公司
如果您开发了一个插件，我们鼓励您与Jenkins项目共同主持，以便社区中的其他人可以参与。必威国际有限公司看到主机插件为更多的细节。
如果你感兴趣的只是做少量的改变，而不是想要留下来。通过GitHub发送pull请求是最简单的。看到使用拉请求为更多的细节。如果你的pull请求没有得到及时的关注，请通过开发者邮件列表通知我们，以便我们可以解决这个问题。
如果你想更认真地参与进来，除了pull请求，我们鼓励你考虑成为一个提交者。在IRC频道或开发列表中给我们留言，我们会给你设置提交权限。尽量礼貌地对待现有开发者，向他们发出警告并与他们协调，但如果他们没有回应，不要让这阻碍你的进程。开发人员的资历是通过不断的参与来获得的。
通常情况下，一旦插件变得足够好(或者最初的作者改变了工作，不再有动力从事这项技术)，最初的开发人员就会转向其他工作。因此，我们鼓励新开发人员或不同插件的开发人员参与到其他插件悬而未决的pull请求或处理针对他们的问题。
为此，我们也鼓励人们选择休眠插件，并将其视为自己的插件。看到采用一个插件指南以获取更多信息。
许多不太活跃的插件实际上没有任何明显的所有者，它们是由一些人进行协作维护的，这些人做了一些小的更改，并在需要时发布它们。如果有疑问，可以在开发列表中询问。
如果你只对小的改变感兴趣，同样的过程也适用于插件。只需提交一个pull请求!然而，由于核心的变化会影响更多的人，我们将感激如果你尝试去额外的距离在注释中描述使用拉请求．
如果您想更认真地参与Jenkins核心，可以考虑加入Jenkins核心维护者团队。必威国际有限公司参见入职指导在这里．
当做出改变时，运用你的常识。例如，如果你想做一个大的改变，建议你提前与开发人员讨论你的改变。或者如果你发现你想做的部分已经被别人修改了，给他们一个提示。
我们一直在寻找可以帮助Jenkins本地化不同语言的人。必威国际有限公司如果您有兴趣提供帮助，请在开发列表中给我们一个注释，以便获得提交访问权限，然后查看国际化了解如何进行更改的细节。
如上所述，Jenkins项目使用pull必威国际有限公司请求作为获取变更的主要工作流之一。当您准备pull请求时，请考虑以下清单作为最佳实践。
看到github在线帮助如何创建一个拉请求
我们鼓励你去登记问题跟踪来描述您正在修复的bug或您正在实现的特性。这在我们的系统上创建了一个永久的记录，允许未来的开发人员了解代码是如何变成当前形状的。这不是必需的(特别是对于小的更改)，但是如果您这样做了，我们将非常感激。
在提交消息中使用符号来引用票据[必威国际有限公司詹金斯- 1234]在哪里必威国际有限公司詹金斯- 1234是机票ID。这使得我们的脚本能够理解历史并在没有人工帮助的情况下生成更改日志。如果你用符号(修复詹金必威国际有限公司斯- 1234)，当更改合并到存储库中，并且在CI服务器中测试更改时，bot将自动关闭票据。这些表示法可以在系统之间创建有用的交叉引用，因此强烈推荐使用。
我们鼓励您为您添加的代码使用一个测试用例，以避免将来的回归。看到测试有关如何编写测试的详细信息。
试着描述你的变化，这样其他人就能理解你做了什么。
确保没有修改与更改不相关的部分(通常是由IDE自动修复导入语句和其他代码格式引起的)。
我们确实努力去关注入站的拉请求，不幸的是，我们可能无法及时地审查其中的一些请求。如果你注意到你的pull请求在一两周内没有得到处理，请在开发者列表中给我们留言，或者在GitHub的pull请求中给我们发信息。看到将请求拉到存储库有关拉请求的更多建议。
该文档由社区所有，实质性的更改通过项目会议批准。将你的问题发送到开发列表，或添加一个项目到下一个治理会议的议程．