## How to contribute

Short version: **open an issue, not a pull request.**

### Why

Everything here ships through one pipeline, mine. That is what keeps support sane: when someone reports a problem I need to know exactly what is in their copy, and a merged branch I did not write makes that guesswork. It is not about the quality of the code. Several of the best fixes in this project came from people reading it more carefully than I had.

### What happens to a good issue

I read it, and if the idea is right I build it, in the style of the rest of the codebase, and **credit you in the commit and in the README.** That has already happened more than once. Issue #1 on backtalk is the example: two features proposed, both shipped the same afternoon, credited in both places.

So an issue is not the slow path. It is the path.

### What makes a report I can act on

The best ones here have all had the same shape:

- **What you saw**, in plain words, including what it looked like when it went wrong
- **What you expected instead**
- **How to reproduce it**, even roughly
- **Your setup**: operating system, and the hardware if it is audio or camera related
- **The evidence**: a log line, an error, a measurement. One report included a timing capture of 186 keyboard events, and it found a bug nobody else could see.

You do not need to know the cause. If you do know it, say so, and paste the code if you have it. That is genuinely useful and it gets credited the same way.

### Pull requests already open

If you have one open, thank you, and sorry that this file did not exist when you wrote it. It is being read. The work in it is not wasted: where it is right it goes in, credited to you by name.