Engineering Technical Discussion on Work Item Initiative

This issue is going to be used as SSO for engineering technical questions that need to be discussed by BE/FE Engineering teams. This could then serve as a starting point for am achitectural blueprint for the Planning Object Initiative.

How to?

Create a thread for any new question that anyone has. Kick-off meeting can be a good source of questions, but also any other questions that might have not been touched in the meetings are fine.

This issue will use discoto to keep the description up to date. Please prefix new discussion threads with Topic:. To include any text in the discussion summary of that topic, please prefix it with Point:.

What to ask and what not to ask?

No question is too trivial, it is a great benefit for all of us to be aligned even on most trivial questions.

Outcome

Be able to draw a dev doc to guide the process

• Mr for dev doc: !66519 (merged)

Auto-Summary 🤖

Discoto Usage

---

Points

Discussion points are declared by headings, list items, and single lines that start with the text (case-insensitive) point:. For example, the following are all valid points:

• #### POINT: This is a point
• * point: This is a point
• + Point: This is a point
• - pOINT: This is a point
• point: This is a **point**

Note that any markdown used in the point text will also be propagated into the topic summaries.

Topics

Topics can be stand-alone and contained within an issuable (epic, issue, MR), or can be inline.

Inline topics are defined by creating a new thread (discussion) where the first line of the first comment is a heading that starts with (case-insensitive) topic:. For example, the following are all valid topics:

• # Topic: Inline discussion topic 1
• ## TOPIC: **{+A Green, bolded topic+}**
• ### tOpIc: Another topic

Quick Actions

Action	Description
/discuss sub-topic TITLE	Create an issue for a sub-topic. Does not work in epics
/discuss link ISSUABLE-LINK	Link an issuable as a child of this discussion

---

Last updated by this job

• TOPIC Should we re-use issues table for base planning object or have a separate table? #332566 (comment 591937351)
  • PRO Easier first MVC step for moving towards issue types #332566 (comment 592294224)
  • PRO We can reuse a lot of the existing code #332566 (comment 592294224)
  • PRO No extra migration to move data to a new table #332566 (comment 592294224)
  • CON Fitting more columns into issues table for all other issue types would make the table very wide requiring more indexes and affecting performance. #332566 (comment 592294224)
  • CON configuring which issue type attributes are visible would require for each column to have a {column}_visible flag within issue table basically doubling the number of columns ? #332566 (comment 592294224)
  • CON Issues live at the project-level, so moving group-level features to issue types is hard-blocked by the work to consolidate groups and projects. #332566 (comment 596787939)
  • I think we need a DB specialist to weigh in before making a decision #332566 (comment 597370599)
• TOPIC Are we going to be adding requirement and epic, incident, etc specific columns to issues table? #332566 (comment 591937913)
• TOPIC Do we force migrate existing objects to an issue type or we make it an opt-in, e.g. an UI button to migrate epics to epic issue types? #332566 (comment 591953149)
• TOPIC Can we bypass groups and projects consolidation to migrate epics to an issue type? #332566 (comment 591956293)
• TOPIC Initial greenfield implementation? #332566 (comment 597375733)
• TOPIC MRs - the odd man out? #332566 (comment 597381708)
• TOPIC What about thinking of it as a framework? #332566 (comment 597385732)
• TOPIC implementation of parent/child relationship #332566 (comment 597773766)
• TOPIC implementation of custom types (existing type enum vs. new table) #332566 (comment 609572456)
• TOPIC GraphQL schema definition #332566 (comment 613221308)
• TOPIC How would we map existing widgets(columns and associations) to a specific Work Item Type? #332566 (comment 631433472)
• TOPIC Should we have a single set of routes or routes for each concrete work item type, plus one for custom types? #332566 (comment 650910685)
• TOPIC Permission checks for work item types #332566 (comment 691202707)
• TOPIC Coarse grained work item mutation #332566 (comment 699120087)
• TOPIC Release and Rollout Strategy Options #332566 (comment 716425457)
• TOPIC Relationships widget for between multiple different resources(issue, task, merge request) #332566 (comment 721973644)
• TOPIC Should we have a GraphQL separate endpoint for updating widgets #332566 (comment 992979338)
• TOPIC Should we include metadata related to a widget in the GraphQL widget type? #332566 (comment 1000720301)

Discoto Settings

---
summary:
  max_items: -1
  sort_by: created
  sort_direction: ascending

See the settings schema for details.