This document defines the bylaws under which the Quantum Mechanical Keyboard (QMK) project operates. It defines the roles and responsibilities of the project, who may vote, how voting works, how conflicts are resolved, etc.
The goal of QMK is to help people build and customize their mechanical keyboard. The core of the project is QMK Firmware, an Open Source keyboard firmware that runs on a variety of AVR and ARM processors.
- The QMK Configurator
- The QMK Toolbox, a flashing tool
- The QMK Firmware Documentation
- The qmk.fm site
- The QMK bot
QMK defines a set of roles with associated rights and responsibilities. These roles govern what tasks an individual may perform within the project. The roles are defined in the following sections.
The most important participants in the project are people who use our software. The majority of our developers start out as users and guide their development efforts from the user's perspective.
Users contribute to QMK projects by providing feedback to developers in the form of bug reports and feature suggestions. As well, users participate in the QMK community by helping other users in github issues and user support forums.
All of the volunteers who are contributing time, code, documentation, or resources to QMK. A contributor that makes sustained, welcome contributions to the project may be invited to become a Collaborator, though the exact timing of such invitations depends on many factors.
QMK’s Collaborators are responsible for the project’s technical management. Collaborators have write access to specific project repositories. They may cast binding votes on any technical discussion.
- Fred Sundvik (@fredizzimo)
- Gergely Nagy (@algernon)
- Christopher Courtney (@drashna)
- Yan-Fa Li (@yanfali)
- Mark Merin (@mechmerlin)
- James Young (@noroadsleft)
- Joel Challis (@zvecr)
- Danny Nguyen (@nooges)
- fauxpark
While Collaborators have wide latitude when choosing which contributions to accept, Directors help set QMK’s technical direction. When it’s not clear how a change should be made Directors will discuss and come to a consensus. All Directors are also Collaborators.
- Jack Humbert (@jackhumbert)
- Zach White (@skullydazed)
QMK is a small project that is resource constrained. Most decisions are made on a Lazy Consensus basis. Those making modifications to their own keyboard (one they produce/sell/maintain) will have ultimate say of what changes are accepted, provided they stay within QMK guidelines for a keyboard. Collaborators are trusted to use their best judgement in determining what kind of consensus a particular decision needs.
- Yes - I agree and think the decision should proceed
- Abstain - The default vote. The voter may or may not choose to offer a statement on why they are abstaining.
- No - I disagree and think the decision should not proceed
- Consensus Approval - Requires 3 binding Yes votes and 0 No votes
- Lazy Consensus - Requires 0 No votes (silence is consent.)
- Majority - Requires more Yes than No
- Lazy ⅔ Majority - Requires twice as many Yes as No, and 1 Yes with 0 No’s passes.
- ⅔ Majority - Requires at least 3 votes and twice as many Yes as No
This section describes specific scenarios and what type of vote will need to be taken. This is not an exhaustive list, and if you find yourself unsure it’s best to open an issue for discussion.
- Minor Code Change - Lazy Consensus
- Major Code Change -
- Product Release - Lazy ⅔ Majority
- New Collaborator - ⅔ Majority
- Remove Collaborator - Majority
- Modifying Bylaws - ⅔ Majority
The timeframe for a vote depends on the impact, urgency, and severity of the issue at hand. Code changes generally run 12-36 hours, but this timeframe is not a guarantee. Product Releases are open for 5 days. All other votes run for 7 days, but may run longer in special circumstance.
QMK is an unincorporated association and can not directly hold money or property. All funds collected on QMK’s behalf are held by Jack Humbert of OLKB. QMK uses these funds in the following ways (list inexhaustive):
- Paying programmers for code bounties, or to contribute boring but important features like Unit Tests.
- Paying technical writers to improve QMK’s documentation
- Paying for stickers and other inexpensive but fun items to give to people who make significant contributions, or any other raffle/give-away
- Paying for domain names, hosting services, or technical services QMK depends on
- Paying for acquisition of copyrights of usable codebases
- Paying for trademarks associated with QMK
- Any other expense related to furthering and improving QMK firmware.
QMK strives to be an inclusive and tolerant community. We welcome participation from anyone regardless of age, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, political belief, race, religion, or sexual identity and orientation.
“A gentle word turns away wrath, but a harsh word stirs up anger.”
Our users, contributors, and collaborators are expected to treat each other with respect, to assume good intentions, and to gently correct, where possible, rather than react with escalation. Some examples of behavior we will not tolerate include, but is not limited to:
- The use of sexualized language or imagery
- Unwelcome advances, sexual or otherwise
- Insults or derogatory comments, or personal or political attacks
- Publishing others’ private information without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
If someone is violating this Code of Conduct you may email hello@qmk.fm to bring your concern to the Directors. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident.