Change Details

I'd like to propose a task related to #wikimedia-log-errors with the purpose of tracking bugs, technical debt, feature work that was prompted by an outage or other incident and as such would help prevent, or reduce impact of, future incidents. We previously sometimes created new components for incidents (e.g. #Incident-20150205-SiteOutage). See also {T134624}. I believe it would be useful to track these tasks under a combined project instead. This would make it easier to discover tasks of importance and be reminded of outstanding technical debt that has retroactively demonstrated its need in the form of an outage. I personally think we don't need the individual incident components, but that's a separate question. If we decide to keep them, we'd be tagging with both. And, more commonly, for incidents that didn't get a component, they'd at least be tracked here. The workboard for this would be a more manageable version of the wiki pages we created in 2014 that transclude the "actionable" sections of each incident per quarter. https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201403 https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201407

Proposal ======== # A new project called `#Wikimedia-Incident` # That will be the parent project of milestones for each incident (eg `#Wikimedia-Incident-20140228-Cirrus`) where follow-up tasks are added/created. # The incident milestone projects will be archived when the follow-up tasks are completed (or removed/delayed for longer than 3 months upon further reflection/discussion) ## //For the avoidance of doubt//: if, after discussion with stakeholders, it is deemed that the only follow-up task(s) that remain is/are not needed in the short term (3 months) but is/are still valid then we should archive the incident milestone AND keep the task in it as a historical marker/context for future work # It is up to the people working on the specific incident to create workboard columns in that milestone ## They may choose everything from not having columns to using columns extensively. **Benefits** * This allows anyone to get a quick view (by viewing the `#Wikimedia-Incident` project workboard) of "tasks of importance and be reminded of outstanding technical debt that has retroactively demonstrated its need in the form of an outage" (as Krinkle said in the original description). * And each incident's responders can manage their work in the best way for them. **Disadvantages** * In the event that a large number of incidents have follow-up that takes a long time the main workboard will be very large. ** NB: Greg is considering new options for something to replace the quarterly review of incident reports and follow-up, see T141287 for that. Original Description: ===================== I'd like to propose a task related to #wikimedia-log-errors with the purpose of tracking bugs, technical debt, feature work that was prompted by an outage or other incident and as such would help prevent, or reduce impact of, future incidents. We previously sometimes created new components for incidents (e.g. #Incident-20150205-SiteOutage). See also {T134624}. I believe it would be useful to track these tasks under a combined project instead. This would make it easier to discover tasks of importance and be reminded of outstanding technical debt that has retroactively demonstrated its need in the form of an outage. I personally think we don't need the individual incident components, but that's a separate question. If we decide to keep them, we'd be tagging with both. And, more commonly, for incidents that didn't get a component, they'd at least be tracked here. The workboard for this would be a more manageable version of the wiki pages we created in 2014 that transclude the "actionable" sections of each incident per quarter. https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201403 https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201407

Proposal ======== # A new project called `#Wikimedia-Incident` # That will be the parent project of milestones for each incident (eg `#Wikimedia-Incident-20140228-Cirrus`) where follow-up tasks are added/created. # The incident milestone projects will be archived when the follow-up tasks are completed (or removed/delayed for longer than 3 months upon further reflection/discussion) ## //For the avoidance of doubt//: if, after discussion with stakeholders, it is deemed that the only follow-up task(s) that remain is/are not needed in the short term (3 months) but is/are still valid then we should archive the incident milestone AND keep the task in it as a historical marker/context for future work # It is up to the people working on the specific incident to create workboard columns in that milestone ## They may choose everything from not having columns to using columns extensively. **Benefits** * This allows anyone to get a quick view (by viewing the `#Wikimedia-Incident` project workboard) of "tasks of importance and be reminded of outstanding technical debt that has retroactively demonstrated its need in the form of an outage" (as Krinkle said in the original description). * And each incident's responders can manage their work in the best way for them. **Disadvantages** * In the event that a large number of incidents have follow-up that takes a long time the main workboard will be very large. ** NB: Greg is considering new options for something to replace the quarterly review of incident reports and follow-up, see T141287 for that. Original Description: ===================== I'd like to propose a task related to #wikimedia-log-errors with the purpose of tracking bugs, technical debt, feature work that was prompted by an outage or other incident and as such would help prevent, or reduce impact of, future incidents. We previously sometimes created new components for incidents (e.g. #Incident-20150205-SiteOutage). See also {T134624}. I believe it would be useful to track these tasks under a combined project instead. This would make it easier to discover tasks of importance and be reminded of outstanding technical debt that has retroactively demonstrated its need in the form of an outage. I personally think we don't need the individual incident components, but that's a separate question. If we decide to keep them, we'd be tagging with both. And, more commonly, for incidents that didn't get a component, they'd at least be tracked here. The workboard for this would be a more manageable version of the wiki pages we created in 2014 that transclude the "actionable" sections of each incident per quarter. https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201403 https://wikitech.wikimedia.org/wiki/Incident_documentation/QR201407