Create:Editor Team

1. You are here:
2. Engineering
3. Development Department
4. Dev Sub-department
5. Create Stage
6. Create:Editor Team

Maintained by:

David O'Regan

@oregand

On this page

• Overview
• 🤴 Team Principles
• 🚀 Team Members
• ☕ Team Category DRIs
• ☎️ How to reach us
• 🛠 How we work
  • 🙊 Ubiquitous terms
  • 💱 Changed terms
  • 💪 Accomplishments
  • ⏰ Meetings
    • 📆 Team Meetings
    • 🗒 Other Meetings
  • 👟 Iteration
  • 🤝 Collaboration
    • 📓 PM - EM
    • 🖌 Design
    • 🏷 Workflow labels
    • 🗺 Directional, Deliverable, Stretch and Discovery
  • 📊 Weekly Status Update
  • 🔖 Triage
  • 🔎 Backlog Refinement
  • 🌉 Planning Guidelines
  • 📝 Issue Guidelines
  • 🖇️ Issue Development Workflow
  • 😷 Issue Workflow Hygiene
  • 🏋️‍♂️ Capacity planning
    • What Weights to use
    • Time Off
    • Cross-functional Backlog
    • Merged Merge Request Types
• 👏 Communication
  • Ad-hoc sync calls
• 🍨 Team IC Gearing
• 🔗 Other Useful Links
  • Developer Cheatsheet
  • Fostering Wider Community Contributors
  • GitLab Unfiltered Playlist
  • Team OKRs

Overview

The Editor Team is part of Create Stage in the Dev Sub-department. We focus on multiple categories: Web IDE, Snippets, Static Site Editor, Content Editor, Source Editor, and Wiki.

Abbreviations used on this page:

• BE ➡️ Backend
• FE ➡️ Frontend
• SSE ➡️ Static Site Editor

🤴 Team Principles

Create:Editor Principles: What Are the Create:Editor Team Principles?

🚀 Team Members

The following people are permanent members of the Editor Engineering Team:

Engineering Manager & Engineers

Product, Design & Quality

☕ Team Category DRIs

☎️ How to reach us

Depending on the context here are the most appropriate ways to reach out to the Editor Group:

• GitLab epics/issue/MRs: @gl-editor
• Slack: #g_create_editor and @create-editor-team

You can view the team members' current time here: timezone.io/team/gl-createeditor

🛠 How we work

Following you will find all details how our team operates in all aspects of our work!

🙊 Ubiquitous terms

💱 Changed terms

💪 Accomplishments

At GitLab we like to encourage each team member to remember why they're awesome, given it's often easy for accomplishments to be forgotten or lost in the iterative pursuit of building loveable features. With this in mind, we encourage each team member to keep a Accomplishments document. This document serves as a list of their biggest wins across our CREDIT value's.

⏰ Meetings

The following meetings are regularly held for our team to ensure we work well together. For Team meetings we use Thursdays, and if anyone outside of Editor wants to join one of these meetings, just give us a heads-up.

❗️Important: For every meeting, the Editor 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.

📆 Team Meetings

These are regular meetings where the majority of the team will be participating. The main meeting day is Thursday.

Social Meeting

• When: Every 1st Thursday in a month.
• What: This is the perfect time for the team to talk about anything they like. It's focused on allowing people to share their personal lives with others, to the extent they feel comfortable, and allow us to get to know each other better.

Monthly Meeting

• When: Every 2nd Thursday in a month.
• What: This meeting is mostly a strategic one which gives the whole team an outlook to learn about what's coming in the next few releases, strategic updates within the group, and to discuss crazy-not-crazy ideas members in our Team have.

Milestone Kickoff Meeting

• When: Every 3rd Thursday in a month.
• What: We'll discuss the results of our planning Issue, and make sure the whole team is on the same page when it comes to the workload that's coming towards us. If there are any last-minute things to discuss for the Milestone, this is the right venue to do so.

Retro Meeting

• When: Every last Thursday in a month.
• What: We'll discuss the feedback of our async Team Retro, and decide on Action Items and Next Steps as applicable. The goal is to make our team more efficient and learn from our mistakes of the past, or continue doing really well on things that succeeded.

Product/UX Weekly

• When: Every Thursday
• What: Weekly sync about the Editor group's Product, Design, and UX Research efforts

🗒 Other Meetings

Backlog Refinement

• When: TBU
• What: A meeting to do an up-to-90min Backlog Refinement session where a few people of the team come together in reviewing some of our Epics and other Backlog Tasks, to make sure we have up-to-date Epics. The goal is to ensure people can take work from them at any point in time. We'll focus on different Epics in each meeting, in line with our team priorities. Read more about it in the Backlog Refinement section.

