# Postmortems

Have you ever found yourself?:

* in the midst of an extended series of broken builds
* harriedly trying to address multiple issues \(in production and/or qa\) simultaneously
* heroically finding multiple ways to improve a process or system

Go ahead and start a Postmortem using our [dedicated template](https://docs.google.com/document/d/1p1vvcbhNqSxjudIRkyulVPnrphnrDzlyzRaJ5Qz4RWk/).

Questions:

* _What's a Postmortem?_  At The Orchard, a Postmortem is a document describing and organizing a series of technical issues that typically created many issues across multiple teams. The goal of the document is to summarize, analyze, and finally to provide learned lessons and action items. Ultimately, the Postmortem is meant to improve tech life at The Orchard by ensuring that certain issues are prevented from occurring again via changes in process, applications, or systems.
* _Why should we do a Postmortem?_  We've found that postmortems on extensive issues have identified new processes/improvements to put into place.
* _What's a Postmortem vs a Build Postmortem?_  A Postmortem is general. A Build Postmortem usually has to do with identifying the cause of a series of continuously broken Jenkins builds. Either way, both are an opportunity to catalog and share lessons learned, as well as to identify critical action items.
* _I started/did a Postmortem. What now?_  Make sure to set the Share settings to `Anyone at the Orchard can EDIT`. Please then share/broadcast it out on Slack to `#engineering` and any other channels where you had discussions related to the Postmortem. Also, be sure you share with your Technology Director. Remember! You don't have to wait for the entire document to be filled in to share it out. It is better for the organization \(and more engaging\) if anyone/everyone can pitch in on this as things are arising.
* _When should I even start the Postmortem?_  It can be as soon as you see fit, or as your Director requests; it can be helpful to start documenting the Details section to describe what the states of the build runs have been. If you have been ruling out certain issues/PRs, you can document that in the Analysis section. This will also help as others cycle onto the issue. Consider it as a tool for organizing information, instead of a chore.
* _Should I do a Build Postmortem now?_  If the build has been continuously broken for more than a day, you should definitely do a build postmortem. Also, send it out over the `#the-build-is-broken` Slack channel.
* _When should I start doing the Build Postmortem?_  The build has been continuously broken for over a day now.