Skip to content

TrueCloudLab team conventions and culture quirks

Marking conversation as resolved

Typically only the user that had started the conversation (created the top comment) should mark the conversation as resolved. Marking other users' threads as resolved is considered bad manners.

This is a soft requirement: you may mark other user's conversation as resolved when there is a good reason, e.g:

  • You have discussed this with original poster out-of-band
  • Original poster is unavailable for a long time
  • Original poster has explicitly stated that you (or anyone) may resolve this thread at their discretion

Recording this reason in the last comment would be a good idea.

Code style

Code style conventions are enforced by linters configured for each project.

If CI checks pass (typically make lint), code style issues should not block the changes from being merged. Linter configuration changes may be suggested and should be reviewed in a separate code review thread.

Commit message format

Commit message format is enforced by dco-go.

New commit message conventions and requirements should be submitted as changes to dco-go instead of lingering indefinitely in the team lore.

Adding references to issue number

If code changes are done in the context of existing Forgejo issue you should reference the issue number in the first line of commit message:

[#1760] shard/log: Fix tag assignment in shard component logs

References to issues filed in other repositories should use long GitHub-like format:

[TrueCloudLab/frostfs-node#1751] object: Add ability to set details for apistatus…

The same long issue references should be used for Gerrit topics/hashtags where applicable.

When a single commit is related to multiple issues only a single issue must be listed in the first line of commit message. All other issues should be placed into commit footer next to "Signed-off-by":

Related: TrueCloudLab/frostfs-infra#287
Related: TrueCloudLab/frostfs-infra#319
Signed-off-by: Vitaliy Potyarkin <v.potyarkin@yadro.com>