Design, Product & Engineering Sync

• When: TBU
• What: A meeting allowing to sync the three departments about current and upcoming work.

👟 Iteration

Iteration is key to success for GitLab and every developer inside the company. In our team, we try to work as iteratively as possible. Following the company's key metrics we aim for small and focused MRs.

Some examples of successful Iteration Work

• Remove staging from commit workflows in the WebIDE
• Design View Zooming capabilities
• Split up work to replace ACE with Monaco
• Design Upload Additions Drag-n-DropCopy-Paste
• Initial implementation of Static Site Editor config file

The approach can be summarized like so:

GitLab.com is the source of truth. Everything that is not shipped and live is not done.

🤝 Collaboration

"Talent wins games, but teamwork and intelligence win championships." – Michael Jordan

📓 PM - EM

Our team follows the general Product Development Flow but this guide is intended to elaborate on a few elements to represent the team's internal flavor, emphasize certain points, and smooth the collaboration.

🖌 Design

• Feedback from the group will be solicited via the design management area of the related issue.
  • Designs needing feedback from the group should be uploaded to the Design tab.
  • The group will be mentioned for general awareness
  • Specific people will be mentioned when asking for direct feedback
  • Designs still in the early stages will have the prefix of concept to the design files
• When designs are ready for planning and development
  • The designer will create a separate page in Figma called Specifications to collate what is to be the solution to be shipped.
    • This design may change through learning more information during the building phase. Changes should be logged on the "Specifications" page in a changelog so that there is a history trail to follow.
  • The proposed solution screenshots should be uploaded to the Design tab
    • Old concept designs should be archived to reduce the noise in following the issue.
    • The naming of the proposed solution screenshots should remain the same to leverage version history to track changes.
    • There might be cases where uploading the whole flow is not ideal so this should be noted in the Proposal area.

🏷 Workflow labels

Let's look at a few of the workflow labels we should take as important cornerstones of our development workflow.

workflow::design

This is the general label for all things design and validation. For issues that need further exploration in either design approach or validation, it is recommended to create a separate issue (see below). This is to make the parent issue easier to parse the important decisions when it comes to the build phase.

• Design exploration: A separate issue will be created in the gitlab-design project and linked to the parent issue.
• Problem/solution validation: A separate issue will be created in the ux-research project and linked to the parent issue.

workflow::planning breakdown

This is the point where EM’s join the efforts, unless requested earlier. For work that requires UI or UX changes, it’s expected that they have gone through the design phase already. More details can be found on this handbook page.

Should a feature require backend and frontend work that issue will receive its weight based on relevant child issues that are created as part of the breakdown. The labels frontend-weight::x and backend-weight::x will help keep track of these.

If needed we will create a Technical Discovery issue for features that have a higher level of complexity. A Technical Discovery Issue should produce either an Epic, another Issue, or feedback into the spawning Issue.

Epic

If the team determines that multiple issues must be created. An Epic should be created. All of the new issues created including the Technical Discovery issue will be assigned to the Epic. The issues will be displayed on the Epic in order of priority. The issues will include dependencies so that the order the issues must be completed in is transparent. An Epic can be spread over multiple releases to support the GitLab Core Values around Iteration

Consider creating nested epics to create logical structures and don't lose track of delivering value to customers whenever possible.

Issue

If only one issue is created, the Technical Discovery proved that a simple solution can be implemented. The traditional Product Workflow should be followed.

workflow::scheduling

For an Issue to reach the scheduling phase, its weight must be set. It can be treated similar to the workflow::ready for development state, except it's in a holding pattern using the %Backlog% milestone, until a proper milestone, gets assigned.

workflow::ready for development

A feature that is ready for development should be able to be picked up at any point by a contributor and should have a provisional milestone assigned. If such a feature requires BE and FE, the corresponding features should also be in this state.

🗺 Directional, Deliverable, Stretch and Discovery

Product will provide the directional items for upcoming milestones and the EM will make sure that these get prioritized accordingly. To account for enough resource planning time it's recommended to have direction items ready ~10 days prior to the next milestone. We need to account for engineers, who might be critical for scheduling the work, might be Out of Office (OOO) or live in the APAC zone.

Engineering will use the ~Deliverable label on any issue the team commits to during the milestone. Only features that reached the scheduling or ready for development phase can receive the ~Deliverable label. Issues that might be in the planning breakdown phase, but on track for an upcoming Milestone, might receive the ~Discovery label to indicate that Engineering discovery needs to happen on it.

Should issues be added during the milestone (unexpected work), they will not receive the ~Deliverable label.

