I think we should probably get some SRE/Release-Engineering-Team input since they would probably be the ones using this the most about how they want to move forward.

I would probably imagine having a Incident-Report parent project then having subprojects for each issue would be the easiest method.

The per incident projects were probably an over engineered part (from me).

I like the one project idea.

What do you think the columns would look like to replicate those older
quarterly reviews? status? Something else?

My idea when doing the Phabricator cleanup was #Wikimedia-sites-incident with milestones for each incident (and convert current incident projects to milestones).

See also T929: New project: "Wikimedia Incident Response"

In T140202#2457202, @Danny_B wrote:

My idea when doing the Phabricator cleanup was #Wikimedia-sites-incident with milestones for each incident (and convert current incident projects to milestones).

And, it'd (hopefully) force us to actively manage the tasks in those milestones (resolve them or remove them in a reasonable amount of time) so as we don't have a workboard with 100 incident milestone still active.

In T140202#2471941, @greg wrote:

In T140202#2457202, @Danny_B wrote:

My idea when doing the Phabricator cleanup was #Wikimedia-sites-incident with milestones for each incident (and convert current incident projects to milestones).

And, it'd (hopefully) force us to actively manage the tasks in those milestones (resolve them or remove them in a reasonable amount of time) so as we don't have a workboard with 100 incident milestone still active.

Cf. T134624: Archive old Incident-* projects ;-)

OK, if no objections soon, I'll proceed first steps towards this aim.

@Krinkle: yay/nay to the above proposal?

In T140202#2476467, @greg wrote:

@Krinkle: yay/nay to the above proposal?

Looks good. Though personally I don't feel the need for milestones. It's fine to have them I guess, but it does force our hand with regards to the main workboard - as tasks can then only be in the dedicated column for that milestone.

Yeah, it does, I just couldn't think of a better workboard column purpose (other than status, which is kind of annoying to track, since many teams track it somewhere else already).

In T140202#2477208, @Krinkle wrote:

Looks good. Though personally I don't feel the need for milestones. It's fine to have them I guess, but it does force our hand with regards to the main workboard - as tasks can then only be in the dedicated column for that milestone.

There is no way task could be in more columns regardless if they are milestones or plain columns.

However, milestone at least - unlike the regular column - allows further breakdown, typically progress-wise.

I've updated the description with the proposal as I see it. I don't think this is too radical of a proposal. We should implement it soon. We just need someone to do the conversion of old incident projects into milestones of #Wikimedia-Incident (needs shell/permissions on the Phabricator host) after it is created.

I had an epiphany while responding in T140207 that makes this proposal even better (I think):

In T140207#2493211, @greg wrote:

#Wikimedia-Incident will be the parent project for the specific incident milestones (see T140202 for details). `Wikimedia-Incident' could also be the solution to this problem. Something like this:

1. See something horrible
2. File task
3. Add #Wikimedia-Incident to alert appropriate people
   1. It goes in the "To Triage (default)" column
4. It is triaged into "Active Emergency"
5. Fix it! (don't worry about column moving, just fix it, Greg/someone can triage it)
6. Does it need an incident report with follow-up tasks? Create a milestone eg #Wikimedia-Incident-20160725-Whatever and move that task to it.
7. See T140202 for how those milestones would be used

#Wikimedia-Incident would then become the project that is watched by myself and responsible people from Operations (though, don't count on us to see the bug mail, a ping on IRC/email is vastly preferred).

I... think that's a good solution, no?

I personally find absolutely no use for the #Wikimedia-Incident-20160725-Whatever tags. I don't recall ever using them as tags or their workboards and they just become noise after a while.

I'm all for a Wikimedia-Incident supertag, though. I actually have proposed that before too, cf. T119944 :)

I think I agree with @faidon regarding individual milestones per incident. That seems like a lot of task management overhead. Creating subtasks for any followup work would be much simpler / easier than creating a new milestone for an incident just because it has more than one task associated with it.

I might be missing something though - is there a specific benefit to the milestones that is being overlooked?

In T140202#2498103, @mmodell wrote:

I think I agree with @faidon regarding individual milestones per incident. That seems like a lot of task management overhead. Creating subtasks for any followup work would be much simpler / easier than creating a new milestone for an incident just because it has more than one task associated with it.

I might be missing something though - is there a specific benefit to the milestones that is being overlooked?

I would think it should probably be based on best judgement in relation to the number of subtasks that the incident report generates.

My opinion is pretty much "what @Peachey88 said".

We're not automatons and can reason whether a milestone would be useful for incident follow-up tasks (aka: the "actionables" section in the incident report).

We could have a "Follow-up/Actionables" (wordsmithing allowed ;) ) column where those tasks go if they don't need a milestone/project themselves. I see this probably being the most common/default choice. I'll edit the description to reflect this.

To keep things as simple as possible at the beginning, let's:

• Just create the #Wikimedia-Incident project/tag now.
• I'll go through as many incident reports as I can and add it to any follow-up tasks listed. Help appreciated with that. I'll create another task for that so others can help (please ;) ).

And looking at the data we have (those 23 still open tasks in those 9 #Incident-* projects) it looks like no one is using the workboards actively (some don't have workboards at all). To clean things up I propose adding them to the #Wikimedia-Incident project and putting them in the 'Follow-up/Actionables' column and archiving the #Incident-* projects. IOW: it seems the people working on them didn't actively need a milestone/workboard, so no need for them now, they can live in that column just fine.

For the sake of order and better orieantation in causes and dependencies it still would be good to have at least a column on Wikimedia-Incident workboard for each incident. Such column can become hidden when incident is considered "solved" and follow up actions moved to proper column.

Having flat board doesn't make a sense that much. Because in fact then only the tasks reporting the incident should be tagged and not all subsequent actions.

I disagree, @Danny_B. The current workboard setup is fine and meets the needs of this task and those who are responding to Wikimedia Incidents. We don't need over-engineering of it. If we need more columns/structure we can do that later (as needed). Thus far it is not needed.