Abhigyan Chakraborty

Contributing to Open Science

Phase 4: Open Science — Part 2

(Part 11 of series Blueprint for a Modern Research Computing Environment)

Follow me :

LinkedIn    Website    Website

Quick Summary

This final part is about contributing to the broader scientific and open-source community. You’ve built a working Python development environment, organized your projects, managed dependencies, and learned version control; now, this article guides you through sharing that work responsibly — choosing licenses, making code citable, contributing to existing projects, and building a public professional presence.

Objective

Science moves faster when work is shared, reused, and improved by others. This part explains how to transition your personal research environment into a public contribution.

By the end, you’ll understand:

Content

💡 Getting Unstuck (Expand for AI Troubleshooting Prompts)

AI tools (like Claude, Grok, Gemini, or ChatGPT) give the best troubleshooting advice when they have the exact text of the tutorial. To ensure the AI understands what you are trying to build, we will give it the actual file.

1. Download the tutorial file

2. Upload it to your AI

3. Ask for Help Copy and paste this exact prompt into the chat along with your file:

I have attached the markdown file for the tutorial I am following. Please read it so you understand the specific environment I am trying to build.

I need help with the following:

Step [X]: [paste exact step text from the blog]

Command I ran: [paste exact command]

What happened: [paste full output/error — if the terminal was truly blank, say so explicitly]

Please help me troubleshoot and fix this error. You can use your general knowledge to solve the problem, but your solution MUST align with the architecture and tools taught in the attached file. Do not suggest alternative setups that contradict the tutorial. Once fixed, tell me what to do next in the article.

To go deeper on a step before you run a command:

I have attached the Part11.md file. Look at Step [X] and explain exactly what the command does and why we are doing it before I run it.

Think of this series as the roadmap and your AI assistant as your learning companion.

Prerequisites

Section 1 — What is Open Science?

Open Science is the practice of making research—data, methods, code, and results—publicly available. It extends the traditional scientific publishing process to the digital artifacts of modern research.

Why it matters:

Section 2 — Sharing Code on GitHub

To share your work effectively:

  1. Make Repository Public: In GitHub Settings, navigate to the “Danger Zone” and set visibility to Public.
  2. Repository Hygiene: Ensure your repo includes README.md, environment.yml, requirements.txt, LICENSE, .gitignore, and .env.example.

Section 3 — Writing an Effective README

A public README is the first point of contact for your project. It must answer:

  1. What does this do? (No jargon).
  2. Who is it for? (Target audience).
  3. How do I set it up? (Step-by-step commands).
  4. How do I run it? (Minimal working example).
  5. How do I cite it? (Citation block).

Section 4 — Choosing an Open-Source License

Without a license, others cannot legally use or modify your code.

Use choosealicense.com to pick the best fit, then create a LICENSE file in your repository via GitHub’s “Add file” menu.

Section 5 — Citing Software and Datasets

Citing Software You Use: Cite major packages based on their documentation (e.g., NumPy’s Nature paper). If no formal citation exists, cite the GitHub repo and version number.

Making Your Code Citable:

  1. Use Zenodo: Log in via GitHub, enable the repo, and create a GitHub release.
  2. DOI: Zenodo will archive the release and issue a Digital Object Identifier (DOI), which serves as a permanent, citable link.

Publishing Datasets: Use Zenodo or domain-specific repositories like Figshare, Dryad, Pangaea, or Harvard Dataverse.

Section 6 — Contributing to Open Source

Contributing involves a standard workflow:

  1. Fork: Create a copy of the target repository under your account.
  2. Clone: Download the fork locally.
  3. Branch: Create a new branch for your changes: git checkout -b fix-branch.
  4. Modify & Commit: Make your changes and commit.
  5. Push: Upload your branch: git push origin fix-branch.
  6. Pull Request (PR): Open a PR on the original repository.

Good first contributions: Fix documentation typos, clarify error messages, or report bugs with clear reproduction steps via GitHub Issues.

Section 7 — Building a Public Portfolio

What You’ve Done

What You’ve Done:

Previous: Part 10 — Building Reproducible Research Workflows

All Blogs

This site is open source. Improve this page.