<aside> 🔨
External contributors can ask questions in Slack (invitation only) or via email at [email protected]
</aside>
Don’t spend too much time trying to debug something or trying to find something that you don’t understand. Just ask someone, put it in Slack, you’ll save time for yourself and the whole team. Often by just explaining a problem, you’ll find the solution.
We don’t have a lot of documentation on everything, so often it is good to ask for some recommendations before starting on something.
We have a handful of simple standards for commit messages which help us to generate readable changelogs. Please follow this wherever possible and mention the associated issue number.
1st line: Max 80 character summary written in past tense
2nd line: [Always blank]
3rd line: ref #STA-ID, fixes #STA-ID, closes #STA-ID or blank
4th line: Why this change was made - the code includes the what, the commit message should describe the context of why - why this, why now, why not something else?
If your change is user-facing please prepend the first line of your commit with an emoji key. If the commit is for an alpha feature, no emoji is needed. We are following gitmoji.
Main emojis we are using:
✨ Feature
🎨 Improvement / change
🐛 Bug Fix
💡 Anything else flagged to users or whoever is writing release notes
This is a thing we do, it works better. It might be personal preference, but we can’t combine multiple ways of working.
Learn how to solve conflicts when using rebase.
Did you find some old code that you have to touch? Refactor it first in a separate commit. Don’t combine refactoring and feature work in a single commit. This makes it hard to review, and it hides the actual changes in your commit.
Put things on paper, in Notion, somewhere. It often helps you end up with a lot cleaner code, and better, reusable patterns. It helps avoid spaghetti code.
It is tempting to commit your whole feature or change in one go. Don’t do this. Commit small working pieces. Iterate in separate commits.