The Create:Editor Extensions Group is responsible for all aspects of the product categories that fall under the Editor Extensions group of the Create stage of the DevOps lifecycle.
The following people are permanent members of the Create:Editor Extensions Group:
| Person | Role |
|---|---|
| Dylan Bernardi | Associate Backend Engineer, Create:Editor Extensions |
| Erran Carey | Staff Incubation Engineer, Breach and Attack Simulation |
| François Rosé | Engineering Manager, Create:Editor Extensions |
| John Slaughter | Staff Backend Engineer, Create:Editor Extensions |
| Tomas Vik | Staff Fullstack Engineer, Create:Editor Extensions |
| Tristan Read | Senior Frontend Engineer, Create:Editor Extensions |
The following people are temporary members (borrow process) of the Create:Editor Extensions Group, each one working on a specific area:
The following people are stable counterparts of the Create:Editor Extensions Group:
The Editor Extensions group is responsible for the following product categories:
We have a sync meeting as a team once per week. Recordings are uploaded to the Editor Extensions Category playlist on GitLab Unfiltered. When the discussion is finished, we stop the recording and stay on the call for the remaining time to have a group coffee chat.
Additionally to our main team's slack channels, each extension/project we work on has its own slack channel:
Our group processes are documented in this section. If a process is in use but not described here, please follow the guidance in Evolving the process to document it.
Our group is relatively new, and currently light on processes. There are several differences between how we operate and the shared processes documented in the product development flow and engineering workflow.
We take an iterative approach to our processes. Instead of defining it all at once, we add process when we see a gap or identify a problem. For efficiency, we also don't shy away from removing a process that has outlived its usefulness.
To evolve the process, please start with an MR to this page which contains your specific proposal, and ask for feedback.
If an issue is better suited for the discussion, it should be created in the meta project.
We exclusively use issue/epic descriptions as the single source of truth for our planned work.
Epics and issues are created in the project that matches their scope in the narrowest possible way. We use the following projects:
We use Milestone Planning Issues to define our goals for the current/upcoming milestone. The PM and EM are responsible for aligning on the goals. The planning issues are created automatically every month.
We use the Editor Extensions Priority Board to track the relative priority of issues. Issues at the top of a column have the highest priority.
Separately, the technical writer for this group also triages open issues for potential documentation and UI text changes,
and follows the Technical Writing triage process. After review, each issue receives the ~tw::triaged label.
Our team owns several projects, written in different languages (Typescript, Kotlin, C#, Lua) and targeting different platforms.
We are currently intentionally working in silos, by assigning engineers to the project/technology that they can contribute to most efficiently. This increases speed of development as we aim to reach GA for Code Suggestions, at the cost of knowledge sharing and team resiliency.
This intentional siloing is a temporary measure. While we do need to cultivate deep expertise in each project, the mid-term vision for the team is to provide opportunities for everyone to contribute across each project. This will increase collaboration, team resiliency, and provide opportunities for growth.
This section contains links to make it easier to find the same information for each extension. This is a first iteration, this content should probably live somewhere else eventually.
Each extension defines an array of supported languages.
Check out our jobs page for current openings.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (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.
(Sisense↗) Flaky test are problematic for many reasons.
(Sisense↗) Slow tests are impacting the GitLab pipeline duration.
