- KPIs and OKRs
- Remote Work
- Access Control Policy
- Data Management Policy
- Information Security Roles and Responsibilities
- Operations Security Policy
- Information Security Policy and Acceptable Use Policy
- Secure Development Policy
- Cryptography Policy
- Development & Design Practices
- Front End
- How We Work
- Markdown How-To
- Using Git
- Website A/B Testing
- Internal Operations
- People Ops
- Sales & Marketing
- Boiler Plate Descriptions
- Content Channels
- Content Types
- Marketing - Website
# Coding Best Practices
All code repositories adopt our standard linting rules found in the flowforge/.github repository.
We use StandardJS, with one exception - 4 spaces not 2.
If you're using VSCode, then we recommend using the ESLint extension and setting
all for the
Eslint › Code Actions On Save: Mode setting:
In the case of working with
njk files (found in the frontend and website repositories), then you can add
njk to the
Eslint: Probe setting in order to enable auto-formatting on save for these file types.
# Git Best Practices
Take care when adding files to a commit. It's easy just to
git add -A (i.e. add all local changes to a commit) but this can result in commits and PRs being clogged with excessive changes that aren't linked to the actual issue/feature at hand.
Take your time when committing files. Review each file carefully and ensure what you're adding to a commit is relevant and necessary.
# Git Commit Messages
- Capitalise the first letter, no trailing dot, 72 chars or less.
- First line should be an imperative/present tense, e.g.
- Do not include the issue number in the first line, this means that commit message are then suitable to include in a changelog as-is.
- Second line should either be blank, or reference to an issue/PR using one of the GitHub recognised keywords, e.g.
part of #...
- The remainder should be any further narrative that is needed. Wrapped at 72 chars.
# Branching vs. Forking
Commits should never be pushed directly to
main. Instead, branch or fork from the relevant branch (most likely
main) and work from there.
It is preferred that new work be added on a branch (rather than in a forked repository), although this is not enforced. Branch names should be short, informative, and if directly linked to a single issue number, reference such issue number, e.g.
Once code is merged, please close any related branches in order to keep the repository tidy.
# Pull Requests
PRs, when opened, should have at least one reviewer assigned, and a consequent review approved, before any merge takes place. If a PR is opened for review/discussion purposes, this PR should be set to
When merging a PR, you should choose the "Merge pull request" option. There is no need to rebase or squash the PR commits.
When conducting a PR review, if you are the last (or only) reviewer and all reviews (including your own) are approvals, unless there is a comment from the author stating otherwise, you are free to conduct the merge. Otherwise, leave the merge to the author of the PR, or a future reviewer.