Overview
StretchProjects builds a delivery discipline directly into every card: three documentation flags — KB, Ops Doc, and Changelog — mark what documentation a piece of work owes before it can be considered done. This guide explains each flag, how to use them as a release gate, and how they roll up into the dashboard.
The three flags
Each flag is a simple on/off attribute on an item, shown as a chip on the card:
- KB required — a public knowledge-base article is expected. Use this when a change affects what customers see or do and should be explained in the help center.
- Ops Doc required — an internal operations document is expected. Use this when a change affects how your team runs, deploys, or supports something.
- Changelog required — a release changelog entry is expected. Use this whenever the change should be recorded in a release note.
An item can carry any combination — none, one, or all three.
Set the flags on an item
- Open a card's detail panel (or set them while creating the item).
- Turn on the flags that apply to the work.
- Save. The chosen chips appear on the card face.
Choosing which flags apply
| Kind of work | Typical flags |
|---|---|
| Customer-facing feature | KB + Changelog |
| Internal process or deploy change | Ops Doc + Changelog |
| Bug fix visible to customers | KB + Changelog |
| Pure infrastructure with no user impact | Changelog only |
| Documentation task itself | Ops Doc |
Track them on the dashboard
The dashboard rolls the flags into two counts:
- Docs required — items still carrying a KB or Ops Doc obligation.
- Changelog required — items owing a changelog entry.
Read these before a release: if Docs required is above zero, some in-flight work hasn't been documented yet. Treat the number as a pre-release checklist.
Use the flags as a release gate
A simple, effective policy:
- When you plan an item, set the flags that its type of change demands.
- As the item moves toward Released, don't let it cross into the final stage until its required docs exist.
- Before each release, open the dashboard and confirm Docs required and Changelog required are at zero for the work you're shipping.
This keeps the standard — meaningful features ship with the right documentation — attached to the work itself rather than living in someone's memory.
Example
A team ships a new customer-facing pricing page. The item is flagged KB required (customers need a help article explaining the new plans) and Changelog required (it's a release-worthy change). It is not flagged Ops Doc because nothing about internal operations changed. The card shows KB and Changelog chips, and it counts toward Docs required on the dashboard until the help article is written — at which point the team clears the KB flag and the count drops.
Tips
- Decide flags at planning time, not at release time — it's much easier to write docs alongside the work.
- Use Docs required as a standing agenda item in your pre-release review.
- Don't over-flag pure-infrastructure work; reserve KB for changes customers can actually perceive.
- Pair the flags with the item's related app/related brand so it's obvious which product's docs are owed.
FAQ
Do the flags block a card from moving automatically?
The flags are a signal and a rollup, not a hard lock — they surface the obligation and count it on the dashboard. Enforcing the gate is a team practice you apply when moving work to Released.
Who clears a flag?
Whoever completes the documentation clears the flag on the item, which removes it from the dashboard's required counts.
Was this helpful?
Help us improve this article
Use these controls to share whether this answer solved the issue. Feedback helps prioritize updates to StretchSuite Support.

