arduino/esp8266
1
0
Fork 0
mirror of https://github.com/esp8266/Arduino.git synced 2025-04-19 23:22:16 +03:00
Code

Update and rename Policy.md to POLICY.md

Browse Source
This commit is contained in:
Develo 2017-09-26 14:52:46 -03:00 committed by Ivan Grokhotkov
parent 32ec86e7de
commit 23ceb828c5
1 changed files with 9 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
Policy.md → POLICY.md
View File

@ -1,19 +1,22 @@
This document describes rules that are in effect for this repository, meant for handling issues by contributors in the issue tracker and PRs. This document describes rules that are in effect for this repository, meant for handling issues by contributors in the issue tracker and PRs.
# Opening New Issues # Opening New Issues
1. The issue tracker is precisely that: a tool to track issues in the core code, and not a discussion forum. Opening an issues means that a problem has been found in the core code, and that it should be addressed by a contributor. 1. The issue tracker is precisely that: a tool to track issues in the core code, and not a discussion forum. Opening an issues means that a problem has been found in the core code, and that it should be addressed by a contributor.
2. Questions of type "How do I..." or "Can you please help me with..." or "Can the ESP do..." won't be handled here. Such questions should be directed at a discussion forum, like esp8266.com or stackoverflow. All issues of this type will be closed with a simple reference to the policy. Example: 2. When opening an issue, a template is presented with fields to fill out. The requested information is important. If the template is ignored, or not enough info about the issue is provided, the issue may be closed due to lack of info. Example:
* Using WifiMulti and FS crashes with error. Why? (no basic info, no IDE settings, no sketch provided)
3. Questions of type "How do I..." or "Can you please help me with..." or "Can the ESP do..." won't be handled here. Such questions should be directed at a discussion forum, like esp8266.com or stackoverflow. All issues of this type will be closed with a simple reference to the policy. Example:
* how do I connect to wifi * how do I connect to wifi
* how do I connect two ESPs * how do I connect two ESPs
* can I send http data over a public network * can I send http data over a public network
3. Issues that are obviously user error, programming language errors, lack of knowledge or experience with the use semantics of the core libs, or similar, will be closed with a reference to the policy. Examples: * my wiring/project/code doesn't work, help!
4. Issues that are obviously user error, programming language errors, lack of knowledge or experience with the use semantics of the core libs, or similar, will be closed with a reference to the policy. Examples:
* sketch crashes due to a char[] in it that is not null terminated * sketch crashes due to a char[] in it that is not null terminated
* trying to use yield/delay, or libs that use yield/delay, from inside async callbacks * trying to use yield/delay, or libs that use yield/delay, from inside async callbacks
* Use of new/malloc without matching delete/free (mem leak) * Use of new/malloc without matching delete/free (mem leak)
4. Issues about topics already handled in the documentation will be closed in a similar manner. Example: 5. Issues about topics already handled in the documentation will be closed in a similar manner. Example:
* can't flash with error espcomm failed * can't flash with error espcomm failed
5. Issues must be provided with a minimalist sketch. Issues with an incomplete sketch, or a huge sketch, will be closed. Maximum effort must be put forth by the person opening the issue to reduce the relevant code that reproduces the issue, so that investigation can be taken up. MCVE is a must. 6. Issues must be provided with a minimalist sketch. Issues with an incomplete sketch, or a huge sketch, will be closed. Maximum effort must be put forth by the person opening the issue to reduce the relevant code that reproduces the issue, so that investigation can be taken up. MCVE is a must.
6. Issues with accompanied investigation that shows the root of the problem should be given priority 7. Issues with accompanied investigation that shows the root of the problem should be given priority
7. Duplicate issues will be closed with a reference to the original 8. Duplicate issues will be closed with a reference to the original
# Triaging # Triaging
1. Any contributor of the project can participate in the triaging process, if he/she chooses to do so 1. Any contributor of the project can participate in the triaging process, if he/she chooses to do so