Chromium是一个开源的浏览器项目，官方网站列出了许多文档。 
官网最值得学习的地方：许多指引写得非常细致，能以老师教导学生的态度去叙述如何工作，而不是为了写文档而写文档，例如“不要害怕问问题，总有人会在IRC上帮到你”。多数文章写得很好很凝练，没法抽取主要信息，全文翻译又太耗时，不如直接看原文。所以只需要筛选出有用的信息，而不用自己总结什么。虽然一些文档会偏旧，但胜在齐全，特别是工作规范类的文档，能为团队协作做出良好的引导。 
文档主要分类如下： 
1. 开发相关：如何checkout、编译、调试、开分支、提交代码、发review和review指引、成为committer及其职责说明、学习路径指引、开发工具使用指引、以功能划分模块的架构设计、代码规范。 
2. 测试相关： 报bug指南、bug处理流程、bug系统的使用、各种自动化测试系统的使用。 
3. 交流：通讯工具、信息发布blog、术语表、wifi、文档索引、在线的代码查看和搜索站点。 
4. 项目管理：宗旨、发布日程、设计理念、演进方向、开发计划管理。

开发相关： 
对开发者，有一个文档汇总的页面http://dev.chromium.org/developers，页面下方是全部文档的索引。 
Life of a Chromium Developer。PPT总结。 
代码学习路径指引。 
需求点状态。在这里能看出开发的方向和进度。（各种方向的都有，很难自己总结，偏H5的多）。 
信息发布的blog。 
术语表。 
用Sublime Text编辑代码。

准备好代码： 
- 必须遵守代码规范。 
- 必须经过测试，通常是单元测试。 代码的量级合理。 
- 大量的代码无法很快review完。 
运行单元测试和UI测试确保你没搞坏任何东西。或请其他人提交到try server。 
个人Contributor和公司Contributor需要分别签协议。签过后会把联系方式加到AUTHORS文件里。（从这个AUTHORS文件发现总共有435个独立committer和11家公司） 
开发： 
先开分支，并准备change list（CL）。 
git checkout -b mychange origin/master 
echo "This describes the goat teleporter." > GOATS 
git add GOATS 
git commit 
然后提交到Rietveld做review。change list有模板。

commit流程： 
先提交到try server，等所有测试变绿。提示时，确保：IRC在线，不离开座位。 
review系统。这系统是开源项目Rietveld做的。 
external目录的代码不属于Chromium项目，需要对应项目的committer权限，按对应的方式去写代码和提交。

Review相关： 
除了找OWNERS文件来找到reviewer，还可以用svn blame或git blame来查看谁编辑过此文件。 
由于Chromium是全球开源项目，开发者之间有时差，review过程可能持续24-48小时。减少这一影响的建议是review的评价更细致。 
Review通过后，可以在Rietveld选择commit或用命令行git cl set_commit，会先提交到commit_queue，这是非committer提交代码的方式。committer还是可以直接提交代码的，但不鼓励这样做，因为没经过tests。reviewer对非committer发起的review，有一个Checklist指引。

有提交权限的称为committer，没有权限但通过别的方式贡献代码的叫contributor。 
成为committer： 
简单来说就是提交10到20个有价值的patch并请至少3个以上不同的人review过，然后请某人提名你作为committer候选人并获取支持。 
需要证明你自己： 
- 致力于对此project做贡献（10个以上good patch需要非常多的时间） 
- 能和团队协作得很好 
- 了解团队如何运作（规则，测试和review流程等） 
- 了解project的代码基础和编码风格 
- 写出好的代码 
请一个committer通过邮件给committers@chromium.org来提名你，内容包括： 
- 你的名字 
- 你的email地址。需要获取@chromium.org的邮箱 
- 解释为什么你必须成为committer 
- 你提交的patch的revisions列表 
还需要另外两个committer支持你的提名。如果5个工作日内没人反对，就通过了。如果有人反对或需要更多信息，committer们会讨论并在5个工作日内达成一致意见。如果问题还不能解决，将会以投票来解决。通常反对原因是这两个：需要提交更多patch；没有足够的人熟悉你的工作。 
通过后，会获得SVN或Git的写权限，并添加到邮件组committers@chromium.org里。 
不需要做额外的事情来维持committer身份。

Commit Queue： 
这是一个自动化工具帮助提交Rietveld的变更代码。在这之前，committer需要在本地运行脚本来到try server上跑集成测试。工作原理是去codereview系统获取closed和待commit的任务，在队列中不断发起try server的测试。其中有一些更智能化的设计，暂没必要深入研究了。

如果想增加一个新功能，可以先去讨论组发帖。如果是基于已有的代码做修改，可去每个目录找OWNERS文件，找到owner做讨论。 
bug系统里不是所有bug都已分派人员去解决，如果你感兴趣可以请求这个bug让你解。

DevTools开发工具，欢迎对这块贡献代码，开发工具和写文档。

测试相关： 
获取bug编辑权限： 
任何人都可以报告bug和添加评论，但增加标签、标记重复、改变状态则需要额外的权限。

提交patch前需要在try server先通过测试，如果不想其他人帮忙try，可以单独申请try的权限。可以先获取@chromium.org邮箱然后去填写申请表格，或请合作的人发邮件去committers@chromium.org申请。

