Hi Cruna. I hope this finds you well.
As I read over the posts from the start of this event to now, it appears pretty clear that there is a growing number of people that have become a bit sour and critical of the dev team/staff in general, warranted or not. I have not been here long enough to understand the history of feature/functionality releases and what was or was not in each iteration to weigh in on the matter.
That said, would you really stand in front of this firing squad and give a “best guess” response?
I agree that a customer facing update should be given at predetermined intervals stating very simply:
1. if they have or have not identified the problem.
2. If they have or do not have a solution, and if it’s temp or permanent.
3. Is the fix currently in testing or has been validated.
once Service is restored the dev team can then put out a customer facing root cause analysis explaining the root cause and what steps are being taken to mitigate future service interruptions.
Its clear that there are historical conversations that both sides have differing perspectives about which resulted in trust lost between customer and devs. I think both sides would benefit from defining a process for service interruptions. This will one, manage expectations on both sides and secondly provide a measuring tool for time to resolution metrics. If we talk about solutions moving forward and both sides agree there has been or effort to improve. We can the. Address the large issues in the room without pointing fingers.
Sorry for the lengthy response. I can be a bit of watch builder, and that takes alot of time to finish.