📖 Chapter 06 — Sharing & Collaboration
Notebooks, datasets, results. How to share analytical work with other people.
Learning Objectives
- Share notebooks with collaborators (read-only, comment-only, edit)
- Share datasets with controlled access
- Publish results: dashboards, reports, exports
- Use JupyterHub for multi-user analysis
Introduction
An analysis that no one else can see is a private analysis. Most analyses have at least one other person who needs to see the result: a collaborator, a stakeholder, a reviewer. The question is: how do you share the work in a way that's useful and safe?
This chapter covers the patterns for sharing: notebooks (read-only vs editable), datasets (controlled access), results (published dashboards, exported reports). The principles are similar to Volume 2 Chapter 7 (extending to friends) and Volume 3 Chapter 6 (sharing with collaborators), applied to the data scientist's workflow.
Sharing notebooks
A notebook is a JSON file with code, output, and markdown. Three ways to share:
- Export to HTML: a static rendering of the notebook with all the output. Anyone can open it in a browser. No code execution. The right answer for stakeholders and reviewers.
- Export to PDF: a printed version of the HTML. Same use case as HTML but for printing.
- Share the .ipynb file: the raw notebook. The other person can open it in Jupyter and run the cells. Right for collaborators who'll modify the analysis.
For most sharing, the export to HTML is the right answer. The reviewer sees the code, the output, the markdown. They can't accidentally run cells. They can print it, save it, email it.
JupyterHub for live collaboration
For live collaboration (multiple people working in the same notebook), JupyterHub is the right answer. Each user has their own environment, but they can access the same shared notebooks, datasets, and results.
JupyterHub also handles authentication (per-user accounts) and resource limits (each user gets a max amount of CPU/RAM). For a small team (3-5 people), a single JupyterHub on the NAS is sufficient.
For real-time co-editing (multiple cursors in the same notebook, like Google Docs), use JupyterLab + collaborative extensions, or use Google Colab-style notebooks (JupyterHub + nbgrader + a real-time collaboration extension).
Sharing datasets
For datasets, the sharing patterns:
- Read-only SMB/NFS mount: the other person can read the data but not modify it. The right answer for most collaborators.
- S3-compatible access: if the data is in S3 (or MinIO), the other person gets read-only credentials. Use for cloud-style workflows.
- Public link: for small datasets, a download link. Time-limited, password-protected (Chapter 7 of Volume 2 has the patterns).
For most home data science, the read-only mount is the right answer. The collaborator can read the data, do their analysis, and write their results to a different location.
Sharing results: dashboards
For a recurring analysis, the right answer is a dashboard. The dashboard updates as the data updates. Stakeholders check the dashboard; you don't have to email them.
For a home data science setup, the dashboard tools:
- Streamlit: a Python framework for building dashboards. Pure Python, no JavaScript. Easy to deploy as a Docker container.
- Dash (by Plotly): a more powerful framework for interactive dashboards. Python, more complex than Streamlit.
- Metabase: a self-hosted BI tool. Connects to databases, builds dashboards with a UI. The right answer if you want a "no-code" dashboard.
For most home data science, Streamlit is the right default. A Streamlit dashboard is a few lines of Python. It runs in a container. It updates in real-time as the data updates.
Sharing results: reports
For a one-off or periodic report, the right tool depends on the audience:
- Notebook to HTML: for technical reviewers. The notebook is the report.
- Quarto or R Markdown: for reports that mix code, output, and prose. Renders to HTML, PDF, Word. Used widely in data science.
- PDF: for formal reports, printouts, archival. The export from the notebook or the Quarto report.
For most home data science, the notebook-to-HTML export is the right answer. The reviewer opens it in a browser, sees the code, the output, the markdown. Done.
Sharing results: scheduled emails
For a recurring report, the pattern: a scheduled script generates the report (as HTML, PDF, or a chart) and emails it. The recipient doesn't have to check a dashboard; the report arrives in their inbox.
For most home data science, scheduled emails are overkill. But for stakeholders who want the regular update ("what were the sales last week?"), the pattern works.
The implementation: a cron job that runs the report-generation script, then sends the email. The email is plain text or HTML with the chart as an attachment.
Access control
For shared data and shared notebooks, the principle of least privilege applies:
- Read-only by default. Give write access only when needed.
- Time-limited access. Remove access when the project ends.
- Audit who has access. Review the list periodically.
For TrueNAS, the access is controlled by the SMB share permissions and the dataset permissions. For JupyterHub, the access is per-user, controlled by the JupyterHub admin.
For most home data science, the access control is informal — you trust the collaborators. The discipline is: when the project ends, the access ends.
What NOT to share
Some things shouldn't be shared:
- Credentials: API keys, database passwords, SSH keys. Never put them in a notebook or a commit.
- Personal data: anything that identifies a real person without their consent. Anonymize, aggregate, or get permission before sharing.
- Proprietary data: anything that came with a non-redistribution agreement. Check the license before sharing.
The discipline: review the notebook and the data before sharing. Strip credentials, anonymize personal data, check licenses. The 5 minutes of review is worth avoiding a leak.
Engineering Note
Sharing is part of the work. An analysis that no one else can see is an analysis that doesn't matter. The act of sharing — making the notebook presentable, the dashboard live, the report readable — is part of the analysis. The discipline: design for sharing from the start. Write the markdown. Document the methods. Build the dashboard. Share the result.
Summary
Share notebooks as HTML for review, as .ipynb for collaboration. Use JupyterHub for multi-user live collaboration. Share datasets read-only. Use Streamlit or Metabase for dashboards. Use scheduled emails for recurring reports. Apply least-privilege access. Strip credentials, anonymize personal data, check licenses. The discipline: design for sharing from the start. The work isn't done until it's shared.
Checklist
- ⬜ For each notebook, decide the audience: reviewer (HTML), collaborator (.ipynb), or yourself (no export)
- ⬜ For shared data, use read-only mounts and time-limited access
- ⬜ For recurring reports, build a dashboard (Streamlit, Metabase) or a scheduled email
- ⬜ Before sharing, review the notebook and data: strip credentials, anonymize personal data, check licenses
Looking Ahead
Chapter 07 is reproducibility. The discipline of doing the work in a way that can be repeated. The tools that help (Git, DVC, conda, Docker). The patterns that make the analysis trustworthy. The chapter that turns "I think I remember how I did this" into "I can show you exactly how I did this, and you can re-run it."