Skip to content

Contributing to Data Science & AI Cheat Sheets

Thanks for contributing! This repository works because people like you share concise, accurate references with the community. This guide explains how to add new cheat sheets, improve existing ones, and keep the repository consistent as it grows.

Table of Contents

Ways to Contribute

  • Add a new cheat sheet — use the template and place it in the matching category.
  • Improve an existing sheet — fix errors, add missing sections, refresh outdated content.
  • Fix typos and broken links — small fixes are always welcome.
  • Review pull requests — verifying code samples and facts is a great way to contribute.
  • Suggest ideas — open an issue for new cheat sheets, categories, or roadmap items.

Getting Started

  1. Fork the repository on GitHub.
  2. Clone your fork locally.
  3. Create a branch with a descriptive name, e.g. feat/add-pandas-cheatsheet or fix/pandas-typo.
  4. Make your changes following the conventions below.
  5. Push your branch and open a pull request against main.

Contributor Checklist

Run through this before opening a pull request. Tick every box in your PR description.

  • File is in the correct numbered category directory
  • File name is kebab-case, one topic per file
  • Front matter complete: title, description, category, tags, status, last_updated
  • last_updated set to today's date (YYYY-MM-DD)
  • Section headings follow the template order
  • Code blocks fenced with a language tag and verified to run
  • Tables have a header row, separator row, and consistent column counts
  • All internal links resolve (test them or ask a maintainer to run the link check)
  • Category README.md index updated
  • NAVIGATION.md updated if a category or link changed
  • CHANGELOG.md updated under [Unreleased]
  • No real API keys, tokens, or credentials — use YOUR_API_KEY-style placeholders
  • No large copy-pasted blocks from copyrighted sources

Creating a New Cheat Sheet

  1. Choose the category. Consult the central navigation index to find the right numbered directory. If no category fits, open an issue to discuss a new one (see New Technology Submission Process).
  2. Copy the template. Start from cheatsheet-template.md — every cheat sheet must follow its structure.
  3. Name the file in kebab-case, e.g. pandas-essentials.md. One cheat sheet per file, one topic per sheet.
  4. Fill every applicable section. Use the Last Updated section to record the date. Mark genuinely not-applicable sections as N/A rather than deleting the heading.
  5. Update the category index. Add a row to the "Cheat Sheets" table in the category's README.md.
  6. Verify internal links. Every link to another file in the repository must resolve.
  7. Update the changelog. Add a line under [Unreleased] → Added in CHANGELOG.md.

Repository Conventions

These conventions keep the repository consistent and scannable even at 100–200+ sheets. They are the ground rules for every contribution.

File naming

  • One cheat sheet per file, one topic per file. A sheet covers a single tool or a tightly-scoped topic (e.g. pandas.md, ml-preprocessing.md).
  • kebab-case, all lowercase: python-typing.md, not PythonTyping.md or python_typing.md.
  • Use the canonical tool name for the file where one exists (pandas.md, fastapi.md, scikit-learn.md).
  • Cross-cutting topics that belong to a framework get a descriptive name: ml-evaluation.md, rag-evaluation.md, data-pipelines.md.

Folder conventions

  • The repository is organized into 30 numbered category directories: 01-Python/, 02-Data-Analysis/, … 30-Other-Tools/.
  • A topic's home is the category where users would search for it first. When in doubt, open an issue rather than guessing.
  • Every category directory contains a README.md index page (breadcrumb + cheat-sheet table). Keep the count in the index row in sync when you add or remove a sheet.
  • New categories are only created through the submission process — never ad hoc.

Front matter

Every cheat sheet starts with a YAML front-matter block:

---
title: <Tool Name>
description: <One or two sentences: what this covers and who it is for.>
category: <Category directory name, e.g., 02-Data-Analysis>
tags: [<tag-1>, <tag-2>]
status: ready
last_updated: YYYY-MM-DD
---
  • category must exactly match the directory the file lives in.
  • status is ready for finished sheets; draft only while work is in progress.
  • last_updated is the date of the latest substantive change (see Version & date policy).

