本文由 AI 分析生成
建立時間： 2026-04-16 來源： https://handbook.gitlab.com/handbook/marketing/project-management-guidelines/boards/
Summary
GitLab Marketing team’s guidelines for using issue boards, covering three board types (Kanban/workflow, member-assignment, and milestone-based), configuration details, and known limitations. Boards operate by adding/removing labels, assignees, or milestones when issues are moved between lists.
GitLab 行銷團隊的 issue board 使用指南，涵蓋三種 board 類型（Kanban 工作流程、人員指派、Milestone），以及拖曳操作背後的標籤/指派行為。
Key Points
- Every board action (drag between lists) does exactly one thing: adds/removes a label, changes assignee, or changes milestone — never more than one change at once
- Board issue order (drag up/down) affects priority on ALL boards in GitLab, not just the current one — a non-obvious side effect
- Priority changes leave no audit trail: no history of who moved what and when
- Each Marketing group should maintain at minimum two boards: a Workflow board (sprint status) and an Iteration board (planned workload across iterations)
- Boards exist at both project and group levels; define at the lowest level that covers the relevant issues
Insights
- The “one action per drag” constraint is the most important limitation to internalize — teams that expect compound changes (assign + label) will be surprised. This shapes how scoped labels and board lists should be designed.
- The lack of priority change history is a significant operational gap for teams managing large backlogs by drag order.
Connections
- Issues project management guidelines — the underlying issue system boards visualize
- Labels project management guidelines — scoped labels are the primary mechanism for workflow boards
- Milestones project management guidelines — milestone boards are the third board type
Raw Excerpt
“Moving issues from one list to another on a board ONLY makes one change (adding/removing a label, assigning/unassigning an issue). It is not possible to drag an issue from one list to another and have MORE than one thing change.”