Project Standards

You can view a copy of this as HTML here (Might not be up-to-date. Always refer to this wiki.)

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.
• Correct your mistakes. If you made a mistake, be it a typo, wrong authorship, or an error in code, correct it.
• Use our Code Review system. Upload your commits there for us to review your changes, suggest improvements and give our opinion about it. We will try to do that as soon as possible.
• Write clear commit messages if necessary. If a commit is not self-explanatory (self-explanatory commits include translations, correction of grammar/typos, …) or does require 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 really necessary. It's good to create a backup branch before doing so.

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

• Use AOSP-conforming code style.
• Avoid trailing whitespaces
• Use the indentation type of the file that you are editing. If Tabs are used, do so as well. Although we do prefer spaces over tabs, you are not required to do so.
• Do not exceed the 80-character line length limit if possible

For participants who have full access (read, write, bypass/admin) on our Code Review server, following rules apply:

• Do not bypass code review for changes to the platform source (repositories such as device, kernel and vendor trees are excluded)
• Do not abandon others’ changes without an explanation
• At least one reviewer gives +2 Code-Review, additionally at least one reviewer gives +1 Code-Review and at least one reviewer gives +1 Verified before submitting. Example: One reviewer does +1, another one +2 +1.
• Set the Submit Type to Rebase if Necessary when creating a new project.
• Always push to Gerrit if the project is mirrored to GitHub unless the server is not reachable or out of function and your change has priority (prioritized changes are critical bugfixes, crash fixes, build error fixes, etc.), however, before doing so talk to your colleagues about the change or push it to a separate branch/repository before pushing to the main branch. As soon as the server is reachable or working again, push your changes to Gerrit as soon as possible because Gerrit will overwrite them on GitHub on startup.

For upstream merges following rules apply (these have higher priority than any of the rules and standards above. If one of the following rules would violate any of the rules and standards above this, the violated part of the affected rule/standard is not valid for upstream merges):

• Push upstream merges on top of the current HEAD bypassing Code Review. Use a separate branch for that (e. g. staging/XOS-...) if appropriate.
• Make sure you built the ROM along the upstream changes at least once and tested for general functionality. Fix issues as soon as possible.

Standards in the Team

When criticizing, do it 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 he is pointing out your mistakes.

Official releases

Official release builds must be built on one of the team members’ or authorized maintainers’ machines 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 have been included without prior permission/approval.

Hierarchy of the 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 additionaly hierarchy.

The core team consists of following people:

• Neil Agarwal - Project Founder, Lead Developer and Authorized Maintainer (not actively contributing)
• Simão Gomes Viana - Project Founder, Lead Developer and Authorized Maintainer
• Harsh Shandilya - Lead Developer and Authorized Maintainer (not actively contributing)
• Hunter Ashton - Code Review Server Maintainer and Developer (not actively contributing)
• Kees Sonnema - Web Developer, Graphics-/Web Designer
• Jeremiah Weaver - Graphics Designer and Animation Creator
• Sewer - Graphics Designer

The so-called "XOS Family" consists of the core team, some testers, contributors, influential people and more:

• Stefan Pruneanu - Veteran OnePlus 2 tester
• Daniel Villalobos - Veteran OnePlus 2 tester
• Leon - Veteran Ex-OnePlus 2 tester
• Paul Larsen - Veteran Ex-OnePlus 2 tester, beer lover
• Christian - Veteran Ex-OnePlus 2 tester
• Yousvel Lormeus - Veteran Ex-OnePlus 2 tester
• Arron Williams - Veteran OnePlus 2 tester and Tim Cook lover
• ...and more

Lead Developers should have read/write/bypass permissions on the Code Review server and be listed on the list of people on the GitHub organization.

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

Contributors are people who do changes from outside.

Official Maintainers have the responsibility of frequently (= as much as possible) maintaining device-specific trees. Usually official maintainers are also authorized maintainers and must fulfill specific prerequisites. We reserve the right to revoke authorized maintainership at any time. Official maintainers may choose to let someone else maintain e. g. a thread in the XDA Forums.

The team as a whole consists of the core team, platform and app developers as well as authorized maintainers.

Currently authorized/official maintainers:

• Neil Agarwal: Nexus 5 (hammerheadcaf), Motorola Moto G4 2016 (athene)
• Simão Gomes Viana: OnePlus 2 (oneplus2), OnePlus 5/5T (cheeseburger/dumpling)
• Harsh Shandilya: Yu Yunique (jalebi), OnePlus 3 (oneplus3), Pixel 2 XL (walleye)

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.

As upstream revision for AOSP, we use one of the latest international 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.