Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document our VCS and code review practices #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

zah
Copy link

@zah zah commented Nov 26, 2021

No description provided.


Work on big ideas is divided into smaller, at most week-sized, chunks that each reasonably can be digested and reviewed in one sitting - the output here might be an overview, a prototype or progress towards a milestone or a snapshot of the work done so far, with the aim to involve reviewers early and allow space and time for course adjustments as the idea develops.

Uncontested portions of the developed code that don't introduce significant risks or can be properly gated through feature flags are merged as soon as possible in order to reduce the size of the long-lived feature branch. Compile-time feature flags are preferred to run-time feature flags.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this last bit is not necessarily true - a good example has been the introduction of the new connection model - it took user feedback to come up with adjustments that will need to be done, and such feedback cannot be expected to happen with compile-time flags. In general, now that the software is released, a practice we've been introducing is releasing certain features as preview behind a "beta" tag - this has worked pretty well.

We strive to follow [trunk-based development](https://trunkbaseddevelopment.com/) with few caveats.
Since the cost of introducing correctness (or security) issues in our software is very high, we don't welcome even temporary quality regressions or sources of risk within our main branch. This may lead to feature branches that are a bit longer-lived than the trunk-based development ideal of 2 to 3 days.

Generally, all significant code changes are reviewed by at least one team member and must pass CI.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

with this change, we can remove the one in the introduction and link instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants