Define interaction for adding relationship type context to a work item[🎨 Design]
Goal
✅ Define relationship "types" and flow
🔮 Which types should we include by default?
- Idea: "Child" items that are sub work items nested within the parent (MVC)
- Idea: "Checklist items" that can be promoted to "child" items if needed
- Idea: "Dependent items" that are blocking or blocked by the current parent
- Idea: "Related items" ...- what are these? or:
- Idea: "Mentions/callouts" of this parent work item in other objects
✅ Define terminology of relationship "types"
🔮 What should we label or title these "child" items?
- Idea: To complete
- Idea: Acceptance criteria
- Idea: Backlog
- Idea: Children
- Idea: Sub-tasks
- Idea: Child items
- Idea: To-Do
- Something else?
🔮 What should we label or title these "Checklist" items?
- Idea: Checklist items
- Idea: Sub-tasks
- Idea: To-Dos
- Something else?
🔮 What should we label or title these "Dependent" items?
- Idea: Dependent items / Dependencies
- Idea: Related items
- Something else?
🔮 What is the entry point for adding "children"? (MVC)
-
Idea a: Pick from
Add childoption at top level -
Idea a: Pick from
Add childoptions within list on slash command -
Idea b: Pick from
Add childoption underChild widgetpicker at top level -
Idea b: Pick from
Add childoption underChild widgetthat has been added by slash command -
Idea b: Pick from
Add childoption within exposed empty state -
Idea c: Pick from
Add childoption within "Links" or "To-Do" section picker -
Idea c: Pick from
Add childoption within "Links" or "To-Do" section exposed empty state -
Idea c: Pick from
Add childoption within"Links" or "To-Do" widgetthat has been added on slash command - Future: All children must be promoted from checklist items
- Future: Child widget included in templates
- Something else?
Solution
-
Default relationship types defined: Document here -
Relationship types terminology defined: Document here -
Entry point or flow: Document here
Edited by Alexis Ginsberg