There are many sources of potential interrupt-driven work that can impact our engineering teams:
This is all important work, but it doesn't fit neatly into our release process. Because of that, it is often at best an unwelcome interruption. Creating a rotation dedicated to these "Reaction" tasks limits the impact of these interruptions for any given release cycle, which allows everyone to stay focused on what they need to deliver in any given month.
The schedule for rotation should be set at least 3 releases in advance by cooperation of the Backend Engineering managers. The pick-random-team-members script can be a good starting point for this selection, but the following should be taken into account:
Aside from the above, Reaction should be considered a priority for all backend teams. While swapping rotation slots or working to address the above concerns is a fair part of the process, teams are not expected to decline participating in the rotation.
Prior to serving as Reaction, the developer on rotation for a release should create an issue using the
reaction-onboarding template and complete the specified tasks.
During the release, the Reaction developer is not scheduled for any release work. Instead, they are fully tasked for interrupt-driven work as described above.
There is no expectation that potential interruptions that happen while the developer is not at work are their responsibility. Earnest effort should be made to notify production and support teams if the developer is not going to be available during their "normal" hours, but otherwise their schedule is still theirs to manage and there is no atypical expectation about their availability while on rotation.
In the event that there are no interrupt-driven tasks to complete, their priorities should be as follows (in order):
~production requestlabel directly impact the efficacy of the Production team, so they should be a priority.
Because of the unpredictable nature of Reaction work, there is no explicit measure of success for the work. Developers on the rotation should log their accomplishments in a doc/issue. This explicit documentation will make handoffs easier, and will also give the developer's manager clear insight into their work.
|11.1||Douglas Barbosa Alexandre||Geo|
After this gets merged, we need to work through the following to kick the rotation off: