Development
- Onboarding
- Principles and practices
- Roles and responsibilities
- 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
- Escalation engineer rotation
- Tooling
- Infrastructure
- Hiring
- Career development
- Use cases
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:
IC5 mandate
- IC5s are expected to raise global tech problems and recommend solutions to the Head of Engineering.
- This only applies to problems/solutions that require significant cross-team coordination and staffing. For anything smaller that doesn’t need help from the Head of Engineering, just go do it; no process required.
- Each recommendation should have been reviewed by each IC5.
- Consensus is not necessary.
- If an IC5 is out on leave or otherwise can’t review it, don’t block on them unless you think it is necessary.
- When given a problem and recommended solution, the Head of Engineering should generally approve (and get a staffing plan in place) or reject within 48 hours.
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.