Editor Extensions: Multi-Platform Group

. To keep things simple, we focus on the main states below and optionally use others when appropriate.

• New → Not yet prioritized or refined.

• Planning breakdown → Needs team attention soon (within ~1–2 months); gather scope, risks/deps, acceptance criteria.

• Ready for development → Immediate priority; clear scope; should be picked up next and ideally completed within ~2 weeks.

• In dev → Assigned DRI(s), milestone set, work in progress.

• In review → Implementation complete; MR opened and under review/verification.

• Blocked → Cannot proceed due to a dependency or external constraint; comment the blocker and next check-in date.

• Closed → Done (or closed as duplicate/won’t fix) with outcome noted.

Note: We chose Planning breakdown & Ready for development as these statues exist on both Issues and Tasks, letting us build one unified set of boards and embedded tables with a single status filter easily.

Rolling Backlog Issue

This rolling issue is the output of this refinement process, it serves as a visible, prioritized, and team-reviewed top-of-backlog list for every scope we own.

Note: We also take into account most thumbed up issues to make sure we also capture community feedback.

How to Participate (for team members)

To contribute or push a issue forward:

• Add one of these labels:
  • group::editor extensions
  • Category:Editor Extensions
• Set the status to one of (see Issues’ state):
  • Planning breakdown
  • Ready for development
• Comment as needed
  • Comment in the relevant issue itself or in the rolling backlog issue if your comment is more relevant there, for example more about order of issues than about a particular issue.
  • Tag EM + PM in your comment
  • Link to references to specific GitLab resources to improve discoverability.
  • For example, comment why this issue is not longer needed, should not be prioritize now, is blocked by other work, is urgent or time-sensitive, is missing info, etc.

How to Participate (for non-team members)

If you want to bring an issue to the attention of the team, please create an issue, if no issue exist yet, then reach out on #g_editor-extensions

Flow

1. EM + PM async pre-pass: Review the backlog, slack pings, re-order, de-duplicate, link and move issues as needed to prepare the initial draft update of the Rolling Backlog Issue

2. Team async review (timebox ~30 min): Review the Rolling Backlog Issue, include any issues you want to push forward, and validate the current priorities if they make sense, and comment as needed

   • EM will create a ticket to trigger this review and assign all engineers, please unassign yourself when you finish review
   • Feel free to move issues directly, just please comment your reasoning and tag EM + PM
   • Please bring your own tech improvement issue you want to include
   • Don’t spend time deep investigating any issue at this point, just high level overview of the priorities is enough

3. EM + PM Sync call: Read team comments, confirm ranking, make trade-offs, and pick target deliverables for the next two weeks. (and once every month use this output to create a milestone planning issue that can be subject to change with the next refinement)

   • Record and use zoom transcript so team can have transparency on the reasoning and arguments behind changing an issue priority or order, also consider adding those reasons directly in the issue when appropriate.

Milestone Planning Issues

We use Milestone Planning Issues to define our goals for the current/upcoming milestone. The PM and EM are responsible for aligning on the goals. The planning issues are created automatically every month.

Estimates

We use three weights to give a rough estimate of the issue’s complexity. The weight is made out of two parts:

• 1 - day or two of effort
• 2 - week of effort
• 3 - week and a half of effort

Notes:

1. Everything with a base weight above 3 should be a spike that will result in one or more issues with estimated weight.
2. These are estimates for someone familiar with the codebase/system, you can add extra weight 1 or 2 to the base weight if you are new to the team/codebase/system.

Flexibility & assigning deliverables

While the monthly milestone issue shape our product priority every month including both Deliverable & Stretch requirements, due to the very dynamic environment of AI engineering, the quickly changing requirements, and the focus on quality and resolving user issues ASAP, we need to plan on shorter periods to be able to adopt as needed and re-focus our attention quickly.

For those reasons we assign Deliverable to the issues we prioritize and expect to ship every 2 weeks:

• At the start of the milestone, following the issue refinement process then creating the milestone planning issue
• Mid-milestone following the second issue refinement process