Engineering

• Onboarding
• RFCs (requests for comment)
  • All RFC documents (Google Drive)
  • How we use RFCs
• Code reviews
• Go style guide
• Testing
• Product documentation
• Continuous releasability
• Commit message guidelines
• Incidents
• Releases
  • Release issue template
• Deployments
• On-call
• Prometheus
• Adding ping data
• Adding buildkite secrets
• Campaigns

Roles and responsibilities

• VP Engineering
• Software Engineer

Teams

Each Sourcegraph engineer works on a team that has long-term ownership of a part of our product and codebase. See the project roadmap for what each team is working on.

• Code intelligence team
• Core services team
• Distribution team
• Web team

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

Misc.

This point lives here for now:

• We require passing checks on GitHub PRs before merging (and don’t allow direct pushes to master). 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.