• Home
  • Line#
  • Scopes#
  • Navigate#
  • Raw
  • Download
1<!--
2   Copyright 2010 The Android Open Source Project
3
4   Licensed under the Apache License, Version 2.0 (the "License");
5   you may not use this file except in compliance with the License.
6   You may obtain a copy of the License at
7
8       http://www.apache.org/licenses/LICENSE-2.0
9
10   Unless required by applicable law or agreed to in writing, software
11   distributed under the License is distributed on an "AS IS" BASIS,
12   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
13   See the License for the specific language governing permissions and
14   limitations under the License.
15-->
16
17# People and Roles #
18
19The Android Open Source Project (AOSP) includes individuals working in a variety
20of roles. As noted in [Our Philosophy](philosophy.html), Google is responsible for Android product management
21and the engineering process for the core framework and platform; however,
22the project considers contributions from any source, not just Google. This
23page describes the kinds of roles that interested parties can take on.
24
25Anyone who is interested in exploring and contributing to Android can use the
26Android Open Source Project resources. Anyone can join the mailing lists, ask
27questions, contribute patches, report bugs, look at submitted patches, and use
28the tools. To get started with the Android code, see [Get Involved](/source/index.html).
29
30## Contributor ##
31
32A "Contributor" is anyone making contributions to the AOSP source code,
33including both employees of Google or other companies, as well as external
34developers who are contributing to Android on their own behalf.  There is no
35distinction between Contributors who are employed by Google, and those who are
36not: all engineers use the same tools (git, repo, and gerrit),
37follow the same code review process, and are subject
38to the same requirements on code style and so on.
39
40## Developer ##
41
42A "Developer" is an engineer writing applications that run on Android
43devices. There is, of course, no difference in skillset between a "Developer"
44and a "Contributor", but AOSP uses "Developer" to distinguish between
45engineers using the platform and those contributing to it. Developers are
46(along with end users) the "customers" of the platform that the Contributors
47create. As such, we talk about Developers a lot, though this isn't technically
48a separate role in the AOSP per se.
49
50## Verifier ##
51
52"Verifiers" are responsible for testing change requests. After individuals
53have submitted a significant amount of high-quality code to the project, the
54Project Leads might invite them to become Verifiers. *Note: at this
55time, generally Verifiers are the same as Approvers.*
56
57## Approver ##
58
59"Approvers" are experienced members of the project who have demonstrated their
60design skills and have made significant technical contributions to the
61project. In the code-review process, an Approver decides whether to include or
62exclude a change. Project Leads (who are typically employed by Google) choose
63the Approvers, sometimes promoting to this position Verifiers who have
64demonstrated their expertise within a specific project.
65
66## Project Leads ##
67
68Android consists of a number of sub-projects; you can see these in the git
69repository, as individual .git files. Tech Leads are senior Contributors who
70oversee the engineering for individual Android projects. Typically these tech
71leads will be Google employees.  A Project Lead for an individual project is
72responsible for the following:
73
74- Lead all technical aspects of the project; for example, the project roadmap,
75  development, release cycles, versioning, and QA.
76
77- Ensure that the project is QA-ed in time for scheduled Android platform
78  releases.
79
80- Designate Verifiers and Approvers for submitted patches.
81
82- Be fair and unbiased while reviewing changes. Accept or reject patches
83  based on technical merit and alignment with the Android strategy.
84
85- Review changes in a timely manner and make best efforts to communicate
86  when changes are not accepted.
87
88- Optionally maintain a web site for the project for information and
89  documents specific to the project.
90
91- Act as a facilitator in resolving technical conflicts.
92
93- Be a public face for the project and the go-to person for questions
94  related to the project.
95
96