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:
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 |
Himanshu Kapoor | Senior Frontend Engineer, Create:Editor |
Kassio Borges | Senior Backend Engineer, Create:Editor |
Paul Slaughter | Staff Frontend Engineer, Create:Editor |
Vishal Tak | Senior Backend Engineer, Create:Editor |
Product, Design & Quality
Person | Role |
---|---|
Eric Schurter | Senior Product Manager, Create:Editor |
Michael Le | Senior Product Designer, Create:Editor |
Category | DRI |
---|---|
Content Editor | Enrique Alcantara |
Snippets | David O'Regan |
Wiki | David O'Regan |
Source Editor | Denys Mishunov |
Web IDE | David O'Regan |
Pages | Vishal Tak |
Static Site Editor | David O'Regan (Soon to be deprecated) |
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-team
You 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 (GLFM) 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.
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::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 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.
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 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 view
Automatically save SSE Drafts 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.
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).
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).
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