Mirror/inav
1
0
Fork 0
mirror of https://github.com/iNavFlight/inav.git synced 2025-07-24 16:55:29 +03:00
Code Issues Wiki Activity

Add clarification that agreement between dev and vendor must be reached before sending the hardware

Browse source
This commit is contained in:
Konstantin Sharlaimov 2019-06-04 13:28:14 +02:00
parent fb70c4e921
commit 77ab7794cf
1 changed files with 6 additions and 3 deletions
Download patch file Download diff file Expand all files Collapse all files

9
docs/policies/NEW_HARDWARE_POLICY.md
View file

@ -36,11 +36,14 @@ If one of the core developers has the hardware in possession they may opt in and
2. Manufacturer or community member providing the hardware 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. 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.
3. Before sending samples the providing party 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 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.
4. It's advised to provide more than one sample to avoid issues with damaged or dead on arrival hardware.
5. It's advised to provide more than one sample to avoid issues with damaged or dead on arrival hardware.