bmersereau drafts the house rules for Mike
A proposed contributor guide tries to turn Mike's emerging working norms into something a newcomer can actually read.
bmersereau has opened a pull request adding a contributor guide to the upstream Mike repository - the kind of document that tells newcomers how to file a bug, how to disclose a security issue privately, how to name a branch, and what the project expects before it will look at your code. The framing matters: this is pitched as a first draft for the maintainer to mark up, not a finished policy.
A few choices stand out. Tests are stated as a hard requirement rather than a polite ask. Database migration conventions that had grown up informally - wrap your changes in a transaction, ship a rollback script, leave a note explaining what you're doing - get promoted to documented expectations. A 72-hour security response window is proposed, with an explicit offer to drop it if the maintainer isn't ready to commit publicly. Notably absent: a contributor licence agreement, a developer certificate of origin, or a code-owners file. The reasoning is that those add friction the project doesn't yet need.
Spotted something wrong? Or know the PR text has fresher detail than the writeup above?