keybrd library is an open source library for creating custom-keyboard firmware.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
This repo is archived. You can view files and clone it, but cannot push or open issues/pull-requests.

CONTRIBUTING.md 6.6KB

7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
7 years ago
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142
  1. Contributing to keybrd
  2. ======================
  3. We'd love for you to contribute to the keybrd project.
  4. Improvement suggestions
  5. -----------------------
  6. We need to know what keybrd library improvements would help you create keyboard designs.
  7. Before requesting an improvement, please check the [planned_features list](doc/planned_features.md).
  8. Submit improvement suggestions to [GitHub issues](https://github.com/wolfv6/Keybrd/issues)
  9. or [geekhack thread](https://geekhack.org/index.php?topic=83599.0).
  10. <!-- * The issue title should start with "suggestion:" followed by a descriptive title -->
  11. * Provide a use case
  12. * Explain why the improvement is useful
  13. * Site other product examples where this improvement exists
  14. Bug reports
  15. -----------
  16. Submitting a bug report is the first step in fixing a bug.
  17. Once it is found, correcting a bug is usually relatively easy.
  18. Please submit bug reports to [GitHub issues](https://github.com/wolfv6/Keybrd/issues)
  19. or [geekhack thread](https://geekhack.org/index.php?topic=83599.0).
  20. Provide enough information so we can reproduce the buggy behaviour!
  21. * Complete sketch (copy & paste, attachment, or a link to the code)
  22. * Screenshot or the exact text of error messages
  23. * Describe the observed behavior and explain which behavior you expected
  24. * Which controller your using
  25. * Wiring details - how exactly have you connected the hardware (a photo's worth 1000 words)
  26. * Arduino IDE version number
  27. * keybrd library version number
  28. * Any other information needed to reproduce the problem...
  29. Code contributions
  30. ------------------
  31. Unsure of where to begin contributing to keybrd code?
  32. You can start by looking through the improvement suggestions, bug reports, and [planned_features](doc/planned_features.md).
  33. Scratch your own itch. Code for your own need. Then share it with the keybrd community.
  34. * [Tutorial 8b - sharing your keybrd extension library](tutorials/tutorial_8b_sharing_your_keybrd_extension_library.md)
  35. * [Tutorial 8c - sharing your keybrd sketch](tutorials/tutorial_8c_sharing_your_keybrd_sketch.md)
  36. Git commit message style guide:
  37. * Limit the first line to 72 characters summary
  38. * Second line should be empty, followed by body of the commit message
  39. * Use the imperative present tense (use "Add feature", not "Added feature", not "Adds feature")
  40. * Reference an improvement suggestion, bug report, or planned_features
  41. * Sometimes a bulleted list is a good format to convey the changes of a commit
  42. User contributions
  43. ------------------
  44. Any project requires various kinds of contributions to succeed.
  45. A thriving project is more than a pile of code.
  46. It's the packaging, explanation, outreach, and empathy of maintainers that make a good project great.
  47. ### keybrd tutorials usability survey
  48. We want feedback on keybrd tutorial usability from real users (feedback from noobs is especially valuable).
  49. Please take the survey after completing a tutorial.
  50. Answer the questions you feel like answering, or make up your own questions.
  51. * How easy was it to find the relevant tutorial?
  52. * Which tutorial did you read?
  53. * Did the tutorial provide complete information?
  54. * What other tutorial topics would be useful?
  55. * Are you satisfied with the tutorial?
  56. * Other comments or suggestions.
  57. Post the completed Q & A on [geekhack thread](https://geekhack.org/index.php?topic=83599.0) with the heading "Tutorial usability survey".
  58. If you prefer your answers remain confidential, pm the completed Q & A to [wolfv](https://geekhack.org/index.php?action=pm;sa=send;u=25471).
  59. Usability survey results will be used to make improvements to the tutorials.
  60. ### keybrd library usability survey
  61. We want feedback on keybrd library usability from real users.
  62. Please fill the survey after using the keybrd library to implement a keyboard design.
  63. Answer the questions you feel like answering, or make up your own questions.
  64. * How easy was it to find relevant information?
  65. * Did the User guide provide complete information?
  66. * What other keyboard firmware have you used?
  67. * What pros and cons did you find compared to other keyboard firmware?
  68. * Did you publish your keyboard firmware? If so, please provide a link.
  69. * Are you satisfied with the keybrd library?
  70. * Other comments or suggestions.
  71. Post the completed Q & A on [geekhack thread](https://geekhack.org/index.php?topic=83599.0) with the heading "keybrd library usability survey".
  72. If you prefer your answers remain confidential, pm the completed Q & A to [wolfv](https://geekhack.org/index.php?action=pm;sa=send;u=25471).
  73. Usability survey results will be used to make improvements to the keybrd library.
  74. ### Documentation
  75. Suggest a clarification, simplification, correction, or other improvement.
  76. We need the perspective of people new to the project to see these things.
  77. Sometimes just changing a word or two makes a big difference.
  78. Please submit improvement and errata to [GitHub issues](https://github.com/wolfv6/Keybrd/issues)
  79. or [geekhack thread](https://geekhack.org/index.php?topic=83599.0).
  80. Text file documentation style guide:
  81. * Use Markdown with a .md suffix.
  82. * "Underline" first-level (=) and second-level (-) headings (because easier to read in plain text).
  83. * Capitalize first letter of headings (no extra capitalization in headings).
  84. ### Write a sketch for a keyboard that is popular with Arduino-compatible controllers
  85. Write a keybrd sketch for a keyboard that is popular with Arduino-compatible controllers.
  86. * You should own the keyboard so you can test the firmware
  87. * The keyboard should have an Arduino compatible controller (e.g. ErgoDox and Phantom use Teensy 2.0)
  88. * The layout should be a plain baseline layout (QWERTY)
  89. Other owners of that model keyboard can then easily modify and compile the sketch on Arduino IDE.
  90. The README should have:
  91. * brief description of the electronics
  92. * link to a hardware page
  93. * list any firmware deficiencies
  94. Follow the "Publish" instructions in tutorial_8c_sharing_your_keybrd_sketch.md
  95. ### Blog
  96. You have a fresh perspective of how the keybrd library works.
  97. This makes you the perfect person to write an introductory blog explaining the project.
  98. A healthy project needs the perspective of many people.
  99. Submitting a pull request
  100. -------------------------
  101. Pull request is the preferred way to contribute code and documentation.
  102. [How to contribute to an open source project on GitHub](http://blog.davidecoppola.com/2016/11/howto-contribute-to-open-source-project-on-github/)
  103. If you want to contribute some other way, please make a request in
  104. [GitHub issues](https://github.com/wolfv6/Keybrd/issues)
  105. or [geekhack thread](https://geekhack.org/index.php?topic=83599.0).