Dan Morrill | 3cd199f | 2009-11-06 14:04:16 -0800 | [diff] [blame] | 1 | page.title=People and Roles |
| 2 | doc.type=source |
| 3 | @jd:body |
| 4 | <div> |
| 5 | <p>The Android Open Source Project (AOSP) includes individuals working in a variety |
| 6 | of roles. As noted in <a href="{@docRoot}about/philosophy.html">Our |
| 7 | Philosophy</a>, the core AOSP members operate the Android product management |
| 8 | and engineering process. This page describes these roles in a bit more |
| 9 | detail.</p> |
| 10 | <p>Anyone who is interested in exploring and contributing to Android can use the |
| 11 | Android Open Source Project resources. Anyone can join the mailing lists, ask |
| 12 | questions, contribute patches, report bugs, look at submitted patches, and use |
| 13 | the tools. To get started with the Android code, see <a |
| 14 | href="{@docRoot}source/index.html">Get Involved</a>.</p> |
| 15 | |
Dan Morrill | 3cd199f | 2009-11-06 14:04:16 -0800 | [diff] [blame] | 16 | <h2>Contributor</h2> |
| 17 | <p>A "Contributor" is anyone making contributions to the AOSP source code, |
| 18 | including both employees or other affiliates of an AOSP Member, as well as |
| 19 | external developers who are contributing to Android on their own behalf. |
| 20 | There is no distinction between Contributors who are affiliated with an AOSP |
| 21 | Member, and those who are not: all engineers use the same git/gerrit tools, |
| 22 | follow the same code review process, and are subject to the same requirements |
| 23 | on code style and so on.</p> |
| 24 | <p/> |
| 25 | |
| 26 | <h2>Developer</h2> |
| 27 | <p>A "Developer" is an engineer writing applications that run on Android |
| 28 | devices. There is, of course, no difference in skillset between a "Developer" |
| 29 | and a "Contributor"; we simply use "Developer" to help identify our audience. |
| 30 | Since the key purpose of Android is to cultivate an open development platform, |
| 31 | "Developers" are one of the key customers of the Android project. As such, we |
| 32 | talk about them a lot, though this isn't technically a separate role in the |
| 33 | AOSP <i>per se.</i></p> |
| 34 | <p/> |
| 35 | |
| 36 | <h2>Verifier</h2> |
| 37 | <p>"Verifiers" are responsible for testing change requests. After individuals |
| 38 | have submitted a significant amount of high-quality code to the project, the |
| 39 | Project Leads might invite them to become Verifiers.</p><p><i>Note: at this |
| 40 | time, generally Verifiers are the same as Approvers.</i></p> |
| 41 | <p/> |
| 42 | |
| 43 | <h2>Approver</h2> |
| 44 | "Approvers" are experienced members of the project who have demonstrated their |
| 45 | design skills and have made significant technical contributions to the |
| 46 | project. In the code-review process, an Approver decides whether to include or |
| 47 | exclude a change. Project Leads (typically employed by an AOSP Member) choose |
| 48 | the Approvers, sometimes promoting to this position Verifiers who have |
| 49 | demonstrated their expertise within a specific project.</p> |
| 50 | <p/> |
| 51 | |
| 52 | <h2>Project Leads</h2> |
| 53 | <p>Android consists of a number of sub-projects; you can see these in the git |
| 54 | repository, as individual .git files. The AOSP Members generally assign tech |
| 55 | leads or product leads who oversee the engineering for individual Android |
| 56 | projects. Typically these tech leads will be employees of an AOSP Member |
| 57 | company. A Project Lead for an individual project is responsible for the |
| 58 | following:</p> |
| 59 | <ul> |
| 60 | <li>Lead all technical aspects of the project; for example, the project |
| 61 | roadmap, development, release cycles, versioning, and QA.</li> |
| 62 | <li>Ensure that the project is QA-ed in time for scheduled Android platform |
| 63 | releases.</li> |
| 64 | <li>Designate Verifiers and Approvers for submitted patches.</li> |
| 65 | <li>Be fair and unbiased while reviewing changes. Accept or reject patches |
| 66 | based on technical merit and alignment with the Android platform.</li> |
| 67 | <li>Review changes in a timely manner and make best efforts to communicate |
| 68 | when changes are not accepted.</li> |
| 69 | <li>Optionally maintain a web site for the project for information and |
| 70 | documents specific to the project.</li> |
| 71 | <li>Act as a facilitator in resolving technical conflicts.</li> |
| 72 | <li>Be the public face for the project and the go-to person for questions |
| 73 | related to the project.</li> |
| 74 | </ul> |
| 75 | </div> |