The team is part of Create Stage in the Dev Sub-department. We focus on multiple categories: Remote Development
and the Web IDE
.
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
Person | Role |
---|---|
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 |
Alper Akgun | Staff Fullstack Engineer, Create:IDE |
Chad Woolley | Senior Backend Engineer, Create:IDE |
Denys Mishunov | Staff Frontend Engineer, AI-powered:AI Framework |
Enrique Alcรกntara | Senior Frontend Engineer, Create:IDE |
Hunar Khanna | Senior Backend Engineer, Create:IDE |
Maลgorzata Ksionek | Staff Backend Engineer, AI Powered:AI Framework |
Paul Slaughter | Staff Frontend Engineer, Create:IDE |
Tomas Vik | Senior Fullstack Engineer, Create:IDE |
Vishal Tak | Staff Backend Engineer, Create:IDE |
Product, Design & Quality
Person | Role |
---|---|
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 |
Tomas Vik | Senior Fullstack Engineer, Create:IDE |
Vishal Tak | Staff Backend Engineer, Create:IDE |
Category | DRI |
---|---|
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:
#g_create_ide
@create-ide-team
(entire team) and @create-ide-engs
(just engineers)โ๏ธ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:
~Category:[Category]
and ~Deliverable
labels. These labels signal that the issue is deemed a priority by the team.workflow::ready for development
contains issues that are ready to pick in an upcoming milestone.workflow::refinement
contains 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 dev
contains ongoing work.workflow::complete
contains 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.
Process:
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).
~rd-workflow::unprioritized
label assigned.Next 1-3 releases
milestone.%"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 %Backlog
or %Awaiting Further Demand
.~rd-workflow::unprioritized
MUST 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 milestoneExplanation:
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 ~"rd-workflow::prioritized"
.%"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.
TL;DR:
rd-workflow::unprioritized
issue which has the %"Next 1-3 releases"
milestone using the Remote Development issue template, then apply the refined
label.refined
issue into the rd-workflow::prioritized
lane on the Iteration Planning board.~"rd-workflow::unprioritized"
AND%"Next 1-3 releases"
milestone applied (optionally include additional milestones for next 3-4
/4-7
releases, if these are being used) AND~refined
labelLabel is ~rd-workflow::unprioritized
and Milestone is %Next 1-3 releases
and 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.~refined
label,
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
of the 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 RD
in the Iteration
field,
and pick the top-most iteration. Then, the Iteration Cadence
feature 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.Explanation:
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 ~refined
label?
For a few reasons:
unprioritized
, prioritized
, and done
phases
are intuitive and self-explanatory. Also, the movement between unprioritized
and prioritized
is a sync process, which ensures the team leadership
are all on the same page about current priorities.Process:
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 ~"Category:Remote Development"
label.Explanation:
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::unprioritized
list 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.~refined
label~rd-workflow::prioritized
list,
in the appropriate position based on its priority relative to other issues.~rd-workflow::done
list.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
(https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#automations-for-remote-development-workflow),
the first line of the issue should have the format: MR: <...>
:
MR: Pending
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.~blocked
label can be applied so it is clear that this issue should is not ready for development. Unfortunately, we must still apply the ~Deliverable
label 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
:
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:
Team members should add any planned time off in the "Time Off by Deel" slack app, so that the Engineering Manager can use the proper number of days off during capacity planning.
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.
The IDE Group collates all video recordings related to the group and its team members in a playlist in the GitLab Unfiltered YouTube channel.
(Sisenseโ) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(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.
(Sisenseโ) Flaky test are problematic for many reasons.
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
Automation:
Goal: To ensure category issues show up on the Iteration Planning board
Automation:
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
Automation:
%"Next 1-3 releases"
.%"Next 1-3 releases"
.%"Next 1-3 releases"
.Goal: To ensure prioritized issues are in the correct state
Automation:
Goal: To ensure closed issues are in the correct state
Automation:
Goal: Syncing Remote Development workflow and GitLab workflow labels
Automation:
Goal: Ensure all prioritized issues have a milestone assigned
Automation:
~rd-workflow::prioritized
but no milestone should have %"Next 1-3 releases"
milestone assigned. (TODO: implement)Goal: Ensure all issues with ~rd-workflow-unprioritized
have a milestone assigned
Automation:
~rd-workflow::unprioritized
but no milestone should have: (TODO: implement)
~needs-milestone
label applied~rd-workflow::unprioritized
:%"Next 1-3 releases"
%"Next 4-7 releases"
%"Next 7-13 releases"
%Backlog
%Awaiting further demand
Goal: Apply correct ~rd-workflow label to reopened issues
Automation:
Goal: To ensure issues and MRs are 1-1
Automation:
~"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
Automation:
type::ignore
label should have the rd-workflow::ignored
label assigned. (TODO: implement)Goal: Ensure all prioritized issues with an assignee have a weight assigned
Automation:
~rd-workflow::prioritized
and an assignee but no weight should get a reminder note to either add a weight estimate or remove the assignee. (TODO: implement)