Arduino/CONTRIBUTING.md

Contributing Rules

Thanks for your interest in contributing to this free open source project! Arduino welcomes help from the community. There are several ways you can get involved:

Type of contribution	Contribution method
- Support request - Question - Problem with your Arduino - Discussion	Post on the Arduino Forum
- Bug report - Arduino website issue or improvement - Feature request	Issue report (read the issue guidelines)
- Bug fix - Enhancement	Pull Request (read the pull request guidelines)
Translations for the Arduino IDE	transifex
Translations for the Language Reference	Reference repositories
Monetary	- Donate - Buy official products

Issues

• Do you need help or have a question about using Arduino? Support requests should be made to the appropriate section of the Arduino forum rather than an issue report. Issue reports are to be used to report bugs or make feature requests only.
• Check if your issue has already been resolved in the hourly build.
• Submit issue reports to the correct repository:

Issue topic	Report at
Arduino IDE, arduino.cc (but not the Arduino Forum), Library Manager additions	arduino/Arduino
Language Reference	Reference repositories
Arduino Forum	arduino/forum-issues
Arduino libraries	arduino-libraries
Built-in examples	arduino/arduino-examples
arduino-builder	arduino/arduino-builder
Arduino Web Editor	Create > Editor section of the Arduino Forum
Arduino AVR Boards (Uno, Mega, Leonardo, etc.)	arduino/ArduinoCore-avr
Arduino SAMD Boards (Zero, MKR1000, MKRZero, etc.)	arduino/ArduinoCore-samd
Arduino SAM Boards (Due)	arduino/ArduinoCore-sam
AVR Toolchain for Arduino	arduino/toolchain-avr
Arduino's build of AVRDUDE	arduino/avrdude-build-script
Security vulnerability	See: Coordinated Vulnerability Disclosure Policy
3rd party libraries, hardware, or sketches	Report issues to the author of the software, not Arduino.

When you're not sure where your issue belongs, report it at arduino/Arduino and we'll move it to where it belongs (but remember: Only bug reports and feature requests, do not ask for help with your own code there).

• Search existing pull requests and issues to be sure it hasn't already been reported. If you have additional information to provide about an existing issue then please comment on that issue. If you simply want to express your support then use the Reactions feature.
• State the newest version of the Arduino IDE you have verified the issue with and which operating system you are using.
• The issue title should be concise yet descriptive. Vague titles make it difficult to know the purpose of the issue when looking through the list of reports and may cause your issue to not be given proper attention.
• Describe the issue and what behavior you were expecting. Post complete error messages using Markdown code fencing, three backticks before and after the error message:

  ```
  my error message here
  ```
  

• Provide a full set of steps necessary to reproduce the issue. Demonstration code should be complete, correct, and simplified to the minimum amount of code necessary to reproduce the issue. Please use Markdown code fencing, three backticks before and after the code:

  ```
  my code here
  ```
  

• Be responsive. We may need you to provide more information, please respond as soon as possible.
• If you find a solution to your problem update your issue report with an explanation of how you were able to fix it and close the issue.
• Library Manager submissions: make sure your library meets all the requirements listed in the Library Manager FAQ.

Pull Requests

Pull requests are an easy and effective way to submit a proposal for a change to the content of one of Arduino's repositories. The Arduino team can merge your change with a single click! You can find more information about pull requests here.

• Big changes, changes to the API, or changes with backward compatibility trade-offs should be first discussed in the Arduino Developers Mailing List.
• Search existing pull requests to see if one has already been submitted for this change. Search the issues to see if there has been a discussion on this topic and whether your pull request can close any issues.
• Code formatting should be consistent with the style used in the existing code.
• Don't leave commented out code. A record of this code is already preserved in the commit history.
• All commits must be atomic. This means that the commit completely accomplishes a single task. Each commit should result in fully functional code. Multiple tasks should not be combined in a single commit, but a single task should not be split over multiple commits (e.g. one commit per file modified is not a good practice). For more information see http://www.freshconsulting.com/atomic-commits.
• Each pull request should address a single bug fix or enhancement. This may consist of multiple commits. If you have multiple, unrelated fixes or enhancements to contribute, submit them as separate pull requests.
• Commit messages:
  • Use the imperative mood in the title. For example: "Apply editor.indent preference"
  • Capitalize the title.
  • Do not end the title with a period.
  • Separate title from the body with a blank line. If you're committing via GitHub or GitHub Desktop this will be done automatically.
  • Wrap body at 72 characters.
  • Completely explain the purpose of the commit. Include a rationale for the change, any caveats, side-effects, etc.
  • If your pull request fixes an issue in the issue tracker, use the closes/fixes/resolves syntax in the body to indicate this.
  • See http://chris.beams.io/posts/git-commit for more tips on writing good commit messages.
• Pull request title and description should follow the same guidelines as commit messages.
• Rebasing pull requests is OK and encouraged. After submitting your pull request some changes may be requested. Rather than adding unnecessary extra commits to the pull request, you can squash these changes into the existing commit and then do a force push to your fork. When you do a force push to your fork, the PR will be updated with your new changes, so there is no need to open a new PR to make changes. Leave a comment on the pull request thread to explain that the history has been changed. This will help to keep the commit history of the repository clean.
• After your pull request is merged please update the documentation if the changes require it:
  • Edit appropriate Wiki pages.
  • Submit an issue report requesting changes to the arduino.cc reference pages.
• For more contributing guidelines, see the Arduino Development Policy.