Dev Experience team

The Dev Experience team, or DevX for short, is a team focused on improving the developer experience of Sourcegraph as part of the Enablement org.

Members

Strategy

Responsibilities

Contact

Processes

To collaborate, we use the following:

Meetings

Team meetings

The DevX team currently has weekly sync meetings and biweekly retrospectives within the team.

sg hack hour

There is a weekly sg hack hour that Thorsten Ball and the DevX team co-host weekly Fridays from to for anyone interested in making contributions to the Sourcegraph developer tool.

When the hack hour starts, a meeting link will be posted in #dev-experience.

To learn more about contributing to sg, check out the contribution guide!

Planning

This section describes how the DevX team currently conducts planning. Planning can include quarterly planning, project scoping, requirements gathering, RFC-writing, or any combination of the above.

For any major body of work:

  1. A work lead is assigned.
  2. A planning issue is created, and relevant planning work is done.
  3. A tracking issue is created, tracking tasks required for completing the work.

Work leads

A work lead is the person assigned to lead a body of work, including the planning of said work. If there are questions about priority order, scope change, etc. the work lead helps answer questions/provide updates. They have special responsibilities regarding planning issues and tracking issues.

Planning issues

Planning starts with a planning issue. Planning issues are GitHub issues with the team/devx and planning labels on our GitHub board to track any significant planning efforts. A planning issue documents the planning process - links to RFC(s), discussions, artefacts like scratch documents, meetings, decisions, etc. as planning progresses.

The work lead should:

  • Continuously document the planning process
  • Help/work with PM/EM to:
    • Define Key Results, including:
      • Desired outcomes of this work
      • Scoping the work to a manageable size for one team to deliver within one quarter (timeboxed)
      • How we will accomplish “Non-Functional Requirements” where applicable (or call out as N/A): testing, monitoring (how do we monitor and support the system?), documentation, etc.
    • Identify and monitor:
      • Stakeholders to notify and consult
      • Dependencies on other teams and/or other work and their progress status.

✅ Outcome: Once a roadmap or scope has been finalized, the appropriate tasks should be created, labelled with days estimates (as supported by the tracking-issue-bot) and other metadata where helpful, as well as a rough order of operation and outline of what can be parallelized. A tracking issue should then be created.

Tracking issues

A tracking issue is summarised by the Key Results defined in planning, and collects all the relevant tasks to achieving this to track in-flight work. Tracking issues are GitHub issues with the team/devx and tracking labels on our GitHub board.

The work lead should:

  • Have a clear picture of the work currently being executed on, upcoming work, and overall timelines
  • Ensure required tasks are delegated
  • Continually evaluate:
    • That we are working towards the Key Results, and if the work meets it.
    • The Key Results, scope, and order of operations
    • If any adjustments are needed - if so, work with PM/EM to make the adjustments.

✅ Outcome: The Key Results defined during planning are met, and follow-ups and takeaways are documented and tracked:

  • Are there any known/outstanding bugs? Create issues to follow up if needed.
  • Did we change the design mid-development? If so, why?

Support

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

Build pipeline support

Build pipeline support pertains to our continuous integration. 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.

The on-call support teammate should monitor the pipeline through channels like #buildkite-main for flakes and notifications from buildchecker. If there are any issues, ensure issues are followed up on:

  1. Infer the owner based on the contents of the issue *e.g. through product names, git history, and/or 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.
  2. Guide the teammate towards a resolution for the issue by following our broken builds process (also see Continuous integration: Flakes).
CI support responsibilities

The DevX team is not responsible for all the tools and tests that run in Sourcegraph’s CI infrastructure. If a tool or test is behaving in an unstable manner, the team using the tool or test (see build pipeline support for how we infer ownership) has the responsibility of leading an investigation into what might be causing said instability, with the assistance of the DevX team if helpful.

The team leading the investigation should either fix the issue directly, or if the issue requires changes in the DevX team’s ownership/responsibility areas (e.g. increasing resource limits for build agents, or making significant changes to the pipeline generator), request the desired changes through an issue tagged team/devx.

For a higher-level understanding of our responsibilities, see our guiding principles.

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.

Newsletter

The DevX team is responsible for a monthly (ish) newsletter to highlight developer experience updates (not just those lead by the team). Learn more about it and see previous issues in the newsletter archive.

To prepare a new issue of the newsletter, create a PR for the latest newsletter issue here following the conventions in the previous newsletters. Some tips:

  • You can refer to dx-announce issues and PRs for content ideas!
    • Adding a closed:>YYYY-MM-DD will filter the list down to just things that have been closed since the last newsletter issue.
  • To include images, either follow the official guide or upload images to a GitHub issue - this will provide a shareable link.

Once the newsletter is ready and reviewed, merge the PR. Then copy and paste the rendered newsletter from the handbook (you can set this up locally with yarn dev) into a draft newsletter. You will need to remove the background color from the pasted content, but the formatting should otherwise just work.

Verify the output looks good, and email it to engineering-team@sourcegraph.com.

Growth plan

TODO

Tech stack

TODO

Internal resources