Frontend platform team
The Frontend platform team (part of the Developer Insights org) defines and maintains the standards and tooling for web development at Sourcegraph.
- Alicja Suska (Product Designer)
- Patrick Dubroy (Engineering Manager)
To empower all users and Sourcegraph frontend developers to achieve maximum efficiency and effectiveness, by enabling and building a first-class web experience.
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.
- 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.
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.
- #frontend-platform channel or @frontendplatform in Slack.
- team/frontend-platform label and @sourcegraph/frontend-platform team on GitHub.
We are not planning on growing the Frontend Platform team further in 2021.
We use a modern, flexible tech stack. Here are some of the technologies we use to deliver on our goals:
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-designlabel and goes in the Needs input column.
- Anything that needs design input gets the
- 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.
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.
Getting cross-team feedback on RFC
- Create an issue for the RFC tracking on our Kanban board.
- Lock conversation: RFC should be discussed in the Google doc.
- Add rfc/tracking and team/frontend-platform labels to the RFC issue.
- Once RFC is ready for review, move it to the In review column and assign sourcegraph/frontend-devs or individual developers to the issue.
- Github integration will notify @web in #frontend-platform-rfc-feed that the RFC is ready for review.
- Once approved, link the RFC issue to the tracking issue if required.
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
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.
The team follows the default code review guidelines with the following addition:
- If the author would like any of the requested reviewers to merge the PR after approval they add the label
- If the author would like their PR to be merged once all of the requested reviewers have approved it they add the label
- 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.
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.