The Editor Team is part of Create Stage in the Dev Sub-department. We focus on multiple categories: Web IDE, Snippets, Static Site Editor, and Wiki.
Abbreviations used on this page:
The following people are permanent members of the Editor Engineering Team:
Engineering Manager & Engineers
| Person | Role |
|---|---|
| David O'Regan | Engineering Manager, Create:Editor |
| Francisco Javier López | Staff Backend Engineer, Create:Editor |
| Paul Slaughter | Senior Frontend Engineer, Create:Editor |
| Denys Mishunov | Staff Frontend Engineer, Create:Editor |
| Enrique Alcántara | Senior Frontend Engineer, Create:Editor |
| Himanshu Kapoor | Senior Frontend Engineer, Create:Editor |
| Chad Woolley | Senior Backend Engineer, Create:Editor |
Product, Design & Quality
| Person | Role |
|---|---|
| Eric Schurter | Senior Product Manager, Create:Editor |
| Michael Le | Senior Product Designer, Create:Editor |
| Anastasia McDonald | Software Engineer in Test, Create:Editor |
| Michael Henriksen | Senior Security Engineer, Application Security, Create:Code Review, Create:Editor, Create:Ecosystem |
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-teamYou can view the team members' current time here: timezone.io/team/gl-createeditor
Following 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 |
Web IDE |
A web-based multi-file code editor |
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 |
Static Site Editor |
Visual editor for Markdown content hosted in a static site |
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 (GFM) in the GitLab application |
| 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.
This 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, emphasise 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::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.
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 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.
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.
Triaging is a team-effort. Every week our engineers are pinged on the GitLab Triage Issue. This lists a lot of issues that have no weight or details on it. Every Engineer should look at triaging 2 Issues / week 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. We meet every other week in order to do some sync backlog discussion. 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 take next outside of the meeting.
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 staging.
We use weights to plan capacity in our team for any given milestone. Our planning sheet uses 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).
To cultivate engagement from the wider community, do not weight 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).
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.
The Editor Team communicates based on the following guidelines:
:ack: = acknowledgement as in I have taken note of the message/request and will action - not appropriate for questions (see :thumbsup:):thumbsup: = acknowledgement as in I agree with a statement/question - appropriate for binary questions asking approval/consensus (as in this one):thumbsdown: = acknowledgement 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: = acknowledgement as in I have taken action on a request:speech_balloon: = acknowledgement 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: The default gearing ratio typically has a staff-level engineer for both backend and frontend technologies. This is aligned with teams having separate backend and frontend managers. Since the Create:Editor team is a fullstack team with one manager, the default gearing ratio would be to have only one staff engineer working with the one manager. The Create:Editor team is responsible for a large number of product categories. These categories not only span backend and frontend but require highly skilled engineer expertise on both sides.
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.
