The following people are permanent members of the Create:Editor BE Team:
|Matt Nohr||Backend Engineering Manager, Create:Knowledge & Create:Editor|
|Francisco Javier López||Senior Backend Engineer, Create:Editor|
|Vijay Hawoldar||Senior Backend Engineer, Create:Editor|
The following members of other functional teams are our stable counterparts:
|Kai Armstrong||Senior Product Manager, Create:Editor|
|Mike Nichols||Senior Product Designer, Create:Editor|
|Marcia Ramos||Senior Technical Writer, Create (Source Code, Knowledge, Static Site Editor, Editor)|
|Evan Read||Senior Technical Writer, Create (Gitaly, Gitter)|
|Paul Slaughter||Senior Frontend Engineer, Create:Editor|
|Denys Mishunov||Senior Frontend Engineer, Create:Editor|
|Himanshu Kapoor||Senior Frontend Engineer, Create:Editor|
|Tomas Vik||Frontend Engineer, Create:Editor|
|Darva Satcher||Senior Manager, Engineering, Create (Interim)|
|Roman Kuba||Frontend Engineering Manager, Create:Knowledge & Create:Editor|
|Anastasia McDonald||Software Engineer in Test, Create:Editor|
|Marcel van Remmerden||Product Design Manager, Create|
|Katherine Okpara||UX Researcher, Create|
|James Ramsay||Group Manager, Product Management, Create|
A full-featured Integrated Development Environment (IDE) built into GitLab so you can start contributing on day one with no need to spend days getting all the right packages installed into your local dev environment.
Store and share bits of code and text with other users. This category is at the "minimal" level of maturity.
Do pair programming directly in the Web IDE. This category is planned, but not yet available.
This chart shows the progress we're making on hiring. Check out our jobs page for current openings.
There is a general onboarding issue assigned to all GitLab team members by People Ops on your first day.
The Create:Editor BE team has participated in the GitLab Engineering Internship program. Interns are treated as equal members of the team and will follow all of the processes and procedures all team members follow.
All GitLab Team members are expected to follow the General GitLab communications guidelines.
Iteration is everyone's responsibility and it should be performed throughout the development lifecycle. PM and UX iterate as they are developing the product requirements and designs. The Engineering Teams pick up the work and then doing the following:
Create MRs for the Issues
Iteration during Backlog Refinement
Iteration during creation of the MRs
While working on an MR, sometimes additional work is discovered. When additional work is discovered, ask the following questions:
Iteration during the Code Review
During the Code Review, maintainer(s) will make recommendations. For each code review comment:
In general, we use the standard GitLab engineering workflow. To get in touch
with the Create:Editor BE team, it's best to create an issue in the relevant project and add the
~backend labels, along with any other
appropriate labels. Then, feel free to ping the relevant Product Manager and/or
Engineering Manager, as listed above.
For more urgent items, feel free to use #g_create_editor on Slack.
Every week the backend engineering team completes a backlog refinement process to review upcoming issues and provide weights so the issues can be planned and scheduled for upcoming milestones.
This process happens in three steps over the course of one week.
Every Friday the engineering manager will identify issues that need to be refined the following week. On average we will try to refine 3-6 issues per week. When picking issues to refine, here are some places to look:
Once identified, the engineering manager will apply the “Backlog Refinement::Editor” and “workflow::planning breakdown” label, which will indicate the issues are ready for refinement.
Early in the next week, each backend engineer on the team will look at the list of issues selected for backlog refinement:
For each issue, each team member will review the issue and provide the following information:
On the following Friday, after engineers have had a chance to provide input, the engineering manager will use the input to update the following information:
For any issues that were not discussed and given a weight, the engineering manager will work with the engineers to see if we need to get more information from PM or UX.
Career development conversations in the Create:Editor BE team are centered around a Career Development Sheet that is based on the Engineering Career Matrix for Individual Contributors. The sheet lists the expected current level behaviors on the left, the next level behaviors on the right, and uses colored columns in between to visually represent the extent to which the individual has shown to have grown from the current level to the next. Columns to the right of a next level behavior are used to collect specific examples of that behavior, which serve as evidence of the individual's growth.
Both the matrix and the sheet are Works in Progress; the development of the career matrix is tracked in an epic, and as the matrix evolves, the sheet will be updated to match.
In the scenario where an Engineering Manager (EM) is unexpectedly out of the office we will immediately implement this backup plan to support a smooth and stable day-to-day work experience for all team members and stable counterparts. In case that the regular EM is not available, the stable counter part will jump in and support the team wherever possible.
Consider pinging the standing EM on important things and help proactivley to follow the usual processes around Weekly Catch Up Meetings, Sprint Planning, Retrospectives or other meetings.
1-1s will be run in an asynchronous manner, where a new Google Doc will be shared with focus on status and enablement.