How we work · 3 min read
How to be useful here
A short mutual contract on how we show up for each other and get things done.
Whether you're on the team or you found us through the code, being useful here looks roughly the same. This is less a to-do list and more a contract in both directions: here's how we expect people to show up, and how you can expect us to show up back. It's warm, and it has teeth.
Try to help yourself first
When you hit a wall, take an honest swing at it before you ask. Read the handbook, search the code, check the issues. Timebox it, though. Fifteen minutes stuck is learning; two hours stuck is just stubbornness with extra steps. When the timer's up, ask.
Ask in the open. Drop it in the Discord or the issue, not a DM. A question answered in public helps the next person who gets stuck on the same thing, and there's always a next person.
The timebox is a real number
Pick one before you start, five minutes or an hour depending on the size of the thing, and honor it. It stops you from either interrupting too soon or suffering in silence too long.
If it's broken and you can fix it, fix it
You don't need permission to make something better. If you spot a typo, a broken link, a confusing paragraph, a bug with an obvious fix, fix it and open the change. The person who noticed the problem is usually the best-placed person to solve it, and "someone should really deal with that" is how nothing gets dealt with.
This goes double for the handbook itself. If a page is wrong, the page is the bug. Edit it. You will not get in trouble for improving something.
For anything bigger than a paper cut, still just start. Open a draft, sketch the fix, show your work. It's far easier for people to react to something real than to a hypothetical.
Default to public
Work where people can see it. Open the pull request early, think out loud in the issue, write the thing down where others can find it. Private progress feels safer and helps no one. See how we work for the mechanics of this.
Being public means being visibly unfinished sometimes, and that's fine. A rough draft in the open beats a polished one nobody knows exists.
Being wrong out loud beats being silent
If you have a hunch, say it. If you think a decision is off, say that too, in the right place and with your reasons. We would much rather you be wrong in public and get corrected than sit on a good instinct because you weren't sure.
Silence isn't caution, it's just information we don't have. The cost of a wrong idea said plainly is a two-minute correction. The cost of a right idea never said can be a lot more.
Ship over asking permission
Bias toward action. If you're reasonably sure and the change is reversible, do it and tell people, rather than asking first and waiting. Most of what we do is reversible, and the ones that aren't are usually obvious. When in doubt, read how we decide for where the line sits.
Asking permission feels responsible. Often it's just moving the risk onto someone else's plate. Own the call.
Leave it better than you found it
The small stuff compounds. Tidy the thing next to the thing you came to fix. Rename the confusing variable, add the missing sentence, delete the dead code. Nobody's assigning this, which is exactly why it matters.
If any of this sounds like your kind of place, come say hi at hey@flagon.io or in the Discord. Read working here for the fuller picture.