Development
- Onboarding
- Principles and practices
- Engineering management
- Policies
- RFCs (requests for comment)
- All RFC documents (Google Drive)
- How we use RFCs
- Tracking issues
- Engineering ownership - who owns what
- Practices & Philosophy
- Customer Issues
- Incidents
- Product documentation
- Continuous releasability
- Releases
- External contributions
- Licenses
- Guides on development, local setup, testing, best practices, etc. can be found in our ”Developing Sourcegraph” documentation.
- IAM model for GCP
- Tooling
- Infrastructure
- Hiring
- Career development
- Use cases
Org chart
We are organized in 3 orgs:
Also see:
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)
How Sourcegraph gets deployed
Where Sourcegraph gets extended functionality
How Sourcegraph operates as a business
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.
Slack channels
Slack channels for non-team-specific engineering interests typically start with a #dev- prefix
The current channels are:
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.