Frontend Platform team

Planning and prioritization

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

• Incoming tickets (e.g., from other teams) are given the team/frontend-platform label. As part of our triage process, these tickets are added to our board by the designated teammate.
• Work is scheduled by adding a card to either the Backlog (product) or the Backlog (eng) column.
  • Backlog (product) is for work that directly contributes to product goals and is refreshed and prioritized by the PM/EM.
  • Backlog (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. Tickets that require further input before an engineer can start working on them are put in the Needs input column.
• Tickets in the Needs input column should be tagged with an appropriate label that describes what input is required:
  • needs-design: if it needs input from the design team
  • needs-discussion: if the issue should be discussed at the next Frontend Platform sync
  • needs-more-info: if it’s not clear yet what needs to be done
  • needs-prioritization: if the issue is part of an active prioritization conversation, to be decided on soon
  • awaiting-reply: if we’re waiting on an answer to a specific question on the ticket
• When starting work, engineers pull cards from one of the Backlog columns and move it to the In Progress column. The other columns are self-explanatory 🙂

Triage

We have a weekly rotation for triaging and refining issues. During their week on rotation, the on-duty teammate is responsible for triaging and clarifying any new issues that have been reported. We aim to do the following on a daily basis:

1. Click the ”+ Add cards” button and search for is:issue is:open label:team/frontend-platform -label:"good first issue" -label:gitstart to find all open issues for the Frontend Platform team that are not yet on our board. For each issue that is found, drag the card into the Inbox column on our board.
2. For each issue in the Inbox column, consider the following:
   • Is it clear what needs to be done? If not, ask for clarification on the ticket, apply an appropriate label (e.g., needs-more-info), and move the ticket to the Needs input column.
   • Is it clearly something that should be done by the Frontend Platform team? If not, tag other teams (using the appropriate team/xyz label) and have a discussion about which is the best team to own the issue. Or you can add the needs-discussion label and discuss it with the team at an upcoming meeting (e.g. Frontend Platform sync or FPT coffee).
   • Is it ready for development? If required, add the needs-design label and move the ticket into the Needs input column.
   • If it’s ready for development and you know how to prioritize it correctly, move it to one of the Backlog columns. If you don’t know how to prioritize it, you can leave it in the Inbox column and ask your teammates for help with prioritization.

At the end of the week, aim for the Inbox column to be empty, or almost empty.

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.

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.

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

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.

Meetings

We inherit Sourcegraph’s meeting principles and asynchronous communication guidelines with some modifications that help us run effective meetings:

• Meeting agenda:
  • The meeting leader prepares the agenda at least 24 hours in advance in a shared Google document.
  • Participants write down their items at least 12 hours before the meeting. There can always be last-minute additions, but early preparation is encouraged.
  • If the discussion point is expected to take a considerable amount of time, an estimate in minutes should be added.
  • Participants ensure that each topic includes important details and relevant references.
  • Participants review agenda details before the meeting starts.
  • During the meeting, we follow the agenda and fill in notes along the way.
• Timing:
  • The meeting leader always starts discussion on time, even if some participants are late. (And try not to be late.)
  • The meeting leader ensures that the meeting ends on time (or early).
• Action items:
  • We capture and assign action items to individual teammates.
  • We review action items from the previous meeting to make sure they get completed.

Retrospectives

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

• 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.

Teammates should consider action items 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.

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.

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. During the sync, we dedicate time to discussing any tickets on our board that have the needs-discussion label.