<spanclass="line"><span>The kerpleplork was intermittently failing with error code 23. The root cause was the fronzlebop setting, which causes the kerpleplork to activate every N iterations.</span></span>
<spanclass="line"><span></span></span>
<spanclass="line"><span>Limited experimentation on the devices I have available shows that 7 is high enough to avoid confusing the kerpleplork, but I'd like to get some feedback from people with ARM devices to be sure.</span></span></code></pre></div><h2id="documentation"tabindex="-1">Documentation <aclass="header-anchor"href="#documentation"aria-label="Permalink to "Documentation""></a></h2><p>Documentation is one of the easiest ways to get started contributing to QMK. Finding places where the documentation is wrong or incomplete and fixing those is easy! We also very badly need someone to edit our documentation, so if you have editing skills but aren't sure where or how to jump in please <ahref="#where-can-i-go-for-help">reach out for help</a>!</p><p>You'll find all our documentation in the <code>qmk_firmware/docs</code> directory, or if you'd rather use a web based workflow you can click the "Edit this page" link at the bottom of each page on <ahref="https://docs.qmk.fm/"target="_blank"rel="noreferrer">https://docs.qmk.fm/</a>.</p><p>When providing code examples in your documentation, try to observe naming conventions used elsewhere in the docs. For example, standardizing enums as <code>my_layers</code> or <code>my_keycodes</code> for consistency:</p><divclass="language-c vp-adaptive-theme"><buttontitle="Copy Code"class="copy"></button><spanclass="lang">c</span><preclass="shiki shiki-themes github-light github-dark vp-code"><code><spanclass="line"><spanstyle="--shiki-light:#D73A49;--shiki-dark:#F97583;">enum</span><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;"> my_layers {</span></span>
<spanclass="line"><spanstyle="--shiki-light:#24292E;--shiki-dark:#E1E4E8;">};</span></span></code></pre></div><h3id="previewing-the-documentation"tabindex="-1">Previewing the Documentation <aclass="header-anchor"href="#previewing-the-documentation"aria-label="Permalink to "Previewing the Documentation {#previewing-the-documentation}""></a></h3><p>Before opening a pull request, you can preview your changes if you have set up the development environment by running this command from the <code>qmk_firmware/</code> folder:</p><pre><code>qmk docs
</code></pre><p>and navigating to <code>http://localhost:5173/</code>.</p><h2id="keyboards"tabindex="-1">Keyboards <aclass="header-anchor"href="#keyboards"aria-label="Permalink to "Keyboards""></a></h2><p>Keyboards are the raison d'être for QMK. Some keyboards are community maintained, while others are maintained by the people responsible for making a particular keyboard. The <code>readme.md</code> should tell you who maintains a particular keyboard. If you have questions relating to a particular keyboard you can <ahref="https://github.com/qmk/qmk_firmware/issues"target="_blank"rel="noreferrer">Open An Issue</a> and tag the maintainer in your question.</p><p>We also ask that you follow these guidelines:</p><ul><li>Write a <code>readme.md</code> using <ahref="./documentation_templates">the template</a>.</li><li>Include a <code>default</code> keymap that provides a clean slate for users to start with when creating their own keymaps.</li><li>Do not lump core features in with new keyboards. Submit the feature first and then submit a separate PR for the keyboard.</li><li>Name <code>.c</code>/<code>.h</code> file after the immediate parent folder, eg <code>/keyboards/<kb1>/<kb2>/<kb2>.[ch]</code></li><li>Do not include <code>Makefile</code>s in your keyboard folder (they're no longer used)</li><li>Update copyrights in file headers (look for <code>%YOUR_NAME%</code>)</li></ul><h2id="quantum-tmk-core"tabindex="-1">Quantum/TMK Core <aclass="header-anchor"href="#quantum-tmk-core"aria-label="Permalink to "Quantum/TMK Core""></a></h2><p>Before you put a lot of work into building your new feature you should make sure you are implementing it in the best way. You can get a basic understanding of QMK by reading <ahref="./understanding_qmk">Understanding QMK</a>, which will take you on a tour of the QMK program flow. From here you should talk to us to get a sense of the best way to implement your idea. There are two main ways to do this:</p><ul><li><ahref="https://discord.gg/Uq7gcHh"target="_blank"rel="noreferrer">Chat on Discord</a></li><li><ahref="https://github.com/qmk/qmk_firmware/issues/new"target="_blank"rel="noreferrer">Open an Issue</a></li></ul><p>Feature and Bug Fix PRs affect all keyboards. We are also in the process of restructuring QMK. For this reason it is especially important for significant changes to be discussed before implementation has happened. If you open a PR without talking to us first please be prepared to do some significant rework if your choices do not mesh well with our planned direction.</p><p>Here are some things to keep in mind when working on your feature or bug fix.</p><ul><li><strong>Disabled by default</strong> - memory is a pretty limited on most chips QMK supports, and it's important that current keymaps aren't broken, so please allow your feature to be turned <strong>on</strong>, rather than being turned off. If you think it should be on by default, or reduces the size of the code, please talk with us about it.</li><li><strong>Compile locally before submitting</strong> - hopefully this one is obvious, but things need to compile! You should always make sure your changes compile before opening a pull request.</li><li><strong>Consider revisions and different chip-bases</strong> - there are several keyboards that have revisions that allow for slightly different configurations, and even different chip-bases. Try to make a feature supported in ARM and AVR, or automatically disabled on platforms it doesn't work on.</li><li><strong>Explain your feature</strong> - Document it in <code>docs/</code>, either as a new file or as part of an existing file. If you don't document it other people won't be able to benefit from your hard work.</li></ul><p>We also ask that you follow these guidelines:</p><ul><li>Keep the number of commits reasonable or we will squash your PR</li><li>Do not lump keyboards or keymaps in with core changes. Submit your core changes first.</li><li>Write <ahref="./unit_testing">Unit Tests</a> for