Headings

  • Use ATX headings (##, ###), never ===/--- underlines.
  • Use the template's exact heading text (Title Case, e.g. ## Common Mistakes, ## Official Documentation). Don't rename headings (Pitfalls instead of Common Mistakes) — consistent names make sheets comparable and keep the Table of Contents anchors working.
  • Keep the template's section order. Readers learn where things are by position, not by reading.
  • Every heading used in the Table of Contents must exist as a heading (anchor links must resolve).

Code blocks

  • Fence every code block with a language tag: ```python, ```bash, ```sql, ```yaml, ```text for output.
  • Snippets must be real, runnable where possible. Verify commands before committing them.
  • Show expected output in a text block after examples so readers know what success looks like.
  • Use YOUR_API_KEY-style placeholders for credentials — never real keys (see Content Guidelines).
  • Keep lines reasonably short so code doesn't force horizontal scrolling on GitHub.

Tables

  • Every table has a header row and a separator row (|---|---|).
  • Column counts must match across all rows of a table.
  • Escaped pipes inside code or text are written as \| — a raw | inside a cell breaks the table.
  • Use tables for reference data (commands, functions, flags, comparisons). Use lists for sequences and prose.
  • Keep cells concise; prefer short snippets over sentences in cells.
  • Use relative links for everything inside the repository.
  • Same directory: [pandas](pandas.md).
  • Other category: [pandas](../02-Data-Analysis/pandas.md) — always include the ../ prefix.
  • Category page: [Python](../01-Python/README.md).
  • Anchors: [Common Mistakes](#common-mistakes) — GitHub slugifies headings; check that anchors match.
  • Never link to a file that doesn't exist. When in doubt, open the link before pushing.
  • External links go in the Official Documentation section (see below).

Official documentation policy

  • Every sheet ends with an Official Documentation section listing the authoritative docs, API references, and tutorials for the tool.
  • Prefer links to official documentation over third-party blogs when both exist.
  • Verify external URLs work. Sites that block bots (e.g. some vendors) still need a URL that a human browser can open.
  • If official docs moved, update the link rather than deleting the section.

Version & date policy

  • last_updated in the front matter is updated on every substantive change to the sheet — even a small fix.
  • The Last Updated section at the bottom restates the date plus a short summary: 2026-09-07 — Fixed broken SQL example links.
  • Note version numbers where behavior changes between releases (e.g. pandas 2.x, Python 3.10+). Mark version-dependent syntax inline: int | None (3.10+).
  • Never document pre-release-only APIs as stable. If an API is deprecated, say so and give the replacement.
  • Do not chase every release. Refresh a sheet when the stable, widely-used API changes — not on every minor version bump.

New Technology Submission Process

A cheat sheet is a commitment to maintain: facts go stale, APIs move, and readers trust the content. New topics follow a light process so the repo grows deliberately.

  1. Open an issue first. Describe the tool, why it matters to the data/AI community, and which category it belongs in. Label it new-cheat-sheet.
  2. Maintainers confirm the fit — category, naming, and whether it duplicates an existing sheet. If an equivalent sheet exists, the issue becomes a "improve existing" request instead.
  3. New categories need extra discussion (numbering, scope, cross-links). They are created only when a single sheet can't fit an existing category.
  4. Once approved, create the sheet from the template and follow the contributor checklist.
  5. First-time contributors can skip the issue and open a draft PR — maintainers will help shape it.

Updating an Existing Cheat Sheet

Updating is encouraged and low-friction:

  1. Make the change in place — same file, same structure. Don't fork the sheet into a new file or category.
  2. Keep the template section order — insert new content into the matching section rather than appending new headings.
  3. Bump last_updated and update the bottom Last Updated line with a one-line summary.
  4. Update related links if your change affects other sheets that reference this one (e.g. a renamed file).
  5. Add a Changed line in CHANGELOG.md under [Unreleased].

Deprecating an Obsolete Technology

Tools go stale — that's normal. Deprecation is explicit so readers aren't misled:

  1. Prefer updating over removing. If a tool still works but is niche, say so in its Best Practices or Troubleshooting section instead of deleting the sheet.
  2. Mark deprecated tools clearly. Update the front matter description and the intro line to state the status and the recommended replacement, e.g. "Note: tool X is deprecated as of 2025; the maintainers recommend Y."
  3. Keep the sheet for historical reference unless it actively misleads readers (broken APIs, security issues). Delete only with maintainer agreement, recorded in an issue.
  4. Remove the sheet from the category index and navigation if it is deleted.
  5. Record the decision in CHANGELOG.md (Removed or Changed) and reference the issue.

Content Guidelines

  • Accuracy first. Verify every command and code snippet against official documentation or by running it. Never guess.
  • Be concise. A cheat sheet is a reference, not a tutorial. Prefer tables and short snippets over paragraphs.
  • Write original content. Explain things in your own words. If you quote official docs, cite the source. Do not copy-paste large blocks of copyrighted material.
  • Stay in scope. One tool or topic per sheet. Cross-references belong in the "Related Cheat Sheets" section.
  • Use complete, runnable snippets where possible, and show expected output for clarity.
  • Keep it current. Note version numbers where behavior changes between releases (e.g. pandas 2.x).
  • Never include real secrets. API keys, tokens, passwords, and private keys in examples must be placeholders (YOUR_API_KEY, <token>, example). Real credentials are an instant revert.

Pull Request Process

  • Title — Add <topic> cheat sheet for new sheets, Fix: <short description> for corrections.
  • Description — summarize what you changed and why. For visual topics, include a screenshot.
  • Scope — keep PRs focused on one sheet or one fix. Large rewrites are easier to review in pieces.
  • Checklist — complete the contributor checklist in your PR description.
  • Review — maintainers or other contributors may request changes; treat feedback as collaboration, not criticism.

Review Checklist

For maintainers and reviewers:

  • Follows the template structure and conventions
  • Front matter complete and category matches the directory
  • last_updated is current and the Last Updated line matches
  • Code samples and commands verified
  • All internal links resolve (including ../ prefixes across categories)
  • Tables have consistent column counts and escaped pipes where needed
  • Category index updated in the category README.md
  • CHANGELOG.md updated under [Unreleased]
  • No real secrets/API keys in examples
  • No large copy-pasted blocks from copyrighted sources
  • Official Documentation section present with working URLs
  • For deprecated topics: status clearly marked with a recommended replacement

Code of Conduct

All contributors are expected to follow the Contributor Covenant code of conduct. Be respectful, be constructive, and assume good faith.

Questions? Open an issue or start a discussion — we are happy to help you get your first cheat sheet merged.