As Engineer, plan accordingly and communicate changes early.

📊 Weekly Status Update

The weekly status update is something that happens asynchronously, by posting a comment on the current milestone's planning issue. The current planning issue is always linked in the Slack Channel description, or the meeting document.

A template for the status update can be found here.

🔖 Triage

Triaging is a team-effort. Every week the EM, PM and UX lead are pinged on the GitLab Triage Issue. This lists a lot of issues that have no weight or details on it. The EM, PM and UX lead should look to triage these ASAP and follow these guidelines:

• All bugs should be looked at by the EM, all feature's should be looked at by the PM and then Engineers/UX should be pinged on those issues as needed.
• If it's a high priority bug, please assign it to the current or next Milestone right away so we can address it within time.
• If the issue seems very specific, or it's something that's probably not being addressed anytime soon please apply the %"Awaiting further demand" Milestone.
• If the issue seems like a duplicate, please look for a similar issue, link them and close the newer one.
• If the issue fits for a Backlog Refinement session, please apply the appropriate label.
• In any other case, it's probably fine to apply the %Backlog Milestone, and making sure all appropriate labels are assigned.

🔎 Backlog Refinement

This practice is very important for our team to make sure our backlog is actually triaged and properly structured. The content of the Session is always defined in advance and documented as meeting in the general Editor Meeting Doc. In the meeting we do one of the following:

• Talk through current workstreams and make sure we are on track regarding bigger ambitious goals so we don't overlook anything (e.g. including docs, quality team, or UX)
• Look through any issue in our group that has the ~"Backlog Refinement::Editor" label applied and make sure to triage it based on any current directions, or with our two backlog epics.
  • Tech Debt Epic
  • Improvements Epic
  • All issues going into these Epics need to fulfill our general Issue guideline.

Sometimes the issue needs next steps defined, so we use this snippet to define the DRI and the actions that need to be taken next outside of the meeting.

🌉 Planning Guidelines

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.

• Architecture Plan: A high-level vision of a technical approach that is shown to solve user problems. This plan includes a formulation of specific quality attributes that are important for this use cases (such as performance, usability, or security). It also includes an outline of technical approaches that will satisfy these quality attributes in addition to the functional requirement. A spike effort should be created to verify and explore the technical approach for an architecture plan. The spike could result in new architectural concerns, resulting in an iteration of the plan.
• Iteration Plan: A plan for how we'll iteratively implement an Architecture Plan or another objective. This can be composed of low-level technical steps, or medium-level slices of use cases. The iteration plan should result in a set of issues (and possible epics) with clearly defined scope and weights.

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.

📝 Issue Guidelines

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:

• Treat the wider community as the primary audience (see relevant summary for rationale).
• Provide a meaningful title that describes a deliverable result.
  • ✅ Add a cancel button to the wiki page editing view
  • ✅ Automatically save SSE Drafts after 2 seconds of inactivity
  • ❌ Make WebIDE better
• Provide a meaningful description that clearly explains the goal of the issue, and provide some technical details if necessary.
• Should there be critical implementation steps or other useful ways to create small tasks as part of the issue, please use a checklist as part of the issue descriptions?
• The issue should have a weight assigned

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.

🖇️ Issue Development Workflow

While "Workflow Labels" mentioned above are used primarily for setting up the PM-EM communication, the group has also adopted a certain development workflow for the issues to make the process reliable and predictable.

Once you're ready to work on an issue, you mark it with the workflow::"in dev" label as the starting point. From there, the process primarily follows the guideline:

It is advised to manually transition issues from one label to another and not use the "Closes" hook in the description of an MR. This will prevent automatically closing issues without them being verified on production.

😷 Issue Workflow Hygiene

In the Create:Editor team we leverage an automatic issue hygiene system via the triage bot. This helps to ensure issues and label hygieneare respected, currently our rules are:

• If a issue is assigned the "ready for development" label but has no technical labels, they are assigned automatically and a member of the team is pigned to verify the issue.
• If an issue is asigned the "verification" label a team memeber is pinged and asked to review it so that the issue can be closed.

🏋️‍♂️ Capacity planning

We use weights to plan capacity in our team for any given milestone. Our planning sheet uses the following formula to calculate the teams capacity:

FLOOR((AverageDaysPerCycle - DaysOff) * AverageCapacity/AverageDaysPerCycle * CapacityKey )

Using this formula, we can calculate different capacities per engineer, and this should give us an overall feel for how much work we can commit to as a team. The goal here is definitely not to squeeze every last second out of people, but to make sure we as a team do not overcommit to work. The work we commit to is communicated to customers and other stakeholders within the company.

What Weights to use

