Developer Experience team

The Developer Experience team (part of the Enablement org) is a team focused on improving the developer experience of Sourcegraph.

Members

Taylor Sperry (Technical Product Manager)
Patrick Dubroy (acting Engineering Manager)

Strategy

See the Developer Experience team strategy to learn about our vission, mission, guiding principles, and overall direction.

Responsibilities

TODO

Contact

Discussions and questions: #dev-experience channel and developer experience GitHub discussions
Support: @dev-experience-support in Slack
GitHub: team/dev-experience label and @sourcegraph/dev-experience team.
- We also monitor and track issues with the dx label in our GitHub project.

Processes

To collaborate, we use the following:

Internal team channel in #dev-experience-internal
Planning board
Team sync
Newsletter
Daily updates via Geekbot to #dev-experience-updates
Google Drive folder

Playbooks maintained by the team:

CI playbook

Work allocation

We aim to allow teammates the flexibility to work on incoming requests, tackle proactive improvements, and invest in long-term efforts to further our team goals, so as a rule of thumb:

We aim to spend 20% to 30% (~2-3 days every 2 weeks) of our time on making proactive impact, i.e. working on things that are aligned with the team’s mission, but aren’t on our roadmap.
If over 50% (~5 days every 2 weeks) of our time is spent outside of planned work (i.e support requests), we opt to discuss the scope and priority of the work with the team first.

Meetings

This section is a work in progress.

We currently have weekly sync meetings and biweekly retrospectives.

Support

Support is handled through the @dev-experience-support handle in Slack. Support on-call responsibilities on this team include:

Urgent questions and issues
Build pipeline support

Build pipeline support

Build pipeline support pertains to our continuous integration. This responsibility can be described as that of a “build sheriff” - the goal is to have someone lead on identifying the right person to drive a fix on an issue, rather than actively fixing every issue that arises.

As a build sheriff, the on-call support teammate should monitor the pipeline through channels like #buildkite-main for flakes, and ensure issues are followed up on:

Infer the owner based on the contents of the issue, e.g. through product names and other context, and reach out for assistance:
1. If a team can be inferred, ping the @$TEAM-support handle in Slack for assistance, escalating to @$TEAM if no support handle or teammate is available.
2. If no team is easily inferred, ping the most recent author via git blame where relevant for assistance.
Guide the teammate towards a resolution for the issue by following our broken builds process (also see Continuous integration: Flakes).

Growth plan

TODO

Tech stack

TODO