Code Of Conducts
Mirror of: ElementOS Guidelines | GitHub
To become a maintainer of ElementOS
Before you apply to add your device into our list of official devices and servers, you should know a few things:
Any failure in following the instructions given below will make you unfit for the maintainership. No questions asked.
1 - You must own the device. Blind and untested builds aren't allowed. The devices that have minimal hardware difference from yours (ex: Pixel 3 - Pixel 3 XL) are allowed to be maintained, as long as you maintain your own device too.
2 - You must have knowledge of git.
3 - You must create and maintain an unofficial builds and make sure that the build is stable before applying. The context of stability may differ for different devices, so explain regarding any exceptions.
4 - You must have your device sources available publicly with proper authorship for each commit.
5 - You must show the real device sources being used.
6 - Your device must be in accordance with the Device Requirements.
Maintainers conduct notes:
The maintainers:
1 - MUST NOT get involved in arguments or resort to insults, or use hateful words, personal attacks or any other verbal or nonverbal action that is considered detrimental towards the creation of a positive environment for the team.
2 - MUST upload:
2.1 - All theirs device sources should be fully buildable
2.2 - Changelogs for each build. These MUST be user-friendly, simplifying the changes for the average user
2.3 - MUST test every build. Each build must be thoroughly vetted by the maintainer before it is released, and all hardware and software functionalities must be tested before a build is released.
2.3 - Must maintain authorship of git commits that are pushed, this is a mandatory requirement for all repositories. Force-pushes are acceptable, but try to keep them to a minimum.
3 - MUST NOT add:
3.1 - Any features in their device specific packages, eg. configpanel, XiaomiParts, etc., like KCAL, force Camera API2, etc.
Features that are device specific and are available in stock firmware are allowed.
3.2 - Playground or anything else related to getting Pixel-like features that aren't available from the ROM sources - only GoogleCamera and ARCore are acceptable.
3.3 - Any Google applications that aren't available from ROM sources - again, only GCam is acceptable, but please ensure that you use a reliable source and that the device has proper support for them.
3.4 - Any stock firmware camera app. Once again GoogleCamera still acceptable as per se.
4 - About Magisk, the maintainers MUST NOT:
4.1 - Do any heavy software modification that may lead to Magisk working properly. If possible, recommend to users to stop using Magisk if it's not working properly.
Device Requirements
-
The device may have SELinux Enforcing to release builds.
-
The device must have complete hardware compatibility corresponding to the stock ROM, i.e. if IR blaster works on the stock ROM, it must work on BR builds. Only VoLTE is allowed to be ignored, so are NFC payment methods.
-
The device must not include any unused overlays and packages. This includes, but is not limited to, packages not being built, packages that don't work, obsolete packages, placebo 'tweaks' or any packages that will include unnecessary and/or unwanted features
-
If the device has Full Disk Encryption (a.k.a FDE) mustn't ship/build the Google Play System Updates/Updatable APEX, as the same only works on devices that have File-Base Encryption (FBE) with the device encrypted. The same is applicable for kernel 3.18 or devices with older kernel versions.
-
The device mustn't have the need for a lot of patches, and if so, it must be in accordance with the following listing below.
-
If there are commits that are needed in repos other than the device-specific ones, they must:
-
Be necessary for the device to build, boot, or even to have a device function working properly (e.g. Fingerprint On Display).
-
Have proper authorship.
-
Be as minimal and polished as possible.
-
Kernel Guidelines:
The following aren't allowed to be added into kernel sources:
- OC/UC/UV, not mattering if it's for display, GPU or CPU.
- Any changes regarding charging voltages.
- Magisk/App Blocker without the need to block toxic modules like FDE.AI. Blocking TikTok/any similar app isn't allowed either.
- Boeffla Wakelock Blocker. Wakelocks exists for a reason. The removal of such ones that are harm for the device is allowed.
- Scheduler restrictions doesn't apply, however that doesn't mean we don't look/care about all possible crappy schedulers you pushed. The same applies for I/O, TCP Schedulers (Backports don't apply to restrictions).
- Prefer giving users less switches to tinker.
Some suggestions would be to:
- Prefer to use init scripts to set default values.
- Changing the default tunable value in the kernel.
- Hardcoding default values isn't recommended.