The search product team owns all parts of Sourcegraph that help users Compose search queries and navigate search results:
- Search field
- Search results UI
- Search contexts
- Query language, including structural search
- The search homepage, homepage panels
- Repogroup pages
It also owns a subset of features built on top of Sourcegraph search:
- Code monitoring
- Saved searches
To learn more about our goals, see the Search Product strategy page.
The search product team has a customer support rotation: each week, one team member will be responsible for fielding questions and requests from Customer Engineering and Customer Support.
The engineer on support rotation can be contacted using the Slack alias
The support rotation can be viewed on Opsgenie: search product schedule.
Should an engineer be unable to fulfill support responsibilities for any reason (for example, due to upcoming time off), they should swap with a teammate.
We work in two-week iterations.
Iterations start every other Monday.
We use ZenHub sprints to plan iterations. If some items in the ZenHub sprint project are not closed by the end of the iteration, teammates should mention in their last weekly update of the iteration what this impact is on planned outcomes.
On the last Thursday of an iteration: - The EM for the team creates a section for planning discussion in the team sync meeting notes doc. The EM and the team add any questions on missing context. - The team adds any relevant issues to the “next” column of the planning board.
We have asynchronous discussion in the meeting notes document. On the first Monday of an iteration, during the team sync, we validate the current plan & the contents of the GitHub project together, thus officially starting the iteration.
Every week on Friday, Geekbot will prompt teammates to share:
- Progress towards iteration goals.
- Roadblocks they’ve encountered.
- Questions they have for the team.
- Anything else they’d like to make the team aware of.
Updates are posted in #search-product-internal.
Projects that will span multiple iterations should have an associated project board tracking all known issues (example: search contexts). The subset of issues planned for a given iteration can then be added to the iteration’s project, as GitHub issues can have multiple associated projects.
We should plan with built-in slack time: the time engineers plan to allocate to roadmap goals should not be 100% of your available engineering time. As an engineer, “things I’d like to get to, but are non-priority work” are tackled as part of this slack time.
On the other hand, the planning document + initial set of issues in the project board represents “work that we plan to complete to keep us on track for our goals”.
Adding non-priority items to the iteration project board when completed is be a good way of surfacing what was accomplished. Depending on the nature of the task, mentioning it in weekly updates may be more appropriate – user’s discretion.
We keep our iteration process fluid. We discuss any aspects that could be improved in our retrospective, and aggressively bias towards testing out new changes immediately.
At the end of every iteration, we conduct a retrospective. Our retrospective notes can be found here.