- RFCs (requests for comment)
- Tracking issues
- Code reviews
- Programming guides
- Styling UI
- Continuous integration
- Product documentation
- Continuous releasability
- Commit message guidelines
- Ignoring editor config files in Git
- Configuring Zoom to send recordings to Slack automatically
- Customer Issues
- Cloud environments
- Adding and debugging ping data
- Adding buildkite secrets
- External contributions
Ownership of technical decisions
The default owner of any technical decision is the person or team that owns the work implied by the decision.
If ownership is unclear, ask “Do we have a designated owner for X?” in an appropriate Slack channel and @mention appropriate managers.
If there is a dispute about ownership, then perform a clean escalation to determine an owner.
Our engineering organization is divided into mission based teams that contain the necessary cross-functional skillsets to achieve the desired mission. The leader of each team is responsible for ensuring appropriate cross-team collaboration happens when shared infrastructure needs to change.
Start a discussion with your manager if you are interested to switch teams. Your manager will chat with you to understand what you want and then propose next steps. Team transfers need to be approved by the VP of Engineering.
We love it when engineers have ideas for things they want to do, even if they don’t align with our existing iteration plans or goals. We want to create time and space for engineers to work on these ideas without negatively impacting our team goals and planned work.
If you have an idea for something you want to work on, then you have a few options:
- Just do it if you can timebox the effort (e.g., 1-2 days) such that it won’t impact your ability to deliver on existing plans.
- If working on your idea would require a non-trivial amount of time or would impact your ability to deliver on existing plans, then have a discussion with your manager to come up with a feasible plan (e.g., explicitly schedule time to work on your idea during the next iteration).
In any case, you should report the results of your work in progress updates just like any other work.
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:
Where Sourcegraph gets extended functionality:
How Sourcegraph operates as a business
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.