Sharing Results Responsibly

Introduction

A correct analysis can still do harm if it exposes people, overstates a weak finding or cannot be understood. Responsible sharing is part of professional data work. This lesson is general education, not legal advice. Privacy and data laws differ by country and sector.

Know what data you hold

• Does it describe people? Names, addresses, emails, dates of birth, locations and unique ids can all identify someone.
• Do you have the right to use it, for this purpose?
• What are the rules of your workplace, school or the data provider?
• Collect and keep only what you need.

Reduce privacy risk

• Remove direct identifiers, such as names and contact details, when they are not needed.
• Pseudonymise: replace identifiers with codes. This lowers risk but may still count as personal data, because the codes can sometimes be linked back.
• Aggregate: share totals and averages instead of individual rows.
• Suppress small groups. A table that says "one member in Hull borrowed 1 book" identifies a person. Hide or combine groups below a minimum size.
• Beware of combinations. A few ordinary fields together, such as city, age and a date, can pick out one person.
• Limit access, store data securely and delete it when it is no longer needed.
• Never put real personal data in public repositories or notebooks.

In the library project, the Hull city group contains one member. In a real report, you would combine small groups or leave them out.

Report uncertainty and limits

• Say how many rows and what period the result covers.
• Show counts next to averages and percentages.
• Avoid precision you do not have: 16.9 days is fine, 16.94872 days is not.
• Distinguish evidence from speculation.
• Name the assumptions and the data problems you found.
• State what the data cannot tell you.
• Do not cherry-pick results. Mention analyses that did not support your story.

Fairness and harm

Data about people can affect decisions. Ask:

• Who could be affected by what I report?
• Is the data representative, or are some groups missing?
• Could my result be misused, for example to judge individuals unfairly?
• Are the categories respectful and meaningful?

If results will inform decisions about people, involve the people responsible for fairness and legal compliance.

Document for others

A good project README includes:

• The question and the main finding with its limits
• Data sources, dates and licences, and the data dictionary
• How to run the pipeline: setup, commands, expected outputs
• Folder structure and what each part does
• Tests and how to run them
• Known issues and next steps
• A contact and the date of the last update

A portfolio piece

To show your skills:

• Choose a question you care about and open data that is licensed for reuse.
• Show the whole process: question, cleaning, analysis, tests and a clear write-up.
• Keep it short and polished. One excellent project beats five rough ones.
• Explain your decisions and what you learned, including mistakes.
• Publish code in a repository, with a readable report or page.
• Respect privacy and licences.

You now have a path through data projects: from your first query to a tested, documented pipeline. Keep practising on new questions, and combine this with the SQL, pandas and machine learning courses.

Try it yourself

Review your project for privacy: list the columns that could identify someone, decide what to remove or aggregate, and check for small groups in your tables. Then finish the README with every section above.

Summary

• Know what personal data you hold, minimise it, aggregate, suppress small groups and never publish real personal data.
• Report counts, limits and uncertainty, avoid cherry-picking and consider who could be affected.
• Document the project fully, and present one clear, honest portfolio piece.