The Editor Team is part of Create Stage in the Dev Sub-department. We focus on multiple categories: Remote Development, Web IDE, Content Editor, Source Editor, GitLab Pages, Snippets (deprioritized), and Wiki (deprioritized).
Abbreviations used on this page:
Create:Editor Principles: What Are the Create:Editor Team Principles?
The following people are permanent members of the Editor Engineering Team:
Engineering Manager & Engineers
| Person | Role |
|---|---|
| David O'Regan | Engineering Manager, Create:Editor |
| Chad Woolley | Senior Backend Engineer, Create:Editor |
| Denys Mishunov | Staff Frontend Engineer, Create:Editor |
| Enrique Alcántara | Senior Frontend Engineer, Create:Editor |
| Guillermo De los Santos García | Senior Backend Engineer, Create:Editor |
| Himanshu Kapoor | Senior Frontend Engineer, Create:Editor |
| Kassio Borges | Senior Backend Engineer, Create:Editor |
| Paul Slaughter | Staff Frontend Engineer, Create:Editor |
| Tomas Vik | Senior Fullstack Engineer, Create:Editor |
| Vishal Tak | Senior Backend Engineer, Create:Editor |
Product, Design & Quality
| Person | Role |
|---|---|
| Eric Schurter | Senior Product Manager, Create:Editor |
| Category | DRI |
|---|---|
| Content Editor | Enrique Alcantara, Himanshu Kapoor |
| Source Editor | Denys Mishunov |
| Remote Development | David O'Regan, Vishal Tak |
| Web IDE | Paul Slaughter |
| Pages | Vishal Tak, Kassio Borges |
| Wiki (deprioritized) | David O'Regan |
| Snippets (deprioritized) | David O'Regan |
Depending on the context here are the most appropriate ways to reach out to the Editor Group:
@gl-editor#g_create_editor and @create-editor-teamFollowing you will find all details how our team operates in all aspects of our work!
| Term | Meaning |
|---|---|
in context editing |
Transitioning from reading to editing without navigating to a new page |
Snippets |
Small, sharable bits of code saved for easy access |
Live Preview |
Preview JavaScript and static sites in real-time in the Web IDE |
Wiki |
Built-in, git-backed knowledge base |
Source Editor |
Source Editor is framework-agnostic and can be used in any application, including both Rails and Vue |
Content Editor |
The Content Editor is a UI component that provides a WYSIWYG editing experience for GitLab Flavored Markdown (GLFM) in the GitLab application |
Web IDE |
A web-based multi-file code editor |
Remote Development |
Use a container / remote machine as a full-featured development environment that connects to the GitLab Web IDE |
GitLab Pages |
Publish static websites directly from a repository in GitLab. |
| Old Term | New Term |
|---|---|
Editor Lite |
Source Editor |
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.
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.
These are regular meetings where the majority of the team will be participating. The main meeting day is Thursday.
Social Meeting
Monthly Meeting
crazy-not-crazy ideas members in our Team have.Milestone Kickoff Meeting
Retro Meeting
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
Backlog Refinement
Design, Product & Engineering Sync
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
The approach can be summarized like so:
GitLab.com is the source of truth. Everything that is not shipped and live is not done.
"Talent wins games, but teamwork and intelligence win championships." – Michael Jordan
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.
concept to the design filesSpecifications to collate what is to be the solution to be shipped.
concept designs should be archived to reduce the noise in following the issue.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.
workflow::refinement
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.
Epic
If the team determines that multiple issues must be created. An Epic should be created. All of the new issues created including the Architecture Plan 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 Architecture Plan 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.
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.
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:
%"Awaiting further demand" Milestone.%Backlog Milestone, and making sure all appropriate labels are assigned.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:
~"Backlog Refinement::Editor" label applied and make sure to triage it based on any current directions, or with our two backlog epics.
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.
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 wiki page editing viewAutomatically save SSE Drafts after 2 seconds of inactivityMake WebIDE betterIt'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.
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.
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:
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.
Do not relate issue weight directly to time (see GitLab's relevant guide on weighting issues). Issue weights are a completely abstract measurement and should describe the weightiness of the issue as it stands by itself (see relevant guideline).
We on the Editor team weight issues by leveraging the Fibonacci Sequence.
good for new contributors and/or Hackathon - Candidate label attached.❗️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.
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.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open 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.
The Editor Team communicates based on the following guidelines:
:ack: = acknowledgment as in I have taken note of the message/request and will action - not appropriate for questions (see :thumbsup:):thumbsup: = acknowledgment as in I agree with a statement/question - appropriate for binary questions asking approval/consensus (as in this one):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:white_check_mark: = acknowledgment as in I have taken action on a request:speech_balloon: = acknowledgment as in I have added to the conversation with a comment/question outside of Slack.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:
[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.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:
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: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.
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.
The Create:Editor team OKR's are available through GitLab