Sync inav to Gitea

docs/policies/CODE_OF_CONDUCT.md

@@ -0,0 +1,49 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include but are not limited to:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the overall community
+
+Examples of unacceptable behavior include but are not limited to:
+
+* The use of sexualized language or imagery, and sexual attention or advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others’ private information, such as a physical or email address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+* Acts of unacceptable behavior on other public resources outside of but in relation to this project
+
+## Our Responsibilities
+
+Project maintainers and community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
+
+Project maintainers and community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+[homepage]: http://contributor-covenant.org

docs/policies/CONTRIBUTING.md

@@ -0,0 +1,23 @@
+# Issues and Support.
+
+Please remember the issue tracker on github is _not_ for user support.  Please also do not email developers directly for support.  Instead please use IRC or the forums first, Also read through the wiki for guidance. Then if the problem is confirmed create an issue that details how to repeat the problem so it can be investigated.
+
+Issues created without steps to repeat are likely to be closed.  E-mail requests for support will go un-answered; All support needs to be public so that other people can read the problems and solutions.
+
+Remember that issues that are due to mis-configuration, wiring or failure to read documentation just takes time away from the developers and can often be solved without developer interaction by other users.
+
+Please search for existing issues *before* creating new ones.
+
+When submitting an issue the general rule is to include:
+
+1. What is your setup and a detailed explanation of the issue,  also include last working version of INAV. 
+1. status dump from cli. 
+1. bootlog dump from cli. 
+1. dump dump from cli. 
+1. BLACKBOX log of the issue. 
+
+# Developers
+
+Please refer to the development section in the `docs/development` folder.
+
+

docs/policies/NEW_HARDWARE_POLICY.md

@@ -0,0 +1,75 @@
+# INAV Hardware Policy
+
+## General
+
+To prevent explosive growth of different target and feature count and ensure reasonable quality and usability of the firmware the following policy is mandatory for all new hardware additions (including variants of the same target).
+
+## Definitions
+
+"Target" - part of the source code responsible for providing a new build artifact (hex-file).
+
+"Hardware" - physical hardware requiring support from firmware side.
+
+"Requester" - manufacturer or community member seeking addition of new hardware or target
+
+## New target additions
+
+New targets are accepted into INAV code if any of the following conditions is satisfied:
+
+1. Requester is a manufacturer of the hardware or an affiliated community member. Requester provides specs, schematics and production samples are provided to at least two core developers. In this case the new target becomes part of official INAV release.
+
+2. Requester is a community member not affiliated with a manufacturer of the hardware. Requester provides board samples to at least one core developer and the target is already supported in official Cleanflight or Betaflight firmware. In this case the new target may or may not become part of official release based on the decision made by core developers.
+
+3. The new target must meet the following minimal requirements:
+
+  * On-board sensors include at least the IMU (gyroscope + accelerometer)
+  * At least 3 hardware serial ports are available with both TX and RX pads. 2 serial ports may be accepted if there is an onboard serial RX.
+  * At least 512K of firmware flash memory and at least of 128K of RAM available
+  * At least one I2C bus broken out (SCL and SDA pins) and not shared with other functions 
+
+## New hardware support
+
+For the hardware which does not require a new target, but still require support from the firmware side the following rules apply:
+
+1. Requester is a manufacturer of the hardware or an affiliated community member. Requester provides specs and production samples for the unsupported hardware to at least two core developers.
+
+2. Requester is a community member not affiliated with a manufacturer of the hardware. Requester provides hardware samples to at least one core developer and the firmware support already exists in official Cleanflight or Betaflight firmware.
+
+## Using own hardware exception
+
+If one of the core developers has the hardware in possession they may opt in and submit support for it anyway. In this case the support is not official and may not be included in official releases.
+
+## Providing samples to developers
+
+1. Hardware provided to the developers would be considered a donation to the INAV project. Under no circumstances developer will be obliged to return the hardware or pay for it.
+
+2. Requester bears all the costs of the hardware, delivery and VAT/customs duties. Hardware manufacturer also assumes the responsibility to provide up to date specs, documentation and firmware (if applicable).
+
+3. Before sending samples the Requester should reach out to developers and agree on specific terms of implementing support for the unsupported hardware. Developers may place additional requirements on a case by case basis and at their sole discretion.
+
+4. The new target and new hardware policies do not apply in the following cases. Developers may still chose to apply the "own hardware exception" at their own discretion.
+
+  * if the receiving developer has to bear part of the costs (and is not reimbursed by the sender)
+  * if the hardware provided does not behave according to specs (different communication protocol, undocumented or incorrect CPU pin mappings, damaged or dead on arrival) and the sender doesn't provide a way to resolve the problem (up to date docs, new firmware etc).
+  * if the hardware was sent without reaching out to developers and agreeing on the terms first.
+
+5. It's advised to provide more than one sample to avoid issues with damaged or dead on arrival hardware.
+
+## Implementing support for the new target or hardware
+
+1. Pull request to add the new target or hardware may be authored by a contributor outside INAV team or by one of the core developers. 
+
+2. There is no obligation to accept a pull request made by an outside contributor. INAV team reserves the right to reject that pull request and re-implement the support or take that pull request as a baseline and amend it.
+
+3. INAV team reserves the right to reject the new target or hardware or remove the support for an unforeseen reason including, but not limited to violation of [INAV Code of Conduct](CODE_OF_CONDUCT.md) by the manufacturer or an affiliated outside contributor.
+
+## Guidelines on contacting the team
+
+1. Requester is advised to open a feature request to add support for certain hardware to INAV by following [this link](https://github.com/iNavFlight/inav/issues/new/choose)
+
+2. After opening a feature request, Requester is advised to contact the core development team via [Discord](https://discord.gg/peg2hhbYwN) mentioning the open feature request and communicate with developer team via email to arrange hardware and specifications delivery.
+
+
+## See also
+[Hardware Design Guidelines](https://github.com/iNavFlight/inav/wiki/Hardware-Design-Guidelines)
+