---
title: "Asana Ticket Standard"
slug: help-asana-ticket-standard
section: In-App Help
status: stable
description: "In-app help · House standard for writing Asana tickets in the Sponsor Ecosystem program"
last-updated: 2026-10-07
---

# Asana Ticket Standard

In-app help · House standard for writing Asana tickets in the Sponsor Ecosystem program

> **Read this first**
>
> Every new Asana ticket — whether drafted by a human or by an agent — must follow this shape so reviewers can read tickets at the same speed they read code. The full standard lives in the repo at docs/asana-ticket-standard.md; this page mirrors it for in-app access.

## Source of Truth

The canonical reference ticket is Asana task 1214212456520951 ("Globus: shared response-redaction layer for all outbound partner and host endpoints"). It is the read-only style anchor — copy from it, but do not edit it.

The full written standard is maintained at docs/asana-ticket-standard.md. When this page and the markdown file disagree, the markdown file wins.

## Title Rule

- The title names the system or component being changed, not the symptom and not a user story.
- Lead with the scope tag, a colon, then a precise noun phrase. The default scope tag is Globus: for ecosystem-wide work.
- A narrower scope tag (e.g. Season lifecycle:, Host Portal:, Rules engine:) may replace Globus: when the work is contained to that subsystem.
- Do not start the title with a verb ("Fix…", "Add…", "As a user…"). Name the thing.
✅ Globus: shared response-redaction layer for all outbound partner and host endpoints

✅ Season lifecycle: state machine + transition guards

❌ Fix partner data leak

❌ As a partner I want to not see other partners' data

## Body — Five Required Sections

Every ticket body has these five sections, in this exact order, with the headings written exactly as shown.

- FOR PRODUCT OWNERS / STAKEHOLDERS — 1–3 plain-language sentences explaining what changes from a stakeholder's point of view. If the work is purely technical and has no visible product surface, lead with the literal phrase "Invisible to end users, but…" and then explain the operational/risk reason it matters.
- Separator line — a row of hyphens with a blank line above and below. Use exactly ----------------------------------------.
- BACKGROUND — frames the current state. Descriptive, not prescriptive. Names the actual modules, routes, files, tables, or jobs that exist today. If a sentence here would still be true after the ticket ships, it belongs in BACKGROUND. If it would only be true after the ticket ships, it belongs in WHAT THIS TICKET DOES.
- WHAT THIS TICKET DOES — concrete scope: which modules to build, which endpoints/screens to rewire, which companion tickets are referenced. Companion tickets are referenced by their full title in straight double quotes, never by ID alone. This is what and scope only — no implementation steps or build order.
- ACCEPTANCE CRITERIA (Gherkin) — the behavioral contract.
## Gherkin Conventions

- Open with a single Feature: line naming the capability being delivered.
- Each Scenario: describes one observable behavior. Never bundle multiple behaviors into one scenario.
- Use Given / When / Then / And, indented two spaces under the Scenario: line.
- Identifiers, role names, toggle labels, status values, permission names, and file/module names appear in straight double quotes exactly as they appear in code or UI (e.g. "recruiter", "Hide from hosts", "program_register.position_types.manage").
- Avoid Background: blocks unless the precondition is truly shared by every scenario in the feature. When in doubt, repeat the Given.
## Scenario-Coverage Checklist

For each ticket, the Gherkin must cover, at minimum:

- Shape of the API surface — one module/function with the specified signature exists.
- Per-audience / per-role behavior matrix — one scenario per role (e.g. one for "partner", one for "host", one for "staff").
- Integration coverage of the named endpoints — every endpoint listed in WHAT THIS TICKET DOES has a scenario asserting it goes through the new layer.
- Build-time guard — a lint rule, type check, or test that fails if a future contributor bypasses the new layer.
- Test-fixture coverage for every meaningful input combination — explicit fixtures for each role × each visibility state × each edge case.
## Anti-Patterns

- ❌ Leading the body with implementation steps ("Step 1: create the module. Step 2: …").
- ❌ Skipping the FOR PRODUCT OWNERS / STAKEHOLDERS section because the work is "purely technical." It is never optional — use the "Invisible to end users, but…" opener instead.
- ❌ Writing acceptance criteria as a bulleted to-do list. Acceptance criteria are Gherkin scenarios, not tasks.
- ❌ Bundling multiple behaviors into one scenario ("…and also when the user is a host, then…"). Split it.
- ❌ Paraphrasing identifiers ("the recruiter role" instead of "recruiter"). Quote them exactly as they appear in code or UI.
- ❌ Editing the canonical reference ticket 1214212456520951. It is the read-only style anchor.
## Canonical Example

The gold-standard template to copy from is Asana task 1214212456520951 — "Globus: shared response-redaction layer for all outbound partner and host endpoints".

> **Do not edit the source ticket**
>
> When writing a new ticket, open Asana task 1214212456520951 and use it as a structural template. Match its section ordering, heading casing, separator placement, and Gherkin shape. Do not modify the source ticket.