The team is part of Create Stage in the Dev Sub-department. We focus on multiple categories: Remote Development
, Web IDE
, and the GitLab VS Code Extension
.
TODO: Update this link once OKRs are moved to ~group::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, Create:IDE |
Chad Woolley | Senior Backend Engineer, Create:IDE |
Enrique AlcΓ‘ntara | Senior Frontend Engineer, Create:IDE |
Hunar Khanna | Senior Backend Engineer, Create:IDE |
Paul Slaughter | Staff Frontend Engineer, Create:IDE |
Tomas Vik | Senior Fullstack Engineer, Create:IDE |
Vishal Tak | Senior Backend Engineer, Create:IDE |
Product, Design & Quality
Person | Role |
---|---|
Eric Schurter | Senior Product Manager, Create:IDE |
Nivetha Prabakaran | Software Engineer in Test, Create:IDE |
Category | DRI |
---|---|
Remote Development | Vishal Tak |
Web IDE | Paul Slaughter |
GitLab VS Code Extension | Tomas Vik |
Depending on the context here are the most appropriate ways to reach out to the IDE Group:
@gl-editor
#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 and GitLab VS Code Extension categories.
The Remote Development team has decided to use an alternate process for the following reasons:
The Web IDE and GitLab VS Code Extension are significantly different features, and do not share many of these same concerns or desires, therefore they 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.
The Web IDE and GitLab VS Code Extension still use 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 two processes/meetings:
These two 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.
The Pre-Iteration Planning Meeting (Pre-IPM) meeting is a necessary step to prepare for the Iteration Planning Meeting. It is analogous to "backlog refinement" in the standard GitLab product development flow.
During the Pre-IPM meeting, the leaders on 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 of the Pre-IPM is to ensure that all issues which are to be prioritized in the upcoming iteration(s) are ready for the wider team to briefly discuss and estimate in the next IPM.
The goal of this meeting is to ensure that the backlog is well-defined, prioritized, and that each issue is estimable and deliverable within a single iteration. The team works together to size each story and determine the iteration capacity. This helps us commit to completing the work within the upcoming iteration(s).
The outcome of the Pre-IPM process is a set of curated issues that represent the work to be done. These issues will be used to populate the team's Iteration board. For each category, a placeholder issue will be created, following a specific title format. This placeholder issue will be used during the IPM to track progress and ensure that the team stays on track.
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.
The board's workflow involves the following (TODO: Add triage bot automation to enforce/automate as much of this as possible):
~Deliverable
and ~Category:Remote Development
labels have been prioritized as part of the Pre-IPM meeting, and will show up on the board either in the Open list or in the Current Iteration list.~workflow::ready for development
or subsequent ~workflow::*
label assigned - i.e., not ~workflow::refinement
or previous.~workflow::in dev
) and have commits associated with them, they should have a one-to-one relationship with an MR.~Deliverable
label is considered part of the backlog and will not show up on the board, and it should have the ~workflow::refinement
label applied.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.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.