David de la Iglesia Castro

> I'm not sure text-based alerts add enough value (we could instead have a doc or blog post showing how to use dvclive + https://github.com/liiight/notifiers). Full reports with plots seem...

Revisiting this. Now that we are moving towards depending on [dvc-render](https://github.com/iterative/dvc-render), I'm assuming it makes more sense to implement these different plotting options on `dvc-render` side, right? > Use stdout...

> Would either of these improve the experience? Are there other ideas? I would like to go with `1`. > it's starting to get to be a lot of methods...

> Automatically add dvclive/report.html to .dvcignore (should we check for the presence of DVC or just add it anyway?). I won't really like to add DVC-specific logic. > Move report.html...

Would https://github.com/iterative/dvclive/pull/322 close this? Given that plots will be isolated in it's own folder, the following won't track the report: ``` plots: - dvclive/plots ```

It looks that for some ML Frameworks which have some "resuming" argument this should be a Documentation update

Lowering the priority as this depends on deciding and documenting the recomended workflow for DVC checkpoints

Back to `p1` as it is relevant for simplifying the "recovering with `DVC_EXP_AUTO_PUSH`" scenario

Relevant for https://github.com/iterative/terraform-provider-iterative use case

Inside each integration, we should look for the ML-Framework specific flags and handle `Live`'s argument `resume=True` properly