2 minute read

Contributing to From CV to Site

Thanks for being here. This project is a work-in-progress, and contributions of any kind are genuinely welcome — especially from academics who have never contributed to open source before. (That’s most of us. It’s fine.)

Ways to contribute

You don’t need to know Git to help. Here are the most useful things you can do, roughly in order of effort:

1. Open an issue

If something in a tutorial doesn’t make sense, something is missing, or you’re stuck on a step — say so. Unclear steps aren’t your fault; they’re bugs in the writing. Opening an issue helps the next person who hits the same wall.

Good issues include:

  • Which tutorial you were reading (e.g., “Tutorial 3, Tech Setup”)
  • What you expected to happen
  • What actually happened (error message, screenshot, or a description is all fine)
  • Your operating system, if relevant (macOS / Windows / Linux)

You don’t need to debug it yourself. Just flag it.

2. Suggest a topic

If you’re an academic with a specific need that isn’t covered — a lab site with multiple people, a site in a non-English language, a teaching-focused layout, a multilingual CV — open an issue describing what you’d want. Feature requests from real users shape what gets written next.

3. Share your own site

If you build a site using this guide (or adapt the approach), I’d love to see it. Open an issue titled something like “Share: [your name]’s site” with a link. A gallery of sites built this way is on the roadmap.

4. Fix typos or improve wording

If you see a typo or awkward sentence in a tutorial:

  1. Click the pencil icon on the file in GitHub
  2. Make your edit
  3. Click “Propose changes” at the bottom — GitHub handles the rest

No terminal, no Git commands needed.

5. Contribute a tutorial or section

If you want to write a full tutorial (or a section of one), open an issue first so we can align on scope. The tone is friendly-but-specific: assume the reader is a smart academic who has never written web code. Write like you’re explaining to a colleague over coffee.

Pull requests

For larger changes:

  1. Fork the repo
  2. Create a branch (git checkout -b my-change)
  3. Make your changes
  4. Open a pull request with a short description of what and why

Small PRs are easier to review than big ones. If you’re unsure, open an issue first.

Code of conduct

Be kind. Assume good intent. Give feedback on the writing, not the writer. This community includes people who are building their first website ever — treat their questions with the same care you’d want for your own.

Anything that wouldn’t be okay at an academic conference isn’t okay here either.

Getting in touch

Thanks again for being here. Every question, typo fix, and fork makes this guide better for the next person.

— Hannah