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 Wiki Page

This rolling backlog page 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 (could be the next 1-2 months of work).

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

Flow

1. EM & PM async weekly pre-pass: prepare for the next 2 steps

   1. Some issues sources to consider
      • Rolling Backlog
      • Slack pings, team discussions
      • Recent triage-reports issues, for example, Bugs Prioritization, Triage Report, Feature flags requiring attention
   2. Add the label workflow::scheduling to the issues to discuss in step #3 (EM + PM Sync call)
   3. Update issues as needed to make sure Rolling Backlog is up-to-date.

2. Team async bi-weekly review (timebox ~1 hour):

   • EM will create an issue to trigger this review and assign all engineers, example issue, please unassign yourself when you finish review
   • Occurs every 2 weeks, to avoid taking too much of the team’s focus each week.
   • Goals:
     • Ensure everyone on the team weighs in on the priorities.
     • Advance tech improvements or tech debt issues.
     • Flag issues that should be given higher importance.
     • Identify issues that are no longer needed or should be de-prioritized.
   • How to Participate:
     1. Review the current priorities in Rolling Backlog
     2. Weigh in: Add/Change the following as needed (including for new issues you want to push):
        1. Status: Planning breakdown: Should be on our radar, within the next 2-3 milestones or so
        2. Status: Ready for development: Ideally should done this milestone
        3. Label: workflow::schedulingt: Immediate priority, should be picked up next (or at least should be discussed this week)
        4. ~“workflow::scheduling”
     3. Comment & tag EM + PM if you change any of the above with reasoning
   • Notes:
     1. Don’t spend time deep investigating any issue at this point, just high level overview of the priorities is enough
     2. Comment in the relevant issue itself or in the rolling backlog issue if your comment is more relevant there
     3. Link to references to specific GitLab resources to improve discoverability.

3. EM + PM weekly sync call: Focus on the label workflow::scheduling, read team comments, confirm ranking, make trade-offs, and pick target deliverables for the next 1-2 weeks.

   • Meeting should be scheduled on the shared team calendar and recorded, we will also use zoom transcript so team can have transparency on the reasoning and arguments behind changing an issue priority or order and add it to the planning issue.
   • Once every month use this call will be used to create a milestone planning issue that can be subject to change with the next refinement)
   • EM is responsible for assigning the agreed on & updated deliverables
   • Output: Update the milestone planning issue weekly + EM to assign updated priority issues
     • Once a month, before the start of the milestone, the discussion will span a bigger number of tickets in preparation for creating a new milestone planning issue

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

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.

Flow

1. Fill Initial milestone planning issue
   • PM drives the goals of the milestone, in alignment with EM
   • All the output of the previous issues refinement is taken into consideration
   • Should be done before the milestone starts
2. Weekly updates after the weekly issues refinement
   • EM + PM update the milestone planning issue, if needed, reflecting latest changes, that could include for example:
     • Urgent bugs that came up
     • Needing to adopt another AI engineering team work into the IDEs
     • Flagged tech debt
   • EM aligns with the team to assign Deliverable & Stretch labels and ensure issues status, weight & milestone are assigned reflecting the latest priorities
     • Possibly in weekly 1:1 or async