Engineering

Build

• Security: Make it secure, because our customers trust us with very sensitive code and other data, and we need to continually earn and retain that trust.
• Reliability: Make it stable and robust, because devs don’t trust flaky or incorrect results.
• Speed: Make it fast, because devs won’t use something 10+ times daily if it’s slow.
• Scalability: Make it work at large scale, such as big monorepos or 100,000s of repositories.
• Documentation: Add and update documentation for the new feature.
• Accessibility: Make it accessible to a broad set of users (including keyboard accessibility).
• Observability: Help admins debug, manage, and scale the functionality.
• Telemetry: Gather the (minimum) data needed for us to understand how the feature is being used and improve it.
• Backward-compatibility: Make it smooth to upgrade from past versions and adapt usage to the newest version.
• Forward-compatibility: Anticipate the feature’s future evolution (where possible, and without over-building today).
• Admin experience: Give an admin the visibility and controls they need to roll out and manage the feature.

Feedback

• Iteration feedback: Iterate with our existing customers and gather user feedback as early as possible.
• Usage/value analytics: Show how the feature is being used to users and admins, communicate the value to the customer’s business, and identify opportunities for more value.

Launch

• Marketing: Update all marketing content to reflect the new feature (such as our about site, readmes, extension descriptions, slides, etc.).
• Announcement: Draft the eventual announcement of the feature early (in blog post form, along with a changelog entry and major docs changes), and update it as you iterate.
• Pricing/packaging: Decide which plans include this feature and whether its code will be open-source or not.

What’s intentionally NOT in this list (but would be plausible items for a similar list at other companies):

• Localization: We don’t yet see the need to localize Sourcegraph for non-English languages or different regions.
• Offline/mobile: We target online desktop users right now. (Note: This is separate from supporting airgapped instances of Sourcegraph within corporate networks, which is important.)
• Abuse prevention: Because Sourcegraph is an enterprise product used in isolated instances within companies, we can rely on admins for the very limited moderation necessary (such as if a search context with an offensive name is created).
• Public usage: We target organizations’ Sourcegraph instances (Cloud managed instances and customer self-managed or jointly managed instances), not Sourcegraph.com. Presume for any feature that it’s not worth doing extra work to make it work on Sourcegraph.com (and disable it on Sourcegraph.com with a feature flag if needed).
• Secrecy/surprise: We almost never care about keeping a feature secret prior to announcement. It’s still important to avoid confusing users and customers about pre-release features and future plans.