Skip to content

Latest commit

 

History

History
121 lines (80 loc) · 7.3 KB

index.md

File metadata and controls

121 lines (80 loc) · 7.3 KB

Frontend platform team

The Frontend platform team (part of the Web org) defines and maintains the standards and tooling for web development at Sourcegraph.

Members

Mission

To empower all users and Sourcegraph frontend developers to achieve maximum efficiency and effectiveness, by enabling and building a first-class web experience.

Vision

Using and developing Sourcegraph is effortless.

  • We have a frictionless developer experience that empowers our frontend engineers to achieve the maximum value from the time spent on development.
  • We have an intuitive, performant, and consistent user experience that makes Sourcegraph an indispensable part of every developer workflow.

Responsibilities

  1. Frontend platform:

    • Creating and maintaining the Wildcard Component Library.
    • Owning the Sourcegraph web tech stack, tools, and patterns.
    • 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 and deploy frontend code.
    • Ensuring an efficient and reliable frontend CI pipeline.
    • Track, measure, and improve cross-cutting frontend metrics like bundle size, Web vitals, etc.

  2. The core user experience of the Sourcegraph product:

    • Accessibility, navigation, and information hierarchy
    • Performance and efficiency of the core UI
    • All code browsing and code host-like views
    • Code syntax highlighting
    • Sourcegraph application homepage
    • Support and enable other teams in all of the above.

Contact

Goals

Goals

Growth plan

We are not planning on growing the Frontend Platform team further in 2021.

Tech stack

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

Processes

Planning and prioritization

We plan and track our day-to-day work on our Kanban board. Our current process (last updated 2021-03-17) is as follows:

  • Incoming tickets (e.g. from other teams) arrive in the Inbox column.
  • Work is scheduled by adding a card to either the Planned (product) or the Planned (eng) column.
    • Planned (product) is for work that directly contributes to product goals, and is refreshed and prioritized by the PM/EM.
    • Planned (eng) is refreshed and prioritized by the engineers. This is the place for refactorings, developer experience improvements, etc.
  • Work should not be moved into either column until it is ready for development.
    • Anything that needs design input gets the needs-design label and goes in the Needs input column.
  • When starting work, engineers pull cards from one of the Planned columns and move it to the In Progress column. The other columns are self-explanatory 🙂
  • We do not yet have work-in-progress (WIP) limits for the columns, but will consider that soon.

Tracking Issues

The team makes use of tracking issues for tracking progress on the implementation of new features. The teammates should ensure that a tracking issue is created when starting work on features that are expected to take longer than a few days (or require multiple PRs) to deliver.

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

Retrospectives

Every two weeks, we hold a review/retrospective meeting to reflect on the past two weeks. We use this meeting to:

  • Review the previous retro’s action items to ensure they get completed
  • Give Shoutouts! to teammates to show appreciation for something they did that we appreciated
  • Discuss things that went well in the past two weeks and that we should do more of / invest more into it
  • Discuss the things that could have gone better and what we can learn from it to improve
  • Talk about processes that we should revisit/refine/propose to improve our efficiency.

We capture and assign actions to individual teammates. Teammates should consider actions coming out of the retrospective as a very high priority.

Teammates contribute to the retrospective asynchronously during the iteration by adding their thoughts to our retrospective document. Teammates are highly encouraged to comment on points raised before the sync meeting in the document.

We rotate who leads the retrospective to allow all teammates an opportunity to lead the session. Teammates can find the rotation schedule at the top of the retrospective document.

Code reviews

The team follows the default code review guidelines with the following addition:

  1. If the author would like any of the requested reviewers to merge the PR after approval they add the label merge-on-any-approve
  2. If the author would like their PR to be merged once all of the requested reviewers have approved it they add the label merge-on-all-approve
  3. When there are only minor issues, reviewers are encouraged to give "approval with comments" and trust their teammates to address the comments without requiring a follow-up review.

Weekly Sync

The team holds weekly syncs.

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

Before team syncs, teammates and stakeholders should write down under "Agenda" in the meeting notes document anything that they'd like to bring up for discussion with the whole team.