Try Server： 
是一个标准的buildbot和一系列的slave。由此得到LKDR（Last Known Good Revision），会公布在http://chromium-status.appspot.com/lkgr。Try Server不是很适合需要快速迭代的UC。

bug系统： 
bug列表：https://code.google.com/p/chromium/issues/list。此系统是自己开发的，列表带有ID、优先级、发现bug的版本、迭代记录、解决的channel（稳定版或beta版）、分类、状态、owner、概要和标签、操作系统、修改日期。页面有链接转向：报bug向导、高级搜索，搜索提示（技巧，如特别的关键字，条件搜索，附件搜索等)，自行关注某类label（有此类bug会收到email）。 
报bug的页面：http://code.google.com/p/chromium/issues/entry 
Mac & Linux报bug指南：报bug的步骤、示范一个好的报告等。 
报告崩溃bug的指南：Chrome可以打开上传崩溃报告。设置->高级设置->勾上 将使用情况统计信息和崩溃报告自动发送给 Google。然后可以打开chrome://crashes来查看崩溃ID。Android的手动收集：崩溃报告路径在/data/data/$PACKAGE/cache/Crash\ Reports/。或者运行adb shell bugreport收集系统信息。 
基本要求： 
- 确保最新的代码还有此bug 
- 提供一个高级的问题描述 
- 详细的重现步骤 
- 包含期望的行为 
- 确认其他浏览器是否有此bug 
- 如果测试过程（如页面）可以更简化，做成简单测试并附加到此bug里 
阻碍发布的bug的处理指南。 
报告无响应bug的指南。 
报告安全bug的指南。 
处理一个bug的指南。（非常细致，值得一看学习如何编写这类文档）

交流： 
交流方式： 
讨论组：区分专题，如常规讨论组、插件(for Chromium）讨论组、installable web apps(for Chromium)讨论组、HTML5讨论组等。

IRC（Internet Relay Chat）：即在线聊天室。主频道：irc.freenode.net/#chromium

Wiki：多数是一些特殊的工作技巧。

有用的URLs：工作中常用的URL收集。 
所有发布版的情况：含版本、发布日期、操作系统、对应的svn版本号、对应的webkit版本号，changelog等。 
最近100个编译ok的版本号。 
在线的提交历史记录。 
committer名录。 
在线搜索代码。

项目管理： 
产品的宗旨：快速、安全、稳定、简单（易用）。（从宗旨看，资源消耗不是首要的）

不同的发布版本称为不同的channel，五种： 
Stable稳定版：经过测试team全面的测试，最大限度地避免崩溃和其他问题。差不多每两到三周更新一个小版本，6个星期更新一个大版本。 
beta版：有极小的风险，每周更新，比稳定版提前一个月发布 
Dev版：一或两周更新，经过测试，但仍有bug，为了让用户尽快体验下个版本增加了什么 
Canary版：每日更新，未经过测试或使用，build出来就发布。有自己的配置（文件）和设置选项，可以和其他channel的版本共存。用做报告崩溃和统计数据。 
Other builds：Chromium有持续集成系统，可以到上面下载LGTM(look good to me自认为是好的)的版本。

发布日程和信息。

Blink: http://www.chromium.org/blink 
一个开源项目也有使命：通过科技创新和好公民来改进开放的web。 
从WebKit转换到Blink的工作提示。 
为了推动Web Platform（可理解为为web开发者提供的平台，简单理解即开发标准）的发展，会增加新功能和删除没用的东西。API设计会向着透明、可靠、兼容性的方向发展。 
增加新功能的流程： 
1. 确定你的变更是否需要走这个流程：如果没有影响开放到web的功能则不用；如果你的变更影响微不足道，只要reviewer不反对，可以不走此流程；如果你的变更无法在Blink上实现，请发email给Chromium团队。 
2. 在chromestatus.com上新增一个项，跟踪新功能的状态，等待别人的反馈 
3. 实现新功能 
4. email给blink-dev，等待3个LGTM 
5. 默认启用此新功能 
新API的review会举行邮件讨论。

Blink架构变更： 
Chromium启动时，初衷是尽量减少WebKit的改动，但现在可以做更大规模的改动，不需要担心打断WebKit的使用者。
一个变动是把iframe放到sandboxed进程中，因为和其它WebKit的分支很不同，所以一直delay中。 
另一个变动是改进网络。因为WebKit现有的网络API多数为了旧的Mac系统来设计，很陈旧，多bug。 
最后是把整个DOM做到Javascript里，这回大大加速Javascript访问DOM，但也引起非常大的架构重写，为此也将不再考虑兼容JSC。其它的考虑：

• 让WebCore能多进程地记录历史（现在是单进程同步访问）
• 删除Widget树（这是Mac WebKit1的限制）
• 把WebCore拆成模块
• 尝试把DOM移入Javascript堆
• 增加多核的利用率（html解析、排版、js解析）
• 删除DOM的难理解的部分并做好向后兼容，优化性能和移除复杂性。
• 在Mac平台使用tcmalloc
• 尝试增量或并行排版
• 删除ScriptValue/ScriptState来解决内存泄露，因为只有一个js引擎了。
• 删除自定义的js bindings代码
• 实现DOM3 Events/UI Events 
  已实现的有：
• 替换WebCore的platform代码为sandbox Platform API
• 建议更简单更严格的内部系统，不用再考虑2个js引擎
• 用WebIDL替代WebKitIDL

Chromium项目文化