Do not relate issue weight directly to time (see GitLab's relevant guide on weighting issues).

To cultivate engagement from the wider community, do not weigh an issue according to a certain assignee or time estimate. This creates hidden coupling to the weight, which can deter the wider community from reading the weight in a meaningful way. Issue weights are a completely abstract measurement and should describe the weightiness of the issue as it stands by itself (see relevant guideline).

• Weight 1: Really simple and small (for example, changing copy text or 1-2 lines of CSS). Most of these issues should have a good for new contributors and/or Hackathon - Candidate label attached.
• Weight 2: Straightforward, but involves updating actual behavior (for example, fixing and testing a trivial bug).
• Weight 5: Changing the behavior of pre-existing modules, or adding significant new behavior (for example, making the Web IDE left-sidebar collapsible).
• Weight 9: Large fundamental rewrite and should probably be investigated for a more iterative approach.

❗️Any weight going above 5 is usually a warning sign that the work is quite complex, and should probably be broken down into smaller issues.

Time Off

Team members should add any planned time off in the "PTO by Roots" slack app, so that the Engineering Manager can use the proper number of days off during capacity planning.

Cross-functional Backlog

(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open SUS-impacting issues and bugs.

Merged Merge Request Types

(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.

👏 Communication

The Editor Team communicates based on the following guidelines:

1. Always prefer async communication over sync meetings.
2. Don't shy away from arranging a sync call when async is proving inefficient, however always record it to share with team members.
3. By default communicate in the open.
4. All work-related communication in Slack happens in the #g_create_editor channel.
5. We use the following emoji reactions in Slack for conveying action when writing a response is unnecessary:
   • e.g.: Added comment on a GitLab Issue, Left a note on a Google Doc.
     1. :ack: = acknowledgment as in I have taken note of the message/request and will action - not appropriate for questions (see :thumbsup:)
     2. :thumbsup:  = acknowledgment as in I agree with a statement/question - appropriate for binary questions asking approval/consensus (as in this one)
     3. :thumbsdown: = acknowledgment as in I disagree with a statement/question - appropriate for binary questions asking approval/consensus (as in this one) - encouraged to follow up with a text response
     4. :white_check_mark: = acknowledgment as in I have taken action on a request
     5. :speech_balloon: = acknowledgment as in I have added to the conversation with a comment/question outside of Slack.

Ad-hoc sync calls

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.

When scheduling a sync call consider doing the following:

1. Add it to the team's shared calendar and make sure to attach an agenda doc. This agenda doc should also be referenced in the Editor team's meeting document.
2. Notify the team of the call in the #g_create_editor Slack channel.
3. Record the call and upload the recording to the Create:Editor playlist on the GitLab Unfiltered YouTube channel.
4. Remember to add a link to the recording in the agenda document.
5. Notify the team of the newly available recording in the #g_create_editor Slack channel.
6. For these meetings to be automatically recorded, you must have pre-configured it in your Zoom settings and add [REC] to the recording title as per the handbook instructions. These calls will be placed in the GitLab Videos Recorded folder in Google Drive on an hourly basis.

🍨 Team IC Gearing

As an engineering organization, we have defined a default ratio for the number of Staff Engineers per team. While this makes sense for most teams, the Create:Editor team has a slightly different ratio due to the nature of the team.

Exception Ratio: 2 Staff Engineers per Team

Justification: Create:Editor is responsible for the entire Editor experience at GitLab.com which spans several categories. Create:Editor requires 3 Staff Level Engineers, 1 Backend Staff Engineer, and 2 Frontend Staff Engineers. There is usually a maximum of one Staff Engineer assigned to a Backend team and one Staff Engineer assigned to a Frontend team. The Create:Editor team is an exceptional case since it's a Fullstack team comprised of Backend and Frontend engineers with multiple Backend and Frontend topics. Listed below is a more detailed explanation of why the team is an exceptional case:

• There are currently Frontend only refactors, proposals, and rearchitectures in progress or being planned that require high-level technical expertise.
• It is currently necessary to have at least one Staff Backend Engineer who will serve as a technical expert for all work related to the Backend and potential rearchitectures of certain categories.

🔗 Other Useful Links

Developer Cheatsheet

Developer Cheatsheet: This is a collection of various tips, tricks, and reminders which may be useful to engineers on (and outside of) the team.

Fostering Wider Community Contributors

We want to make sure that all the fields of the Create:Editor 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.

GitLab Unfiltered Playlist

The Editor Group collates all video recordings related to the group and its team members in the Editor playlist in the GitLab Unfiltered YouTube channel.

Team OKRs

The Create:Editor team OKR's are available through GitLab