Sourcegraph Web Team Logo

Web team

The Web team owns two areas of the product:

  1. Frontend platform: the maintenance and expansion of the Sourcegraph web application. We also define and maintain the standards and tooling for how we do web development at Sourcegraph.
  2. Extensibility: our code host and third-party integrations (including our browser extension) and our Sourcegraph extensions.

This is a large ownership area, so the team creates a focused plan each iteration, by agreeing on an appropriately small set of iteration goals. Each goal should have more than one teammate working on it.

Members

* Joel is the acting PM for this team until we are able to hire a dedicated PM for it. Once that happens, he will focus entirely on code insights.

Contact

Goals

See goals

Growth plan

Updated 2020-01-14

  • As of 2021-01-14, we are no longer accepting frontend engineer applications to focus on the Frontend Platform work stream. We will be opening applications for JavaScript engineers to apply to work on our Extensibility work stream by the end of January 2021.

When this team team gets big enough, we expect to split into two dedicated teams: Frontend platform and Extensibility.

In January 2021, Code Insights moved out of the Web Team into its own team, lead by Felix Becker (EM) and Joel Kwartler (PM).

Frontend platform: frontend web platform and code browsing

This team is responsible for:

  1. Defining how we do web development at Sourcegraph and ensuring that our product engineering teams have the tools and components they need to quickly build high quality user experiences everywhere we use web technologies (for example: web application, browser extensions).
  2. The core user experience of the Sourcegraph product

The team’s areas of responsibility include:

  • Frontend platform
    • Creating and maintaining a standard Sourcegraph UI component library.
    • Sourcegraph web tech stack, tools, patterns, documentation, education (e.g. webpack, TypeScript, React, RxJS).
    • Documentation and training material to enable product teams and new hires to quickly learn how we do web development at Sourcegraph.
    • Define and maintain how we test frontend code.
    • Ensuring an efficient and reliabile frontend CI pipeline.
  • Code browsing
    • Application navigation and information hierarchy
    • Syntax highlighting and file viewing
    • Repository landing pages and file directory pages
    • Basic code host-like features (e.g. viewing diffs, commits, history)
    • Sourcegraph application homepage
    • Accessibility support

Extensibility: Sourcegraph extensions and code host integrations

This team is responsible for:

  1. Bringing the value of Sourcegraph to other developer tools
  2. Bringing the value of other developer tools into Sourcegraph

