Skip to content

Latest commit

 

History

History
61 lines (31 loc) · 4.38 KB

maintainers_code_of_conduct.md

File metadata and controls

61 lines (31 loc) · 4.38 KB
Raw

Maintainers conduct notes:

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The maintainers:

  • 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.

  • MUST upload:

    • All theirs device sources on AOSPK-Devices organization. It goes without saying that these should be fully buildable. Using external repos for build releases aren't allowed, unless they're from LineageOS/TheMuppets organization(s). Exceptions may be open if only it's absolutely necessary.

    • Changelogs for each build. These MUST be user-friendly, simplifying the changes for the average user who aren't aware of things like Safetynet or color calibration, but would like to know what has changed since the last update.

  • MUST test every build before sending an OTA update to users. 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. Releasing untested builds can (and will) lead to your maintainership being revoked.

  • 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.

  • In the event of any disagreements between maintainers, sort them out via direct messages on Telegram or XDA. Do not take your fights to our chats, approach the administration if you want something sorted out quickly. The same is valid for our public chat. "We don't do this here".

  • MUST NOT add:

    • Playground or anything else related to getting Pixel-like features that aren't available from the ROM sources - only GoogleCamera and ARCore are acceptable.

    • Any Google applications that aren't available from ROM sources - again, only GoogleCamera is acceptable, but please ensure that you use a reliable source and that the device has proper support for them.

    • Any stock firmware app. Once again GoogleCamera is acceptable per se, so is the camera app from the stock firmware itself, only, if fully functional.

  • MUST use the same device common-tree if a device is already using the same repository. Different branches are not allowed. In case the maintainer doesn't want to use the same common-tree, the only option remaining will be to fully decommonize the device in question. The same goes for the vendor repositories.

  • MUST NOT enable the Always On Display in case the device has a LCD panel.

  • MUST, for kernels, follow our Kernel Guidelines.

  • About Magisk, the maintainers MUST NOT:

    • 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.

    • Do any modifications that may lead to Magisk not work, as per the Kernel Guidelines.

  • If you're a maintainer of an A/B partition or a dynamic partition device, you MUST NOT ship TWRP prebuilt.

  • About proprietary files, the maintainers MUST:

    • Have a working proprietary files list and extraction script that inherits the global extraction script (located in tools/extract-utils) in their device tree (or device tree dependencies).

    • Use only the script generated vendor repositories for build.

    • Specify the source of any un-pinned (default) proprietary files.

    • Pin any proprietary files not sourced from the default specified source and have a short comment specifying their source.

  • About Translations, the maintainers MUST:

    • Move all required strings for any custom packages for device (XiaomiParts, OnePlus Settings, Doze) in devicesettings-custom repository.

  • About Sepolicy Rules, the maintainers MUST NOT:

    • Ignore Sepolicy Neverallows, only if is for testing purposes.

If any of these rules are broken, the administration will take direct action against the maintainer without prior warning.