Abbreviations used on this page:
The strongest team makes the most progress.
The following people are permanent members of the Editor Engineering Team:
Engineering Manager & Engineers
|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|
|Francisco Javier López||Staff Backend Engineer, Create:Editor|
|Himanshu Kapoor||Senior Frontend Engineer, Create:Editor|
|Paul Slaughter||Senior Frontend Engineer, Create:Editor|
Product, Design & Quality
|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, Ecosystem:Integrations|
Depending on the context here are the most appropriate ways to reach out to the Editor Group:
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!
||Transitioning from reading to editing without navigating to a new page|
||A web-based multi-file code editor|
||Small, sharable bits of code saved for easy access|
||Built-in, git-backed knowledge base|
||Visual editor for Markdown content hosted in a static site|
||Source Editor is framework-agnostic and can be used in any application, including both Rails and Vue|
||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|
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.
crazy-not-crazyideas members in our Team have.
Milestone Kickoff Meeting
Next Stepsas 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.
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.
conceptto the design files
Specificationsto collate what is to be the solution to be shipped.
conceptdesigns 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.
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.
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
frontend work that issue will receive its weight based on relevant child issues that are created as part of the breakdown. The labels
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.
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.
If only one issue is created, the Technical Discovery proved that a simple solution can be implemented. The traditional Product Workflow should be followed.
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
ready for development phase can receive the
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
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.
%BacklogMilestone, 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 taken 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 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 contributorsand/or
Hackathon - Candidatelabel 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.
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:= 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 Recordedfolder 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 full-stack 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 Create:Editor team OKR's are available through Ally.io