Incident Report : Publishing the First Executive Summary on SE1

post
developer development
incident report
Let’s learn from our struggles when shipping a summary!
Authors

Mordred Boulais

Gregory M. Kapfhammer

Published

September 11, 2023

The overarching struggle with getting out our first executive summary of Software Engineering At Google mostly centered on the team’s lack of proper communication and mutual understanding - of GitHub and of the task at hand. This was amplified by a lack of secure and consistent access to a wireless network, and of a universal understanding of the terms used to describe the task.

By this I refer to the confusion that followed the initial announcement of our need to work on this blog post. We simply decided to discuss among subgroups, but not what to do with that discussion nor how to make it into a proper product. In doing so, we failed to make clear the expectations and individual responsibilities involved. Then, even when team members attempted to coordinate a final product, the team’s lack of understanding of GitHub Flow interfered, as did the constant disconnecting and reconnecting of the wireless network for those involved.

In order to tackle these issues, the team laid out a new methodology for the completion of tasks, involving the assignment of smaller committees to each task. This is intended to facilitate closer and more accurate communication among teammates and to ensure clarity of assigned work. Part of obtaining this clarity is to assign each committee a “Github Expert”, someone confident enough in their understanding of GitHub Flow and functions to help guide other committee members. Through this, we aim to also allow an opportunity for those less experienced to get a closer look, as the teams are small. Specifically, for professional précis synthesis and publishing, we chose to have teams of three who can split the work and discuss with each other to ensure our work’s quality.

Here are the schedules for the team as a whole as well as for our committees:

Additional details and weekly schedules will go out in the team Discord. Teams can also find the best practices and appropriate approval process pinned there as well.

The elements of this left to properly establish is when in our schedule the committees for each week will be determined, and how to handle a situation in which any committee both fails to send notification to the team Discord by 12:00 noon on Sunday that they cannot complete the work and fails to complete their work. The possibilities below are not guaranteed to be the only options chosen from; discussion among our team members may yield more effective ideas.

Both will be decided by 10:00 AM Monday, September 18, 2023.

Some possibilities for scheduling are: every Monday, after our demo on Tuesdays, and via the project’s Discord at a group determined time.

Some possibilities for handling a committee that does not complete their work: Requiring the offending committee members to be assigned separately from each other, and requiring that each cannot work individually or on a committee for the next two weeks without a partner that was not on the offending committee.