Engineering

• Onboarding
• Principles and practices
• RFCs (requests for comment)
  • All RFC documents (Google Drive)
  • How we use RFCs
• Tracking issues
• Practices & Philosophy
  • Customer Issues
  • Incidents
  • Product documentation
  • Continuous releasability
  • Releases
  • Release issue template
  • External contributions
  • Guides on development, local setup, testing, best practices, etc. can be found in our “Developing Sourcegraph” documentation.
• Tooling
  • Configuring Zoom to send recordings to Slack automatically
• Infrastructure
  • Cloud environments
  • Deployments
  • On-call
  • Observability
• Hiring
  • Open positions
  • Early-career engineers

Org chart

• How engineering is organized.
• Roles and responsibilities

Communication

For a list of engineering relevant Slack channels to join see the team chat page in the handbook.

Repositories

Sourcegraph has a lot of repositories!

Where Sourcegraph is built (things you’ll find out-of-the-box)

• Main repositories
• Web development repositories
• Backend repositories
• Tooling repositories
• Documentation repositories

How Sourcegraph gets deployed

• Infrastructure repositories
• Customer infrastructure repositories

Where Sourcegraph gets extended functionality

• Code intelligence repositories
• CLI repositories
• Editor extension repositories

How Sourcegraph operates as a business

• Business repositories
• Customer repositories

Sourcegraph deployments and other developer test instances

• sourcegraph.com is our production deployment for open source code.
• k8s.sgdev.org is a dogfood deployment that replicates the scale of our largest customers.
• demo.sourcegraph.com is a managed instance used for CE demos.
• devmanaged.sourcegraph.com is a managed instance used for managed instances development.
• storybook.sgdev.org is a design system built with Storybook.
• gerrit.sgdev.org is a Gerrit test instance.
• gitlab.sgdev.org is a Gitlab test instance.
• github.sgdev.org is a Github test instance.
• bitbucket.sgdev.org is a Bitbucket test instance.

Misc.

This point lives here for now:

• We require passing checks on GitHub PRs before merging (and don’t allow direct pushes to main). Sometimes it’s nice to push without waiting for checks (such as for docs-only changes), but this is outweighed by the downside that people too often accidentally merged changes that broke the build. Certain kinds of low risk changes (e.g., documentation only changes) may only run a subset of the build pipeline so that checks pass quickly in those cases.