Arduino/CONTRIBUTING.md

Contributing Rules

Thanks for your interest in contributing to this free open source project! Please take the time to read this before submitting an issue report or pull request.

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 AVR Boards, arduino.cc (but not the Arduino Playground or forum), Library Manager additions	arduino/Arduino
Arduino Playground	This is a publicly editable wiki. Please either make the edit yourself or create a post on the forum.
Translations for the Arduino IDE	transifex
Arduino Forum	arduino/forum-issues
Arduino libraries	arduino-libraries
arduino-builder	arduino/arduino-builder
Arduino Web Editor	arduino/arduino-create-agent
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
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.
• 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 when posting code.
• 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

This guide mainly focuses on the proper use of Git. It has some overlap with the more general information found in the Development Policy File.

• Before starting to work on bigger topics like modifying the API or changes with backward compatibility trade-offs please discuss them in the mailing list first.
• An easy to read pull request will speed up the merging process. Your commit messages need to be logically separate. And containing enough information on their own. When this is done consistently your pull request will have an easy to read log of changes.
• Your commits need to be atomic which allows the repository to remain flexible after merging.
• If you did not read the following 7 points before or just want to fresh up. Please read up on them on this website by Chris Beams.
• Separate subject from body with a blank line
• Limit the subject line (first line) to 50 characters
• Capitalize the subject line
• Do not end the subject line with a period (.)
• Use the imperative mood in the subject line. This should be in the written as giving an instruction for example "Fixed save-as bug" (it shows what the PR achieves when merging it)
• Wrap body at 72 characters
• Use the body to explain what, why and how
• If your pull request fixes, closes or resolves an issue please reference it in the body with the following syntax. Also see the last lines of the following example.
• A general example with these 7 guidelines in mind is shown below (from the same website of Chris Beams):

Summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

Resolves: #123
See also: #456, #789

• When different people are working on the Arduino project simultaneously, pull requests can go stale quickly. A "stale" pull request is one that is no longer up to date with the latest merges in the project. It needs to be updated before it can be merged. Most often pull requests become stale when merge conflicts occur. This happens when two pull requests both modify similar lines in the same file and one gets merged, the unmerged request will now have a merge conflict and needs updating. When your pull request is stale, you will need to rebase your branch on the current master branch before you can merge it without conflicts. More information about rebasing can be found at the repository of edX.
• When your pull request is merged please update the documentation if the changes require it:
  • Edit appropiate Wiki pages
  • Submit an issue report requesting changes to the arduino.cc reference pages