@mnohr Is it possible to assign a backend team member here? It seems rather straight forwards as the backend should add a new setting and validate input for it.
@mrincon I am not sure if the backend team will have capacity for this in %13.1. If the other Deliverable items are completed then this will be the next thing to work on.
Based on slack conversation with @dhershkovitch, we are going to leave it as Deliverable for now to indicate priority. @mrincon feel free to leave this on the backburner for now. We'll revisit this in a couple of weeks to determine whether we should remove Deliverable or not
1. Please provide a quick summary of the current status (one sentence).
Backend work has not started yet.
2. When do you predict this feature to be ready for maintainer review?
Changes seem minimal and well outlined (thanks @mrincon). I expect the backend piece to be ready for maintainer review early next week.
3. Are there any opportunities to further break the issue or merge request into smaller pieces (if applicable)?
N/A
@mrincon I assume you meant June 5th How does SRE shadow play in the role of the delivery prediction of the issues?
UTC is fairly important/requested by the infrastructure team and could become blocking in the rollout of the SLA dashboard (removing it from Grafana with a redirect to the GitLab metrics dashboard). I'm wondering if we could get better velocity/address infrastructure team faster if we could set UTC for a project as a feature flag as a smaller iteration so that we aren't blocked by backend capacity. Thoughts? I'm not sure how long backend will take and it would be beneficial to get this out sooner if possible.
The backend work is started and @rcobb has an MR that is in review here: !33120 (merged). Hopefully that will be what is needed for the backend / frontend integration work.
@ClemMakesApps I'm interested in your feature flag idea. How would that work to set UTC for a project? If that is something we could do to facilitate the work to rollout the SLA dashboard, it is worth discussion/investigation.
I also find it odd that UTC as a default would be blocking for the infrastructure team unless the number of projects they need to monitor is significant. Hopefully we can get some feedback from @sgoldstein
@rcobb - Yes the UTC default is important to the Infrastructure team, particularly in contexts where they are coordinating on incident response or analysis. When engineers are in different timezones it becomes challenging for them all to convert local time to UTC correctly when responding to an incident. As a result most ops team (particularly those who are distributed or working a larger companies) tend to prefer to standardize on UTC when communicating times since this creates less room for errors that can delay incident resolution or cause mistakes analyzing impact.
The UTC default is important to moving the dogfooding effort forward - though the approach we are taking seems correct and it is great that will be landing soon. Let me know if there are other questions I can answer or details that would be useful. Thanks!
In order to prevent discussions of the UTC default topic from spreading across too many issues/epics, I've created #219569. Please consolidate the conversation there.
I'm interested in your feature flag idea. How would that work to set UTC for a project? If that is something we could do to facilitate the work to rollout the SLA dashboard, it is worth discussion/investigation.
@mnohr Based on the recent async updates, it looks like (I presume May was supposed to be June in the comment), we will be able to have this issue in verification by June 5. Considering how @mrincon will be doing SRE shadow next week, that seems reasonable for us to wait for that point.
My previous thought (based on the issue updates) was that it looked like frontend was mostly ready and waiting for backend . With that in mind, I wanted to consider the idea of just merging the frontend code for UTC without the toggle in the settings page (as that requires backend) and configure a feature flag (that is project based) be the "toggle" to enable UTC. This would require a little more engineering effort but could potentially get us closer to the infrastructure team needs of having UTC in their charts before moving their SLA dashboard from Grafana to our metrics dashboard.
Considering we are anticipating we can get it in by June 5. I don't think it's worth the extra effort to get the functionality "working" (toggling using feature flag instead of settings) under a feature flag
One we get backend merged, the frontend effort should be small (Consists of connecting the backend setting to the related props in the components, one in panel, and another in the datepicker), this is similar to the effort of adding a feature flag.