DCC delivery checklist
DCC Quality Issue Triage Checklist
Direct answer: Use one ledger with reproducible asset state, object path, severity, owner, due build, and acceptance condition. Blocker stops the build; Warning requires risk ownership; Info records context; Resolved means the check passes on the named delivery, not merely that the submitted changed.
Acceptance ReportArt CheckBlockerConstruction History Not DeletedDuplicate Object
1. Freeze the candidate prior triage
register the DCC version, scene path, submitted revision, export preset, destination build, and checker version prior assigning severity. Do not compare an autosave finding with the submitted candidate.
2. Classify impact, not appearance
Set Blocker when the build cannot ship, import, render, animate, or meet an explicit contract. Use Warning for measurable risk and Info for observations requiring no change. A Naming Error may be a Blocker when automation resolves files by name, but a Warning in a manual archive. Write the failed requirement beside severity so reviewers rank delivery impact, not visual annoyance.
3. Capture a minimum reproduction packet
An Issue Ticket should name the revision, object, viewport mode, operation, expected finding, and actual finding. For an Empty Node or Hidden Object, include the hierarchy filter. For Construction History Not Deleted, identify the surviving node and import incident. Add one clear screenshot and validator output. Another artist must reproduce the symptom without live explanation.
4. Separate ownership from discovery
The reporter owns reproduction, not necessarily the resolution. Route geometry, look-development, rig, and export faults to their responsible disciplines, while keeping one accountable owner. Set the deadline by gate: same build for Blocker, next assessment for Warning, backlog for Info.
5. Run the decision on a real case
Suppose a hero prop imports with overlapping collision meshes and a hidden render mesh. The Duplicate Object changes gameplay, so mark it Blocker. The Hidden Object is Warning if export excludes it, but Blocker if packaged. A helper Empty Node is Info unless naming automation treats it as a socket. Judge observed destination behavior, not every cleanliness violation equally.
6. Verify resolutions against the acceptance condition
For Self Check, reopen the submitted, rerun the validator, re-export with the recorded preset, and audit the destination build. Compare counts, hierarchy, dimensions, materials, animation, and logs with the incident. “Deleted duplicate” is not proof; “collision count changed from 14 to 7 and traversal passes in build 4821” is. Mark Resolved only when the original steps pass without adjacent regression.
7. Control reopen and exception paths
Reopen an item when the same acceptance condition fails on a newer candidate, even if the symptom moved to another object. Create a linked ticket when the root cause differs.
8. Assemble the acceptance register
The Acceptance Report lists candidate identifiers, open Blocker count, accepted Warning items, validator versions, reviewer, decision time, and documentation. Preserve captures and logs. Show closed blockers, owned waivers, and delivery matching the reviewed revision—an auditable boundary between “artist says fixed” and acceptance.
Issue labels across assessment languages
Use these labels without abbreviation in validator output, tickets, and the final report so regional teams classify the same finding consistently.
| zh | en | ja | delivery context |
|---|---|---|---|
| 验收报告 | Acceptance Report | 受入報告書 | 质量检查、问题类型与交付验收 |
| 美术检查 | Art Check | アートチェック | 质量检查、问题类型与交付验收 |
| 阻塞问题 | Blocker | ブロッカー | 质量检查、问题类型与交付验收 |
| 历史未清理 | Construction History Not Deleted | 履歴未削除 | 质量检查、问题类型与交付验收 |
| 重复对象 | Duplicate Object | 重複オブジェクト | 质量检查、问题类型与交付验收 |
| 空节点 | Empty Node | 空ノード | 质量检查、问题类型与交付验收 |
| 隐藏对象 | Hidden Object | 非表示オブジェクト | 质量检查、问题类型与交付验收 |
| 信息 | Info | 情報 | 质量检查、问题类型与交付验收 |
| 问题单 | Issue Ticket | 課題チケット | 质量检查、问题类型与交付验收 |
| 命名错误 | Naming Error | 命名不正 | 质量检查、问题类型与交付验收 |
| 已解决 | Resolved | 解決済み | 质量检查、问题类型与交付验收 |
| 自检 | Self Check | セルフチェック | 质量检查、问题类型与交付验收 |
| 警告 | Warning | 警告 | 质量检查、问题类型与交付验收 |
DCC Quality Issue Triage Checklist FAQ
Can a visual defect be Info while a naming defect is a Blocker?
Yes. Severity follows delivery impact. A minor visual note may not affect the current contract, while a Naming Error can break automated export, binding, or packaging and therefore stop the build.
What documentation is required prior marking an issue Resolved?
Repeat the original reproduction steps on the saved submitted and named export candidate, attach the passing validator or destination-build finding, and register the reviewer who confirmed the acceptance condition.
Should an accepted Warning disappear from the Acceptance Report?
No. Keep the Warning visible with its risk owner, impacted release, expiration point, and fallback. Acceptance is a controlled exception, not documentation that the underlying condition no longer exists.