If you're interested in the team's Objectives and Key Results (OKRs), you can find them on GitLab.
Create:IDE Principles: What Are the Create:IDE Team Principles?
The following people are permanent members of the IDE Engineering Team:
Engineering Manager & Engineers
|David O'Regan||Engineering Manager, AI Framework|
|Alexander Chueshev||Staff Machine Learning Engineer, AI-powered:AI Framework|
|Alejandro Rodríguez||Senior Backend Engineer, AI Powered:AI Framework|
|Bruno Cardoso||Senior ML Engineer, ModelOps:AI Model Validation|
|Denys Mishunov||Staff Frontend Engineer, AI-powered:AI Framework|
|Małgorzata Ksionek||Staff Backend Engineer, AI Powered:AI Framework|
|Mark Chao||Senior Backend Engineer, AI-powered:AI Framework|
Product, Design & Quality
|Eric Schurter||Senior Product Manager, Create:IDE|
|Alper Akgun||Staff Fullstack Engineer, Create:IDE|
|Chad Woolley||Senior Backend Engineer, Create:IDE|
|Enrique Alcántara||Senior Frontend Engineer, Create:IDE|
|Hunar Khanna||Senior Backend Engineer, Create:IDE|
|Nivetha Prabakaran||Software Engineer in Test, Create:IDE|
|Paul Slaughter||Staff Frontend Engineer, Create:IDE|
|Vishal Tak||Staff Backend Engineer, Create:IDE|
|Remote Development||Vishal Tak|
|Web IDE||Paul Slaughter|
Depending on the context here are the most appropriate ways to reach out to the IDE Group:
@create-ide-team(entire team) and
❗️Important: For every meeting, the IDE team's meeting document should be used, and filled with the meeting notes, as well as references to any other sync meeting agendas/notes/recordings which have recently occurred. This will make it easier for people to find any meeting notes.
These are regular meetings in which most team members will participate. Below is our schedule:
NOTE: This meeting is specific to the Remote Development category planning - see Remote Development Planning Process
NOTE: This meeting is specific to the Remote Development category planning - see Remote Development Planning Process
Each week the team EM provides a Weekly Status update issue which aims to capture the most important items for the team to be aware of. These can be found here.
Every month, we create a Milestone Planning issue that serves as the single source of truth (SSoT) for the current milestone.
This issue provides us with a centralized location to discuss our upcoming milestone work, plan for feature, bug, and maintenance tasks, and provides us with the necessary flexibility to iterate mid-milestone if required.
Populate the milestone planning issue with issues from the prioritized boards placed in the ~"workflow::ready for development" column. Feel free to add maintenance issues that aren’t directly related to the group as well.
Move the issues assigned to the current milestone to the ~"workflow:: in dev" column. Also, assign the ~"Deliverable" label and assign the target milestone.
You can find all milestone planning issues in the IDE team’s project.
The layout for these Milestone issues are automated and can be found here.
In the Create:IDE team we leverage an automatic issue hygiene system via the triage bot. This helps to ensure issues and label hygiene are respected, currently, our rules are:
We use the terms Architecture Plan and Iteration Plan when we think of outcomes to broad high-level issues. An investigative spike should result in an Architecture Plan and an Iteration Plan.
Sometimes it takes a time to develop a well fleshed-out iteration plan. In these cases, a "Formulate Iteration Plan" weighted issue can be used.
These guidelines apply to all issues we use for planning and scheduling work within our group. Our Engineers can define specific implementation issues when needed, but the overall goal for our issues are as follows:
Add a cancel button to the edit workspace form page
Automatically save Devfile changes after 2 seconds of inactivity
Make WebIDE better
It's okay to create specific engineering-driven implementation issues for more complex features. These would be called Child Issues and they should always link back to their parent. If one issue would spawn many child issues, consider creating an Epic.
Currently, our team has two primary planning processes: one for Remote Development category, and another for the Web IDE category.
The Remote Development team has decided to use an alternate process for the following reasons:
The Web IDE is a significantly different feature, and does not share many of these same concerns or desires, therefore it will still use a workflow closer to the standard GitLab Product Development Flow. See this comment thread for more context and discussion around this decision.
See the sections below for details on each category's specific planning processes.
The Web IDE still usees the default milestone planning process which is loosely based in the Plan and Develop & Test phases of the product development workflow. We recommend reading these references for a better understanding of this workflow.
These categories have prioritized boards that are populated during Milestone Planning:
Each column on the board represents a phase of the development workflow:
~Deliverablelabels. These labels signal that the issue is deemed a priority by the team.
workflow::ready for developmentcontains issues that are ready to pick in an upcoming milestone.
workflow::refinementcontains issues that require more investigation or to break them down into smaller units of work that can be delivered in a single milestone.
workflow::in devcontains ongoing work.
workflow::completecontains completed work.
The following diagram visualizes the milestone planning and delivery process:
For the reasons described above, the Remote Development category team has decided to modify parts of the Plan and Build & Test phases of the GitLab Product Development Flow to a more lightweight velocity-based estimation and planning process inspired by the widely-used and popular XP and Scrum methodologies.
The crux of these changes is focused around the following process phases:
These components allow us to provide realistic velocity-based estimates based on "Yesterday's Weather" historical velocity analysis.
IMPORTANT: note that these process changes do not represent a full adoption of XP or Scrum methodologies. Instead, they are a minimal and lightweight process "inspired" by XP and Scrum. The primary goal is to allow the team to provide realistic planning and delivery estimates to leadership based on accurate velocity measurements. The Pre-IPM and IPM processes are the minimal components which allow us to meet that goal.
To facilitate this process, especially around calculating emergent iterations based on velocity, we will use the GitLab Velocity Board Chrome Extension.
See this video for an overview of the extension, and also for an explanation of this general process, and why we need to use an extension to support it rather than the current standard GitLab Iteration and Board features.
This extension is in support of a GitLab OKR for Create. We plan to continue iterating in this area, with the goal of eventually having GitLab directly support this workflow.
TL;DR: Assign the
Next 1-3 releases milestone milestone to all issues that should be refined and prioritized in the next Pre-IPM meeting(s).
Next 1-3 releasesmilestone.
%"Next 1-3 releases"may have the
%"Next 4-7 releases"or
%"Next 7-13 releases"release applied, or alternately, they can be assigned to
%Awaiting Further Demand.
~rd-workflow::unprioritizedMUST NOT be left without a release applied. This should be enforced by automation. Use this issue search to identify Remote Development issues which are missing a milestone
This process identifies and validates higher-priority issues to be worked on in the upcoming releases. It is analogous to the Validation Track in the GitLab Product Flow, and should consist of many of the same steps and processes.
In addition to validating features, this process can also result in Engineering identifying high-priority issue which are necessary to address Technical Debt or "Friction".
There may be concerns about over-committing too many issues to the
%"Next 1-3 releases" release. However:
%"Next 1-3 releases"during every Pre-IPM, and moving them to
%"Next 1-3 releases"to a specific release, depending on what iteration they fall into (and we can always give ourselves a "buffer" by assuming, for our purposes, that only things slated to be completed by a certain time will be likely to be in the release, e.g., everything slated to be completed in the 2nd iteration of the month, which is a ~1+ week buffer before the actual release is cut).
See the following discussion thread for more context.
rd-workflow::unprioritizedissue which has the
%"Next 1-3 releases"milestone using the Remote Development issue template, then apply the
refinedissue into the
rd-workflow::prioritizedlane on the Iteration Planning board.
%"Next 1-3 releases"milestone applied (optionally include additional milestones for next
4-7releases, if these are being used) AND
Label is ~rd-workflow::unprioritizedand
Milestone is %Next 1-3 releasesand
Label is not one of ~refined
TODO:comments left in the description from the template once refinement is complete. If a section from the template is not applicable, delete it.
~refinedlabel, so that only refined issues appear in the
~"rd-workflow::unprioritized"list. Make sure you don't save this filter to the defualt board settings
~"rd-workflow::prioritized"list, based on their relative importance, whether they are blocking other issues, etc. They are prioritized by dragging them into the appropriate order in the
~"rd-workflow::prioritized"list, with the highest-priority issues being at the top, and the lowest-priority issues being at the bottom.
~"rd-workflow::prioritized"list, it should be assigned to the current
Iteration Cadence. We will eventually create an automation for this, but for now it must be done manually. The easiest way to do this is to search for
Iterationfield, and pick the top-most iteration. Then, the
Iteration Cadencefeature functionality will handle automatically rolling over any incomplete issues to the next iteration once the current iteration ends. Do NOT assign it to a future iteration, only the current iteration. We do this because of limitations in the GitLab Iteration feature which are incompatible with this process, and instead we rely on the GitLab Velocity Board Chrome Extension to automatically split the actual current iteration in the database into multiple future "virtual" iterations based on dynamic velocity calculations.
The "Pre-Iteration Planning" (Pre-IPM) meeting prepares for the Iteration Planning Meeting. It is analogous to "backlog refinement" in the standard GitLab product development flow.
During the Pre-IPM, the team will collaborate on creating/refining, organizing, and clarifying all issues which are to be prioritized for the upcoming iteration(s). This will normally involve Product and Engineering leaders on the team, but may also involve Design or other team members depending on the nature of the issues involved. The goal is to ensure that all issues which have been identified as a priority for the upcoming releases are properly refined, curated, prioritized, and ready for the wider team to briefly discuss and estimate in the next IPM.
If a single piece of work spans multiple projects/repos, there should be be a separate issue created for each MR in each repo. We cannot use the tasks feature, because boards cannot display individual tasks.
QUESTION: Why isn't there a
~rd-workflow::refined phase instead of using the
For a few reasons:
donephases are intuitive and self-explanatory. Also, the movement between
prioritizedis a sync process, which ensures the team leadership are all on the same page about current priorities.
TL;DR: Discuss and estimate each prioritized issue.
~"rd-workflow::prioritized"lane of the Iteration Planning board are reviewed by the team. The board should be unfiltered other than the standard
The "Iteration Planning Meeting", or "IPM" meeting is a weekly process where a team reviews the backlog and the current iteration status, estimates and prioritizes work for the next iteration, and uses issues as the single source of truth for discussions and progress. It is analogous to the "Weekly Cycle" in XP or "Sprint Planning" in Scrum.
The goal of the IPM is to ensure all issues for the upcoming iteration have been discussed, and estimated with weights as a team. Then, each issue will be worked on, and if there are commits to be made as part of the work, there should be a 1-to-1 relationship between the issue and MR.
The iteration cycle is one week long, and the team maintains one board for tracking their progress - the Iteration Planning board.
TODO: This can be automated in the future by adding functionality to the chrome extension. For now, it will be a manual process.
TL;DR: Assign issues to specific releases based on their calculated iteration
At this point, once all prioritized issues have been estimated, with the use of the GitLab Velocity Board Extension we will be able to know how they break down into future iterations.
Then, based on the dates of calculated iterations, we can reassign the issues from the
Next 1-3 releases milestone into specific milestones.
~"rd-workflow::unprioritizedlist of the Iteration Planning board. Note that the issue description may be incomplete/unrefined and high-level at this point.
%"Next 1-3 Releases"milestone to signal this.
~rd-workflow::prioritizedlist, in the appropriate position based on its priority relative to other issues.
We want to enforce that:
This is in order to facilitate accurate and granular velocity calculations and issue prioritization under this process. The merge request is the atomic unit of deliverable work in most cases, so it must be represented in the prioritization and calculations by being associated with one and only one issue.
If boards and epics allowed MRs to be added and estimated as well as issues, this would not be necessary - for feature/maintenance involving an MR, we could have the MR directly represent the full lifecycle of the discussion and implementation, and not have an issue at all.
We also cannot rely on the Crosslinking Issues feature (https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html), because this shows ALL linked MRs that have mentioned the issue anywhere, and cannot enforce this 1-1 relationship.
In order to enforce this via triage-ops automations
the first line of the issue should have the format:
MR: <MR link with trailing +>, and the first description line of the MR should be
Issue: <Issue link with trailing +>
MR: No MR. However, this should be rare, because most issues should have some sort of committed deliverable, even if it is only a documentation addition or update. If it is an issue which represents a larger piece of work split across smaller issues, then it should be promoted to an epic.
It is normal that team members may identify issues that need to be resolved promptly prior to the next planning cycle. This may be because they are blocking other prioritized issues, or just because a team member wishes to tackle an outstanding bug or small piece of technical debt.
In these situations, it is acceptable for a team member to take the initiative to create an issue, assign proper labels, estimate it, assign it to the current iteration, and work on it, as long as it does not adversely impact the delivery of other prioritized issues. However, if it becomes large or risks impacting other issues which were collectively prioritized as part of an IPM, then the issue should be brought up for discussion with the wider team in the next pre-IPM and/or IPM.
To assign weights to issues effectively, it's important to remember that issue weight should not be tied to time. Instead, it should be a purely abstract measure of the issue's significance. To accomplish this, the our team uses the Fibonacci sequence starting from weight 0:
Some issues are large in scope to start implementing, and/or still has too many unknowns/risks. In this case, we should break it down into smaller issues which can be implemented in a single iteration. These smaller issues should ideally have a weight of 3 or less, but never more than 5. Here's our process:
[Category] - Iteration Planning Placeholder for [description of work]. Here's an example: https://gitlab.com/gitlab-org/gitlab/-/issues/408093.
~blockedlabel can be applied so it is clear that this issue should is not ready for development. Unfortunately, we must still apply the
~Deliverablelabel to this issue, because that is the only way we can associate it with the Iteration Cadence for velocity calculations.
For certain scenarios, we handle remote development (RD) issues differently, categorizing them under the
rd-workflow::ignored label. These categories include:
type::ignore, such as reporting, blogs, OKRs, etc.
This approach ensures that these types of issues do not have an undesired impact on our velocity, and that our remote development process remains streamlined while accommodating different issue categories that may not fit the standard workflow.
The IDE Team communicates based on the following guidelines:
We operate using async communication by default. There are times when a sync discussion can be beneficial and we encourage team members to schedule sync calls with the required team members as needed.
Developer Cheatsheet: This is a collection of various tips, tricks, and reminders which may be useful to engineers on (and outside of) the team.
We want to make sure that all the fields of the Create:IDE team are approachable for outside contributors. In this case, if issues should be good for any contribution it should be treated with extra care. Therefore have a look at this excellent guide written by our own Paul Slaughter!
Cultivating Contributions from the Wider Community: This is a summary of why and how we cultivate contributions from the wider community.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
Automations should be set up via triage-ops if possible .
NOTE: Some of the following automations related to iterations are currently blocked by https://gitlab.com/gitlab-org/gitlab/-/issues/384885.
Ideally we should automate as much of the Remote Development Planning Process workflow as possible.
We have the following automation goals for the Remote Development Workflow. Unless otherwise noted, these rules are all defined in the triage-ops
policies/groups/gitlab-org/ide/remote-development-workflow.yml config file)
Goal: To ensure every issue in the category is assigned to an epic
Goal: To ensure category issues show up on the Iteration Planning board
~"Category:Remote Development"but no
~rd-workflowlabel should be added to
Goal: To avoid premature assignment of specific milestones before an issue has gone through IPM, to avoid getting this warning: https://gitlab.com/gitlab-org/gitlab/-/issues/411933#note_1419147845
%"Next 1-3 releases".
%"Next 1-3 releases".
%"Next 1-3 releases".
Goal: To ensure prioritized issues are in the correct state
Goal: To ensure closed issues are in the correct state
~"Category:Remote Development"which is closed must have the
Goal: Syncing Remote Development workflow and GitLab workflow labels
Goal: Ensure all prioritized issues have a milestone assigned
~rd-workflow::prioritizedbut no milestone should have
%"Next 1-3 releases"milestone assigned. (TODO: implement)
Goal: Ensure all issues with
~rd-workflow-unprioritized have a milestone assigned
~rd-workflow::unprioritizedbut no milestone should have: (TODO: implement)
%"Next 1-3 releases"
%"Next 4-7 releases"
%"Next 7-13 releases"
%Awaiting further demand
Goal: Apply correct ~rd-workflow label to reopened issues
Goal: To ensure issues and MRs are 1-1
~"Category:Remote Development"must have the first line of the description matching:
Issue: <issue link>\n\n. See https://docs.gitlab.com/ee/topics/gitlab_flow.html#linking-and-closing-issues-from-merge-requests (TODO: implement)
Goal: Automate Label Assignment for Ignored Issues
type::ignorelabel should have the
rd-workflow::ignoredlabel assigned. (TODO: implement)
Goal: Ensure all prioritized issues with an assignee have a weight assigned
~rd-workflow::prioritizedand an assignee but no weight should get a reminder note to either add a weight estimate or remove the assignee. (TODO: implement)