Batch Changes team

Batchers Logo: badger in a silly hat

Strategy

Contact

Process

  • We prioritize our work in our planning board. It is the responsibility of the PM and EM to keep this updated and correct.

  • Each day, Slack reminds us to do our text check-in, which consists of a short message (it shouldn’t take longer than a minute to write) in the reminder’s thread. This should be a recap of what we have finished that day.

  • One Big Thing: Each sprint, each engineer gets one big thing to work on — one significant chunk of work scoped to be doable in a single sprint (leaving some slack in the sprint for customer support and other unexpected issues). When it is completed, engineers will pull P0 items from our planning board into the current sprint to work on (or P1 if there are no P0s).

  • Invariants and assumptions:

    • Issues have the current milestone set if-and-only-if they are P0.
    • An issue assigned to an engineer means that engineer is committing to finishing in the current sprint. Issues should be unassigned by default.

Sprint planning

Our two-week sprints start every other Wednesday. On the Tuesday before, we have our sprint planning meeting to determine our common goals for the iteration. The process for this is described in our agenda doc. After sprint planning, the team has a retro to discuss how the previous sprint went, and what changes we might want to our working agreements.

Working Agreements

  • To avoid siloing of knowledge and to keep teammates happy, we make sure that everyone gets a chance to work in different areas of the codebase. In particular, we don’t want tasks in area X to always default to person P. We want to strike a healthy balance between spreading knowledge around and building individual expertise in one area.
  • We do not schedule team meetings on Fridays. (Folks are free to pair on Fridays if they want.)
  • We do not scramble to get last-minute changes in before branch-cut. (If it’s a blocking issue, there’s a process for that.)
  • If there is no agenda in our sync doc for our team syncs by 5 minutes before the meeting starts, then the meeting will be cancelled.
  • If a process isn’t serving us, we are quick to either change it or get rid of it.
  • We aim to improve the developer experience of working on the Batch Changes and the larger Sourcegraph codebase as we work on it. We do that by allowing ourselves to set aside time to implement improvements if we see a chance to do so. For example: it’s okay to spend half a day improving our test tooling if we know that it will make things easier for us and others in the future.
  • By default, we record team meetings with 3+ participants (with exceptions for social meetings and retros).

Team Communication

Our team has two Slack channels, one for everyone (#batch-changes) and one just for us (#batch-changes-internal). Our default is to use the public channel.

The private channel is for communications that would be of no interest to someone not on the team. Things like (re-)scheduling of team meetings, vacation scheduling, reminders about tasks that need completing, etc. Keeping these out of the public channel raises the signal-to-noise ratio for folks interested in Batch Changes, but not interested in who will be 10 minutes late to our sync meeting today due to the fact that their cat knocked over a jar of pickles and now there’s glass everywhere and everything smells like vinegar and now you wish you hadn’t read this sentence to the end.

Stewardship of src-cli

The Batch Changes team is the current owner of src-cli, due to the fact that most of the src-cli work in recent months has been related to Batch Changes. We do not expect to be the permanent owners of src-cli; when another team becomes the main contributor, we will transfer ownership to them.

Members

Growth plan

We have no further plans to grow the team at this time.

Onboarding

Attribution

Our team logo was designed using resources from Flaticon.