Engineering

• Onboarding
• RFCs (requests for comment)
  • All RFC documents (Google Drive)
  • How we use RFCs
• Tracking issues
• Practices & Philosophy
  • Customer Issues
  • Incidents
  • Styling UI
  • Web-specific testing guide
  • Product documentation
  • Continuous releasability
  • Releases
  • Release issue template
  • External contributions
• Tooling
  • Configuring Zoom to send recordings to Slack automatically
• Infrastructure
  • Cloud environments
  • Deployments
  • On-call
  • Observability

Org chart

• How engineering is organized.
• Roles and responsibilities

Guiding principles

We build things in this order:

1. Make it work: Build the minimal useful thing that we can use to start collecting feedback and validating we are on the right track. Take shortcuts where possible (cut scope, not quality) because this work might get thrown away if we discover we are going in the wrong direction.
2. Make it smooth: Once we have signal that we are building the right thing, the next goal is to make the experience smooth so we feel good about putting this in front of users. Aim for smooth when in the make it work phase (to avoid duplicate efforts), but if it’s possible to separate the two in order to move things forward, we should!
3. Make it fast: Now that the experience works smoothly, make sure it is fast for users. There is no benefit to speeding up a fundamentally broken experience.
4. Make it scale: Make it work at large scale. It is better to have high demand and need to surge on scalability than to make an infinitely scalable unused feature.

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.

Communication

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

Open positions

Open positions

Innovation time

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:

1. 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.
2. 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.

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.