├── README.md ├── how_to_apply.md ├── developers └── requirements.md └── maintainers └── requirements.md /README.md: -------------------------------------------------------------------------------- 1 | # Recruiting # 2 | --- 3 | These requirements are for developers that want to apply to become device maintainers or for general developer "status" but don't know what's expected of them or may have questions about how our project differs from others. 4 | --- 5 | 6 | This guide assumes that the developers applying already know how to sync and compile Android, and have a basic understanding of linux. If 7 | the developers applying don't have a basic understanding of linux and Android, please don't bother applying. 8 | 9 | - __[Requirements for maintainers](https://github.com/DirtyUnicorns/Notices/blob/master/maintainers/requirements.md)__ 10 | 11 | - __[Requirements for developers](https://github.com/DirtyUnicorns/Notices/blob/master/developers/requirements.md)__ 12 | 13 | - __[How to apply](https://github.com/DirtyUnicorns/Notices/blob/master/how_to_apply.md)__ 14 | -------------------------------------------------------------------------------- /how_to_apply.md: -------------------------------------------------------------------------------- 1 | --- 2 | __How to apply__ 3 | --- 4 | 5 | 1. Before contacting anyone on the committee, ALL of the requirements for either maintainer or developer must be met. If there are any questions regarding them, you can reach out but maintainership will not be considered without meeting the requirements. 6 | 7 | 2. Contact one of the committee members using either on Telegram. When contacting the committee, you should link your personal GitHub and/or device specific repos (if applying for maintainer) and explain why you think you should be a DU developer/maintainer. Think of this like a job application, the information should be provided before coming in for an interview. 8 | 9 | 3. __DO NOT SPAM__ the committee members. They all have real lives and can get busy. 10 | 11 | 12 | ## Recruiting committee ## 13 | 14 | ([Telegram unofficial support chat](https://t.me/UnofficialDirtyUnicornsSupport)) 15 | 16 | - Josh Correll ([Telegram](https://t.me/jbats00)) 17 | 18 | - William Bellavance ([Telegram](https://t.me/Flintman)) 19 | 20 | - Nathan Chancellor ([Telegram](https://t.me/nathanchance)) 21 | -------------------------------------------------------------------------------- /developers/requirements.md: -------------------------------------------------------------------------------- 1 | ## Requirements ## 2 | 3 | - The developer must have a good understanding of Linux. 4 | 5 | - The developer must have at least a basic knowledge of either Java or C / C + + programming. 6 | 7 | - The developer must know how to use Gerrit correctly. This includes but is not limited to pushing commits, rebasing commits, reviewing commits, pushing commits in draft, assigning proper groups for further testing and organizing large number of commits in topics. 8 | 9 | - The developer must know how to use Git correctly. This includes but is not limited to amending commits, rebasing commits, cloning repos, pushing commits/repos, merging and pulling commits accordingly. 10 | 11 | - The developer must know how to use JIRA correctly. This includes but is not limited to reviewing reports and replying accordingly to users. The developer will also be required to handle any platform specific issues on their own. If the developer needs assistance then assistance will be provided. 12 | 13 | - The developer must display proper authorship and commit history in all non-original commits that are pulled from other sources. This is not limited to just past commits but future commits as well that are pushed to both github and gerrit. Authorship is important. 14 | 15 | - The developer must be able to write clear and descriptive commit messages with both normal commits and reverts, documenting exactly what they are changing and why. 16 | 17 | - The developer must have a clear and good understanding of AOSP. 18 | 19 | - The developer must be able to troubleshoot platform specific issues. This includes but is not limited to reading logcats, radio logs, dmesg and JIRA bug reports. 20 | 21 | - The developer must demonstrate the ability to work well with others. This includes but is not limited to working with fellow DU developers. DU developers often collaborate with other projects and developers. 22 | -------------------------------------------------------------------------------- /maintainers/requirements.md: -------------------------------------------------------------------------------- 1 | ## Required skills ## 2 | 3 | - The maintainer must own the device and do all their own testing. Blind building is not acceptable. 4 | 5 | - The maintainer must have an account on Github, Gerrit and JIRA. 6 | 7 | - The maintainer must know how to use Gerrit correctly. This includes but is not limited to pushing commits, rebasing commits, reviewing commits, pushing commits in draft, assigning proper groups for further testing and organizing large number of commits in topics. 8 | 9 | - The maintainer must know how to use Git correctly. This includes but is not limited to amending commits, rebasing commits, cloning repos, pushing commits/repos, merging and pulling commits accordingly. 10 | 11 | - The maintainer must know how to use JIRA correctly. This includes but is not limited to reviewing reports and replying accordingly to users. The maintainer will also be required to handle any device specific issues on their own. If the maintainer needs assistance then assistance will be provided. 12 | 13 | - The maintainer must display proper authorship and commit history in all non-original commits that are pulled from other sources. This is not limited to just past commits but future commits as well that are pushed to both github and gerrit. Authorship is important. 14 | 15 | - The maintainer must write clear and descriptive commit messages with both normal commits and reverts, documenting exactly what they are changing and why. 16 | 17 | - The maintainer must do unofficial builds on [Telegram](https://t.me/UnofficialDirtyUnicornsSupport) for at least a month to show off how they handle users and issues. 18 | 19 | 20 | 21 | ## Device requirements ## 22 | 23 | - The device must be buildable. 24 | 25 | - The device must not have any outside dependencies. All dependencies must be open sourced and ready to be forked with proper authorship/commit history. 26 | 27 | - The device must enforce SELinux. 28 | 29 | - The device's kernel must be up to date with the latest patches from [kernel.org](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/). If you are unsure of how to do this, check out [android-linux-stable](https://github.com/android-linux-stable) or contact [Nathan Chancellor](https://nathanchance.me). 30 | 31 | - The device must have working audio. This includes but is not limited to in-call audio, speaker phone, headphone jack and bluetooth audio. 32 | 33 | - The device must have working phone calls and data. This includes, but is not limited to, to being able to receive and make phone calls, download files from the internet, stream video calls and use different sim slots if applicable. 34 | 35 | - The device must have a working hotspot if applicable. This includes, but is not limited to, WiFi and USB tethering. 36 | 37 | - The device must have a working camera. Not only do we require the the camera to work but the AOSP camera needs to be fully functional because that's what we ship. We do not ship with any other camera, snapdragon or OEM. This includes but is not limited to having the camera take pictures with both the back camera and front facing camera if applicable and video recording in all definitions. 38 | 39 | - The device must have working bluetooth. This includes but is not limited to be transferring files and receive them. 40 | 41 | - The device must have working NFC if applicable. This includes but is not limited to being able to beam files and receive them. 42 | 43 | - The device must have a working fingerprint scanner if applicable. 44 | 45 | - The device must have a working proximity sensor. 46 | 47 | - The device must have working WiFi. 48 | 49 | - The device must include all device specific and DU overlays. This includes but is not limited to ambient display, LED and hardware keys if applicable. 50 | 51 | - The device must not include any unused overlays. This includes but is not limited to packages not being built, obsolete packages or placebo build.prop 'tweaks'. 52 | 53 | - If commits are needed in repos other than the device specific ones, they must: 54 | 55 | - Be necessary for the device to build, boot, or otherwise function. 56 | 57 | - Have proper authorship. 58 | 59 | - Be pushed to Gerrit under one topic for easy review. 60 | 61 | - Be as minimal as possible. Do NOT merge other ROMs' repos into DU ones. 62 | --------------------------------------------------------------------------------