keybrd/CONTRIBUTING.md

Contributing to keybrd

We'd love for you to contribute to the keybrd project.

Improvement suggestions

We need to know what improvements to the keybrd library would help you create your keyboard design. Before requesting an improvement, please check planned_features list

Submit improvement suggestions to GitHub issues.

• The issue title should start with "suggestion:" followed by a descriptive title
• Provide a use case
• Explain why the improvement is useful
• Site other product examples where this improvement exists

Bug reports

A bug report is the first step in making the keybrd library work the way it's supposed to work.

Please provide enough information so we can reproduce the bug behaviour!

• Complete sketch (copy & paste, attachment, or a link to the code)
• Screenshot or the exact text of error messages
• Describe the observed behavior and explain which behavior you expected
• Which controller your using
• Wiring details - how exactly have you connected the hardware (a photo's worth 1000 words)
• Arduino IDE version number
• keybrd library version number
• Any other information needed to reproduce the problem...

Code contributions

Unsure where to begin contributing to keybrd code? You can start by looking through the improvement suggestions, bug reports, and planned_features.

Git commit message style guide:

• Limit the first line to 72 characters summary
• Second line should be empty, followed by body of the commit message
• Use the imperative present tense (use "Add feature", not "Added feature", not "Adds feature")
• Reference an improvement suggestion, bug report, or planned_features
• Sometimes a bulleted list is a good format to convey the changes of a commit

User contributions

Any project requires various kinds of contributions to succeed. A thriving project is more than a pile of code. It's the packaging, explanation, outreach, and empathy of maintainers that make a good project great.

User Contributions can be in the form of:

• Blog - You have a fresh perspective of how the keybrd library works. This makes you the perfect person to write an introductory blog explaining the project. A healthy project needs the perspective of many people.
• Documentation - Suggest a clarification, simplification, correction, or other improvement. We need the perspective of people new to the project to see these things. Sometimes just changing a word or two makes a big difference.
• [What we currently need from keybrd users](todo geekhack) lists tasks for the keybrd project's current stage of development.

Text file documentation style guide:

• Use Markdown with a .md suffix.
• "Underline" first-level (=) and second-level (-) headings (because easier to read in plain text).
• Capitalize first letter of headings (no extra capitalization in headings).

Submitting a Pull Request

Pull Request is the preferred way to contribute code and documentation. If you want to contribute some other way, please make a request in the GitHub issues.