The team’s areas of responsibility include:

  • Sourcegraph extensions
    • Providing a Sourcegraph extension API that enables developers to bring data from their favorite developer tools into their Sourcegraph workflow.
    • Building useful Sourcegraph extensions on top of the Sourcegraph extension API (for example: Codecov, Datadog, Sentry, Lightstep).
    • Documentation and tutorials that enable third party developers to create extensions that are actively used.
    • Building and maintaining the extensions registry and discovery paths to create a community around Sourcegraph extensions.
  • Integrations
    • Surface code intelligence (and other Sourcegraph data) in code hosts through user installed browser extensions.
    • Add native support for Sourcegraph in code hosts (for example: GitLab) or popular sites where developers look at code examples (e.g. https://reactjs.org, https://pkg.go.dev/) so users don’t have to install our browser extension to get code intelligence.

Tech stack

We use a modern, flexible tech stack. Here are some of the technologies we use to deliver on our goals:

Processes

Communication

We recognize that frequent, open communication is key to the success of our team, especially in an all-remote environment. We default to asynchronous communication in Slack and GitHub issues over other mediums (video calls, emails) as we are respectful of our teammates’ time.

The team communicates in the following channels in Slack:

#web-chat: All work related commmunication happens in this channel. This is also the primary channel for teammates outside of the team to reach out to us.

#web-team: Our daily standups (facilited through Geekbot) go into this channel as well as all non-work related commmunication. Random conversations, banter, jokes etc. are all welcome here.

#web-onboarding: This channel is dedicated to questions or thoughts that new teammates have while they onboard. It’s a safe space to simply think out load and the goal is to identify things that we can improve and things we should make more clear in the handbook.

Backlog

The web team keeps a backlog GitHub project board for each of our focus areas: frontend platform backlog and extensibility backlog.

We use the backlogs for tracking bugs, small features, and unplanned work. We don’t use the backlog for tracking work that is expressly planned in our roadmap.

To add an issue, tag it team/web to notify the web team PM and put it in the “to triage” column of the board. Unless you’re directly asked, only web team members should move issues out of the “to triage” column on the board. A web team member will confirm the issue is web team-related, and then move it to the appropriate column.

Product Feedback

Specific product feedback about well-defined, small features can be found directly in the backlog boards. More general product feedback that applies to larger features, or that needs more research and planning to be actionable, is kept in Productboard, separated by focus area: extensibility feedback and frontend platform feedback.

Iterations

The web team has a large ownership area, so the team creates a focused plan each iteration, by agreeing on an appropriately small set of iteration goals.

We plan our work in 2-week iterations.

Our goals for the current and past iterations can be found in our iteration goals living Google Doc.

The individual tasks and progress of the current iteration can be found as GitHub issues in our GitHub project board, with estimate labels and assignees. At the beginning of an iteration, we fill the “Planned” column with all issues we want to accomplish by the end of the iteration and make sure they have estimates and assignees. Each issue should be as small as possible. Over the course of the iteration, we strive to close issues with small, iterative pull requests that we review and merge timely (generally a day). By the end of an iteration, all issues should be in the “Done” column and the board gets emptied.

Iteration planning

To ensure the team can be productive right from the start of an iteration we start planning for our next iteration as soon as a new iteration starts.

  1. First week of the iteration
    1. The EM & PM will add tasks that should be considered for the iteration throughout the week.
      1. Tasks are added to the Iteration planning scratchpad; a spreadsheet we use to propose work items for the upcoming iteration
      2. The PM will focus on adding items that are aligned with our roadmap so that we keep working towards our goals
      3. The EM will focus on adding bugs and tech debt issues to ensure we maintain a high quality code base and product.
    2. The EM & PM work on getting all tasks to a “Ready for dev” status.
      1. A “Ready for dev” status means that all the necessary information has been captured or prepared so that the engineer taking up the issue can essentially start working on it immediately.
        1. This does not involve figuring out implementation detail, as we do not tell engineers how to execute a task, but rather tell them the problem and make the requirements clear, and then ask them to figure out the best way to implement the solution.
        2. We don’t block on design dependencies for a task, but try to identify any dependency early on and communicate this requirement to the product designer.
    3. The PM identifies and communicates design input needed from the Product Designer and works to prioritize it with them.
  2. Second week of the iteration
    1. By the Wednesday, the EM and PM should have ensured that:
      1. All planned work have refined issues in GitHub and are added to the ‘Next iteration’ column on the backlog board
      2. All issues are in a “Ready for dev” state
      3. All issues have effort estimates and have been prioritized
      4. The team’s available capacity for the next iteration is known.
        1. A teammates capacity is calculated at 80% of the iteration days - vacation days.
    2. On the Wednesday, the teammates are invited to review the planned iteration scope and to provide feedback.
    3. On the Thursday, the EM and PM will have a sync call to finalize the next iteration’s scope. In determining the iteration scope they will factor in:
      1. The priority
      2. The effort estimate
      3. The available capacity of the team
      4. Any left over issues that won’t be complete from the prior iteration, and whether those issues should still be prioritized next iteration or moved to a backlog category.
      5. Feedback from the teammates
    4. The PM will prepare the current iteration project in GitHub with the relevant issues.

Updates

We do regular updates to communicate our progress to members of the team, and to external stakeholders.

Daily Slack updates

Collaborating across timezones requires regular communication to keep each other updated on our progress, and coordinate work handoff if needed. We also use this opportunity to build camaraderie between team members by sharing some non-work related aspects of our lives with each other.

We use Geekbot to facilitate all this and these updates are purely for coordination within the team (as opposed to for external stakeholders). At the start of each working day, Geekbot will ask each teammate a set of questions and the responses will be posted in the #web-chat Slack channel.

All teammates are expected to be part of this channel, and should read the updates, to learn what your teammates have been working on, and check if they need your help.

Retrospectives

After each iteration, we hold a retrospective, to reflect on the past iteration. We use this retrospective to:

  • Understand whether we accomplished the goals we set at the beginning of the iteration. If we didn’t accomplish them, reflect on the reasons why.
  • Discuss things that didn’t go well in the iteration, and identify action items to improve on these in the next iteration.
  • Discuss things that went well in the past iteration, and that we should do more of / invest more into.

At the beginning of each iteration, the engineering manager will:

  • Schedule the retrospective meeting
  • Set up a Slack reminder three days before the retrospective meeting, asking teammates to write their discussion topics in our retrospectives document

We do regular backlog triages together, where we go through the issues in our backlog. This helps us resurface older issues, create shared awareness for existing deficiencies among everyone on our team and ensures no-longer-applicable issues are closed. To manage the load for these triages, a triage may have a specific theme, like “debt” or “performance”.

Team syncs

The web team holds weekly syncs.

The meeting notes of web team syncs can be found in this doc.

Before web team syncs, teammates and stakeholders should write down under “Discussion items” in the meeting notes document anything that they’d like to bring up for discussion with the whole team.