Start with one question and permitted data
Choose a bounded question such as comparing product revenue in a synthetic orders sample. Write the question before creating charts. Record where the dataset came from, whether redistribution is allowed and which fields mean what. Use generated classroom records for this exercise; a portfolio repository does not need private customer or employer data to demonstrate analysis skills.
Separate inputs, analysis and explanation
Keep a small permitted sample under data, analysis logic in a script or notebook, and the project explanation in README.md. Describe how inputs become outputs and where each transformation happens. Avoid a repository containing only a screenshot: a reviewer should also understand the calculation and the steps needed to reproduce it.
Write a README that can be followed
Use the example below as a starting template, then replace its instructions with your actual setup, command and expected output. Explain the question, data source, field definitions, cleaning decisions and limitations. If the project requires additional packages, record the versions used. Include a compact result table only after it agrees with the committed input and analysis.
Review the staged changes
Before a commit, use git status and git diff --staged to check the files and content you are about to record. Stage a small coherent change such as documenting the dataset or adding a duplicate-ID check. Write a commit message that identifies that change. A visible sequence of understandable improvements is more useful than manufacturing a long commit history.
Use ignore rules with the right expectation
Add local environment files, caches and private input folders to .gitignore before staging them. Git ignore rules concern untracked files; adding a rule does not remove a file already tracked or erase earlier commits. Inspect what is actually tracked. If credentials were exposed, remove their validity through the relevant service rather than assuming an ignore rule makes them safe.
Test reproduction in a fresh copy
After preparing the project, make a separate local copy from the committed version and follow only the README. Check that every required input is available, file paths work and commands do not depend on unsaved notebook state. Record discrepancies and fix the instructions or implementation. Do not claim reproducibility merely because the project runs in your original working folder.
Practice a reviewable mini project
Implement the synthetic orders example: validate unique order IDs, calculate quantity times unit_price, group revenue by product and display the result. Add an empty-input case and a duplicate-ID case with explicit expected behaviour. Ask a peer to explain your result from the README and source. Their questions show which assumptions or steps still need documentation.
Finish the portfolio handoff
Provide a direct repository link only after checking access and reviewing all committed files. Keep screenshots consistent with the current code, identify the sample's limitations and distinguish your work from borrowed libraries or datasets. Do not invent a company assignment, client outcome or placement result. The deliverable is evidence of a clear analysis process and a result someone else can inspect.
README starting template—complete before publishing
# Sample Orders Analysis
## Question
Which product has the highest revenue in the supplied synthetic sample?
## Data
Use a small, synthetic CSV with these fields:
order_id, product, quantity, unit_price
Document units and explain missing-value handling.
Never substitute private customer records into this public example.
## Project files
- README.md: question, setup, data notes and limitations
- analysis.py: cleaning, validation and calculation steps you implement
- data/sample.csv: permitted synthetic input
- .gitignore: local/private files excluded from future additions
## Reproduce
1. State the Python version and any dependency versions you use.
2. Add your actual command for running analysis.py.
3. State the expected output for the committed sample.
4. Run those instructions from a fresh local copy.
## Review
Check duplicate order IDs, missing product names and invalid quantities.
Explain whether unit_price and calculated revenue include tax.
## Limitations
This is a classroom sample, not evidence about a real market.
Complete the run command and expected output before publishing.
Expected result
A complete project has an actual run command, documented input and expected output. The template is a checklist, not a completed analysis or a claim that files already exist.
Further reading
Check your progress
Keep your working files, test cases and notes together. Explain one design decision, demonstrate a failure case and list what you would improve next. These concrete outputs make it easier to identify the next skill to practice.