The Global Search team is focused on bringing world class search functionality to GitLab.com and self-managed instances.
The team will be responsible for improving and expanding upon our current global search implementations using Elasticsearch, PostgreSQL, and Gitaly. Areas of responsibility will include global search functionality, UI, ingestion mechanisms, optimal indexing, administrative tools and installation mechanisms for self-managed installations.
The following people are permanent members of the Global Search Team:
|Changzheng Liu||Backend Engineering Manager, Global Search and Memory|
|Dmitry Gruzd||Senior Backend Engineer, Global Search|
|Terri Chu||Senior Backend Engineer, Global Search|
The following members of other functional teams are our stable counterparts:
|John McGuire||Senior Product Manager, Global Search|
|Nick Brandt||Product Designer, Enablement:Global Search|
|Andrew Kelly||Senior Security Engineer, Application Security, Growth (Activation, Conversion, Expansion, Adoption), Fulfillment (Purchase, License, Utilization), Enablement (Distribution, Geo, Memory, Global Search, Database)|
|Erick Banks||Senior Software Engineer in Test Enablement:Search|
Whenever possible, we prefer to communicate asynchronously using issues, merge requests, and Slack. However, face-to-face meetings are useful to establish personal connection and to address items that would be more efficiently discussed synchronously such as blockers.
We follow the general workflow and principles defined in Product Development Flow and Engineering Workflow. To bring an issue to our attention please create an issue in the relevant project. Add the
~"group::global search" label along with any other relevant labels. If it is an urgent issue, please reach out to the Product Manager or Engineering Manager listed in the Stable Counterparts section above.
Below are a few guidelines the team follows in the day-to-day work.
We encourage all backend engineers in our team to get a review of their changes by someone else in our team. It's great for knowledge sharing.
workflow::solutionvalidation for user research, and
workflow::designfor UI design and prototyping. Once the design is finished,
workflow::ready for developmentlabel will be added as an indicator that development can start. For minor UX/UI changes, we contact our UX counterpart or the UX manager to request a review for fast iterations.
workflow::planning breakdownand adding the SET counterpart as assignee. Once SET reviews the issue, they acknowledge back with label
documentationand adding our counterpart in Technical Writing team as assignee. Our technical writer helps us update the corresponding document. The documentation change normally happens together with code change.
The team has been actively working on enabling Elasticsearch powered Advanced Search on GitLab.com. Based on our analysis, we set our first target to rolling this feature out for all the paid groups on GitLab.com. You can find more details about the timeline and progress in the links below.
|Type of Operation||
|Recall Record, Global||Above 10 seconds to timing out||Between 7 and 10 seconds||Between 4 and 7 seconds||Between 2 and 4 seconds|
|Time until inserted record is recallable||Above 15 minutes||Between 15 and 10 minutes||Between 10 and 5 minutes||Between 3 and 5 minutes|
The two types of operations we detail severity metrics for above are:
We use the Fibonacci rating system to assign weights to Search issues. Below are a few guidelines when assigning issue weight:
~frontendwork should have the weights added for a total weight representative of the work effort.
|0||No effort or trivial effort (example: Documentation typo or Feature Flag Rollout)|
|1||Low effort (No Database migrations or Advanced Search migrations)|