This message was deleted.

if storing the output notebooks simplifies collaboration (e.g. to review result), then yeah, it makes sense to store them in git, although take into account that git is not designed to handle large files so you may look into git LFS or store them somewhere else, so whatever is more convenient. ideally, people should not be modifying products directly, but rather add a new script that processes the product and stores the new version. finally, soorgeon should only be a one-off process. once you get the pipeline, it's best to work directly there. thoughts?

Ideally the flow should be on developing on the .pys and having a notebook product you can review and generate on demand. Is there a reason that some users changing the products directly? or it’s just because of the .ipynb

Well we are facing following problem how to collaborate all of us: users A(Prototype),B(developer), C(mostly reviewer ), before ploomber era: A test-idea.ipynb, B test-idea_fromA_C.ipynb,C test-idea_B_merging.ipynb, C editing nice-plot function to improve it then need to push back to other notebooks.. totally mess. Finally we have 1,2,3,4 notebooks and data1v1,…data1vN with N notebooks and plots J To improve the situation, I have decided to move the workflow to ploomber: tasks/ products A- creates some new idea and makes a draft plots in test-idea.ipynb B- soorgeon test-idea.ipynb idea , converting to ploomber project “idea” with the folders tasks and outputs C - going to check the results in the outputs/nice-plot.ipynb In this point we are somehow got stack

if C has feedback for A, can A edit the existing ploomber pipeline? even if the tasks are .py, A can still open them as notebooks due to ploomber's plugin so it's essentially the same experience as when A was working on the initial idea in an ipynb file, except the logic is now organized in a few files. i'm guessing A doesn't feel comfortable working on the ploomber pipeline, I'd like to know what are the friction points