Developer Infrastruture Team

Sourcegraph Developer Infrastructure temporary team logo

The Developer Infrastructure team, or DevInfra for short, is a team focused on improving the developer experience of Sourcegraph.

Need DevInfra help or support? Jump to the Contact section.

Leadership

Members

Strategy

Find out more about the Developer Infrastructure team’s mission, vision, and strategic plans in our Strategy page.

Responsibilities

Also see org-wide areas of ownership and our team processes.

Support levels

The team operate across a broad range of responsibilities, so it’s best to reason in terms of how much a given issue affects others. The below list gives an overview of the commonly encountered scenarios, but isn’t meant to be exhaustive.

  • P0: Issues that are affecting at least a third of the engineering team and that have no immediate workaround.
  • P0: Issues the CI where a given build is affecting other builds, i.e breaking isolation.
  • P0: Issues caused by Bazel, affecting releases (broken release or preventing it to be created).
  • P1: Issues with CI or local environment that are threating another team objectives.
  • P2: Issues causing intermittent failures in CI.
  • P3: Default priorities for support requests when created.
  • P4: Issues that can wait, usually QoL improvements.

Contact

For questions and discussions about anything related to developer experience, post a message in the #discuss-dev-infra channel.

For urgent requests or if you’re blocked on something important, add the @dev-infra-support tag in your message.

  • The @dev-experience-support tag will ping an on-call member of the DevInfra team.
  • Requests tagged with @dev-experience-support will get priority support.
  • Please use the @dev-experience-support tag only for issues that require immediate attention.

You can also interact with us on GitHub:

Principles

We inherit Sourcegraph’s engineering principles and practices. In addition, the following principles guide the work we do in Developer Infrastructure. Sometimes adhering to one causes us to compromise another, but they guide our decisions on what matters.

  • We don’t own the developer experience at Sourcegraph – we simply focus on it. Sourcegraph engineers own the developer experience as a collective.
  • We ship open products. Our products are open to contributions to anyone in the company, documented, and provide migration paths if necessary. Our decisions are clearly and publicly communicated for everyone to understand our reasoning. We want to make it simple for everyone to benefit from and work on Sourcegraph’s developer experience.
  • We bandage first, then plan for surgery. Fix local problems first, then generalize if and only if it makes sense.
    • What we cannot take upon right now, we make its status clear and provide stewardship.
      • We should never refuse to fix a “now” problem in favour of a long-term solution, only to cancel the fix because the priorities changed in between. More than not addressing the issue at hand, it prevents our users from fixing the problem for themselves in the meantime.
    • We deliver small and iterative experiments and collect feedback. We communicate regularly on their status to enable others to provide inputs. We should reap the benefits of what we work on as we go, not at the end.
  • We listen and observe. Our users often know best what’s immediately good for them because they are the ones experiencing it every day. We are not a dependency. We actively seek to avoid blocking product teams. We focus on improving and expediting progress, not being critical to it.

Processes

Read more about how this team works.

Useful resources

Sourcegraph instances operated by us

We also maintain various instances of Sourcegraph which include:

Tech stack

  • We primarily build tools and libraries in Go, with a dash of bash scripting in between.
  • We also operate CI infrastructure with Kubernetes and Terraform.
  • We’re the reference point for any Bazel related effort.