Why Our Lab Needs Version Control 🚀

Our lab is actively working with shared code, and we are growing every day. We constantly create new scripts, adjust existing ones, and develop new versions of Scanfold designs and other experimental workflows. Currently, our documentation is very poor, and we often spend more time figuring out what was done, why it was done, and by whom, rather than actually using the existing scripts to improve or develop new ones. This has become a major drain on our lab's time, resources, and collective effort.

Using version control (like GitHub) helps us:

✅ Collaborate seamlessly – No dependency on a single person who wrote the code.

✅ Keep everything documented & organized – Any team member can update or review changes at any time.

✅ Track differences easily – We always know what changed, who changed it, and why.

✅ Avoid confusion with multiple versions – No more lost or conflicting versions of scripts and data files.

Even if it feels like overkill now, it's a best practice that will save us time, effort, and frustration in the future! 🚀

Our lab is growing rapidly, and while things might feel a bit unstructured right now, we need to start building good habits for version control and documentation. From now on, every new piece of code used in lab projects must be properly documented and stored in GitHub—no exceptions! 🚀

📌 Guidelines for Adding Code to the Repository

1️⃣ Read the Guidelines Before Contributing

Before writing or committing any code, ensure you have read:

📖 Best Practices for Code Documentation
📖 GitHub_Workflow_Guide.md

These documents provide essential guidelines on clean coding, structuring scripts, and using Git correctly to facilitate seamless collaboration. 2️⃣ Project Structure: How to Organize Your Code

Create a new directory inside the lab_projects folder
    📌 The directory name should reflect the project (e.g., RNA_Analysis_Tool, not Johns_Scripts).
Inside this directory, organize your scripts logically, ensuring each script is well-commented block by block.
Provide a README.md file following the format below.

3️⃣ README Documentation Template

Each project must include a README.md file that follows this structured template:

Project Name

📌 Overview

• Briefly describe the project’s purpose and objectives.

🛠️ Methodology

• Summarize the key steps in the analysis or computational workflow.
• Outline the logical approach, including algorithms or models used.
• Provide an example of expected input and output.

🔧 Installation & Dependencies

• List all required dependencies, libraries, and software needed to run the scripts.
• Specify whether the script is designed to run in NIVA's system or on local machines (or both).

🚀 Usage Instructions (Running In Silico Experiments)

• Provide step-by-step instructions on how to execute the scripts for computational experiments.
• If applicable, include command-line execution examples:

  python analyze_sequences.py --input data.fasta --output results.csv
  
    Explain any expected parameters, input file formats, and outputs.
  

⚠️ Assumptions & Important Notes

Document any manual assumptions, edge cases, or logical decisions incorporated into the script.
Mention known limitations or considerations when using the tool.

🌟 Why This Matters

✔ Prevents chaos and confusion (future-you will thank you).
✔ Saves time by making sure scripts are understandable and reusable.
✔ Helps everyone collaborate smoothly (no more "What does this script even do?!").
✔ Makes it easier to debug, track changes, and improve workflows.

Even if it feels like extra work now, it’s a game-changer for efficiency. 🚀

⚡ Bottom line: Follow the process, document everything, and if in doubt—ask! 🎯