Eric Lee

On the issue of having the wrong status displayed to the user: one proposal is to change the job status update mechanism to a heartbeat mechanism, since that these jobs...

@shazraz @mohammedri bringing the conversation about tracking functionality from #63 to a new issue.

Proposal: Add a default parameter that indicates the function will append to existing value, i.e. change from `log_metric(key, value)` to `log_metric(key, value, overwrite=False)` Pros: backwards compatible, user gets to choose...

@Dessa-ColeClifford I like that idea. We don't have to modify the SDK in that case. Were you thinking a toggle of sorts on a per-column basis for metrics?

For reference, an old issue that planned to productionize Tensorboard, mentioning multi-tenancy: https://github.com/tensorflow/tensorboard/issues/92. Unfortunately the issue was closed because the planned features were "too ambitious and potentially overlap with the...

@shazraz @mohammedri bringing this conversation about tracking functionality to #131

On the issue about disjoint UX between local and scheduled job, I think the gap is that Atlas is ignorant about the following pieces of data: 1. where the job...

For #131, the manual Start/Stop proposal alone seems to be able to address that problem. I'm not clear on whether the other design elements are needed to address that concern....

To address issue #73, is the suggestion in this design proposal that users configure their local execution to use other archiving methods (e.g. design element 4 above) instead of the...

> > I suggest that if we were to tackle the issue of discrepant UX, we will need to capture these 3 pieces of data at minimum and make the...