The documentation team reviews every new commit in a release to determine whether any documentation needs to be updated. The Jira Epic ref, GitHub Issue ref or Docs note in the commit message tells them why the commit was made to better inform their work on the documentation and release notes. This page provides guidance on when and how Cockroach Labs engineers should include these references or write these texts.

When should I include an Epic ref, Issue ref or Docs note?

Every commit must include at least an Epic ref, an Issue ref or a Docs note.

If the commit does not require a release note and there is no Epic ref or Issue ref, use Docs note: None.

How do I choose which one to include?

If the change in the commit is made as part of an epic choose one of:

• Epic ref

• Issue ref where the issue contains an Epic ref in the issue body (description)

Else if the commit is part of an issue but not an epic:

• Issue ref

Otherwise, when there is no issue for the commit

• Docs note

Why is including this information necessary?

The Documentation team uses “Release note” texts in commit messages to identify user-impacting changes in the product that might require documentation updates. However, those texts alone don’t help Docs writers understand why a change was made. This new information takes care of that, helping writers either connect the change to a high-level epic (e.g., on the product roadmap) or by simply adding additional context about why the change was made when there’s not a connection to an epic.

How do I include an Epic ref?

The rules for an epic reference are:

• It must be of the form [Ee]pic:? CRDB-123

• It must be on a line by itself with no whitespace before it.

An example line in a commit message might be:

Epic: CRDB-8035

How do I include an Issue ref?

The rules for an issue reference are:

• It must be of one of these formats:

  • KEYPHRASE:? #123(, #456)* where KEYPHRASE is one of:

    • See also

    • Informs

  • KEYWORD:? #123 where KEYWORD is one of (following the GitHub PR / issue linking format):

    • Close

    • Closes

    • Closed

    • Fix

    • Fixes

    • Fixed

    • Resolve

    • Resolves

    • Resolved

• The issue ID in the above formats must be one of:

  • #123

  • org/repo#456

• It must be on a line by itself with no white-space before it.

Examples of valid issue references:

closes #16750

Fix: #64276

informs: #33316

See also #62585, #43784

What information needs to be in the issue?

If the issue has an epic link in its body, that is all that is needed.

Otherwise, the issue should explain why the change was made as described in the “What information do I need to put in the Docs note?” section below. If the issue does not explain why the change was made, please add it to the issue or to the Docs note.

How do I include a Docs note?

The rules for a Docs note are:

• The first line must start with [Dd]ocs note:

• It may span multiple lines

• The Docs note text will be this line and every subsequent line until another section is reached (Release note: or Release justification:) or until the end of the commit description is reached.

• The contents will describe why the commit was needed.

What information do I need to put in the Docs note?

Whereas the “Release note” text explains what changed in the product, the “Docs note” text should explain why the change was made. What motivated the change? Was the change made for Postgres compatibility or to support a specific third-party tool? Was the change made to improve the usability of a specific feature? Please provide enough detail for writers to understand the context for the change.

When there is a link to an epic, that epic answers this why question. The “Docs note” is required only in cases where an epic link or an issue link doesn’t clarify the context for the change.

When the commit does not require a release note and there is no Epic ref or Issue ref, use Docs note: None.

What are some examples of Docs notes?

Do I still need to add a release note to commit messages?

Yes. The “Release note” text identifies what changed in the product. Those texts are used in our public-facing release notes as well as by our Docs team to identify product changes that might require documentation.

The epic ref / issue ref / docs note provides additional context for the Docs team about why the change was made.