Chromium是一个开源的浏览器项目。官方站点列出了很多文档。
官网最值得学习的地方：很多指引写得非常仔细，能以老师教导学生的态度去叙述怎样工作，而不是为了写文档而写文档，比如“不要害怕问问题。总有人会在IRC上帮到你”。多数文章写得非常好非常凝练，没法抽取主要信息。全文翻译又太耗时，不如直接看原文。
所以仅仅须要筛选出实用的信息。而不用自己总结什么。
尽管一些文档会偏旧，但胜在齐全，特别是工作规范类的文档，能为团队协作做出良好的引导。
文档主要分类例如以下：
1. 开发相关：怎样checkout、编译、调试、开分支、提交代码、发review和review指引、成为committer及其职责说明、学习路径指引、开发工具使用指引、以功能划分模块的架构设计、代码规范。
2. 測试相关： 报bug指南、bug处理流程、bug系统的使用、各种自己主动化測试系统的使用。
3. 交流：通讯工具、信息公布blog、术语表、wiki、文档索引、在线的代码查看和搜索站点。
4. 项目管理：宗旨、公布日程、设计理念、演进方向、开发计划管理。
开发相关：
对开发人员。有一个文档汇总的页面http://dev.chromium.org/developers，页面下方是全部文档的索引。
PPT总结。
需求点状态。在这里能看出开发的方向和进度。（各种方向的都有，非常难自己总结，偏H5的多）。
信息公布的blog。
准备好代码：
- 必须遵守代码规范。
- 必须经过測试，一般是单元測试。 代码的量级合理。
- 大量的代码无法非常快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。由此得到LKGR（Last Known Good Revision）。会公布在http://chromium-status.appspot.com/lkgr。
bug系统：
bug列表：https://code.google.com/p/chromium/issues/list。此系统是自己开发的，列表带有ID、优先级、发现bug的版本号、迭代记录、解决的channel（稳定版或beta版）、分类、状态、owner、概要和标签、操作系统、修改日期。页面有链接转向：报bug向导、高级搜索。搜索提示（技巧，如特别的keyword，条件搜索，附件搜索等)，自行关注某类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