Project Standards

Introduction

As a quickly growing project, a lot of responsibility and care has to be taken. We want to unify all our standards in one place, letting all participants, whether as team member, contributor or leader, follow a set of rules in order to strive for a long-living professional-looking project with a friendly and organized atmosphere.

Contribution standards

For team members as well as contributors from outside there are a few standards that should be met on all changes:

• Keep authorship as much as possible. If you are cherry-picking commits from other projects, make sure you don’t change the author. Add a Co-Authored-By label if you think someone deserves extra credit.
• Correct your mistakes. If you made a mistake, be it a typo, wrong authorship, or an error in code, correct it.
• Write clear and concise commit messages if necessary. If a commit is not self-explanatory (self-explanatory commits include translations, correction of grammar/typos, …) or requires further explanation in order to be understood, explain in the commit message body what you did, why you did it, what it affects and how you tested it. That allows everyone to better understand what a commit does.
• Do not force push unless it is absolutely necessary. It's mandatory to create a backup branch or tag before doing so to preserve all source code. An exception to this rule is when a branch is in "pre-development" and not ready for public use yet.

As for the code style, following code style standards apply:

• Use AOSP-conforming code style. For Kotlin, use Kotlin Official code style (reformat in IntelliJ).
• Avoid trailing whitespaces and excessive use of blank lines
• Use the indentation type of the file that you are editing. If Tabs are used, do so as well. For new files, follow the conventions of existing files or of the language you are currently writing in. In case there is no convention and there is no other way of finding out the correct indentation type and you can't decide what to use, use 4 spaces.
• Do not exceed the 120-character line length limit if possible.

For admins, project owners/maintainers following rules apply:

• Do not reject others’ changes without an explanation

Standards in the Team

When criticizing, do so constructively. Don't say random things that don't make sense. Talk about things you don't like in a friendly manner. Try finding a solution to problems instead of complaining about it all the time. When pointing out a mistake, do so in a reasonable and understandable matter. Everyone makes mistakes and don’t hate someone just because they are pointing out your mistakes.

Official releases

Official release builds must be built on one of the team members’ or authorized maintainers’ systems and must represent the exact state of the public sources as of the point of time the build was launched. This measure is taken to make sure no unapproved or unwanted changes are included without prior permission/approval and to ensure reproducible builds.

Team, Contributors and Maintainers

Note on the change of Founders: Instead of only having one founder and additional co-founders, all founders are called the same. This change is to keep consistency and avoid additional hierarchy.

The core team consists of following people:

• Simão Gomes Viana - Founder, Developer, Coordinator, Financial Contributor and Authorized Maintainer
• Noah Anleitner - Developer, Authorized Maintainer
• Beru Stella Krugermeier - Developer, Authorized Maintainer

We want to thank and credit following people for their great support and help:

• Neil Agarwal - Founder, Authorized Maintainer (does not contribute to code anymore)
• Harsh Shandilya - Authorized Maintainer, former team member
• Daniel Villalobos - Financial Contributor, Coordinator
• Stefan Pruneanu - Veteran OnePlus 2 tester
• Leon - Veteran OnePlus 2 tester
• Paul Larsen - Veteran OnePlus 2 tester, beer lover
• Christian - Veteran OnePlus 2 tester
• Yousvel Lormeus - Veteran OnePlus 2 tester
• Arron Williams - Veteran OnePlus 2 tester
• Kees Sonnema - Web Developer, Graphics-/Web Designer, former team member
• Jeremiah Weaver - Graphics Designer and Animation Creator (old boot animation design), former team member
• @Sewer56 - Graphics Designer, former team member

Authorized Maintainers should have read/write permissions on their device-specific trees.

Contributors who contribute to the project from outside.

Financial Contributors are part of the team and help or have helped pay for infrastructure.

Official Maintainers have the responsibility of frequently maintaining device-specific trees. Official maintainers must fulfill specific prerequisites which are solely at our discretion. We reserve the right to revoke authorized/official maintainership at any time.

Upstream

We base our work off the Android Open Source Project. From 8.0 on, merging CAF is not required and should only be done where necessary. From 10.0 on, CAF shall not be merged into platform repositories (only device-specific, CAF-specific or external ones can have CAF merged in).

We use our scripts in external/xos that are available as the commands mergeUpstream, mergeAospUpstream, etc. to do upstream merges. mergeUpstream merges the repositories given in the upstream attribute in the manifest.

As upstream revision for AOSP, we use one of the latest tags in the format of android-..._r…

As upstream revision for CAF, on 7.1, we use the LA.UM line of the latest MSM SD800-series SoC. From 8.0 onwards, we use the LA.UM tags of the latest SoC.

The manifest is based off AOSP.