Lab Guidelines
Welcome to OMICS Banglads. This comprehensive guide provides everything you need — our expectations, best practices, and available resources — to help you succeed across all our research labs
Mission Statement
OMICS Bangladesh operates several cutting-edge research laboratories focused on pushing the boundaries of life science research. By combining computational biology, artificial intelligence, and novel drug discovery approaches, our labs work collaboratively to address pressing challenges in genomics, precision medicine, and biotechnology.
Our Vision
To establish ourselves as a leading global research organization in computational biology and AI-driven life sciences by fostering innovation, collaboration, and scientific excellence across all our laboratory facilities.
Expectations
Your Role
We expect every lab member to take primary ownership of their research project and career development. You are also expected to actively participate and contribute to the team. To support collaboration and scientific discussion, all members should maintain a minimum presence of 4 hours per day in the laboratory.
Mentor Role
Your mentor’s primary role is to support your success as well as the success of your research project. Within the project, your mentor will serve as a sounding board for ideas, help you plan and refine your research direction, and assist in designing experiments to test your hypotheses. Beyond the project, mentors will support your overall development by helping you plan your training, create a strategic career roadmap, manage your project-risk portfolio, and provide guidance on all aspects of your professional and scientific growth as needed.
Deadlines
Our team is committed to building a strong reputation for producing high-quality, well-presented scientific work. All meeting abstracts must be circulated to every co-author, including mentors, at least one week before the submission deadline.
Oral presentations should be delivered to the research team during a braintrust meeting, and presenters are expected to incorporate the feedback they receive. Poster presentations must be shared in the Slack channel at least one week prior to printing.
Code of Conduct
At OMICS Bangladesh Labs, we are dedicated to fostering a safe, respectful, and inclusive environment for all members and visitors. Discrimination or harassment of any kind, whether based on gender, gender identity, age, disability, appearance, body size, race, religion, or any other personal characteristic, is strictly prohibited.
Authorship
Our team follows the ICMJE's Uniform Requirements for Manuscripts Submitted to Biomedical Journals definitions of the roles of authors and contributors to our manuscripts.
Ethics
Lab members are expected to uphold honesty in all scientific communications, both within the team and externally. Experiments and studies should be designed to minimize bias and avoid self-deception. Members are also expected to honor their commitments, exercise care in their work, and share their code and results openly with the broader scientific community.
Communication
Slack
OMICS Bangladesh Labs operate remotely and use Slack for internal communication. Members should prioritize Slack messages over emails for faster response times.
Required Accounts
- GitHub (organization)
- Slack (workspace)
Meetings
Scrum
Our team's scrum process involves three components:
- A weekly kick-off meeting at
8:30 AM Fridaymorning where individuals will lay out their goals for the week on Zoom. - A demo day meeting at
8:30 AM Saturdayafternoon where team members show off an accomplishment from the week in 3 minutes or fewer. - A daily virtual scrum update on Slack.
Research Meeting
Research meetings are scheduled for one hour on the third Friday of the month. All lab members are expected to attend. Meetings are designed to provide a supportive environment for learning, constructive criticism, help, and scientific discussions.
Meeting Formats
Format 1: Braintrust
The meeting lead presents their own research/project to the group. Presenters often focus on open questions or challenges in their work.
Format 2: Tech Talk/Discussion
Talks on commonly used technology in the team, strategies for staying on top of the literature, organization, etc.
Format 3: Post-Conference Presentations
Journal club talk on a favorite poster/talk from conferences.
Format 4: Big Ideas or Projects
Helps senior members practice for paper discussion sections/conclusions while helping newer members see where the boundaries of fields are.
Format 5: Journal Club
Presentation to be given by the meeting leader followed by group discussion. The meeting leader should aim to send the chosen paper one week before the scheduled meeting.
Format 6: Preprint Review
A preprint is discussed by the group. The discussion is led by the meeting leader, and all members are expected to be familiar with the content.
Source Code, Data, and Reproducibility
Pride
"Craftsmen of an earlier age were proud to sign their work. You should be, too… People should see your name on a piece of code and expect it to be solid, well-written, tested, and documented."
We expect lab members to sign their code, ensuring that source code contributions are attributable to an individual's account on GitHub.
Programming Languages
We write analytical code in Python or R to ensure that all lab members are proficient in both languages.
Licensing
We release as many research outputs as possible under permissive open licenses. The BSD-2-Clause Plus Patent License is the default license for software developed in the lab, as it is OSI-approved, simple, and highly compatible.
Data Management
- Publicly available data: Scripts used to download and process these data should be preserved and version-controlled.
- Generated data: Lab-generated data should be stored in a replicated location and uploaded to relevant repositories (e.g., GEO for gene expression, SRA for sequencing) as soon as possible.
- Intermediate files: Where feasible, reasonable-sized intermediate files should be stored to facilitate re-use.
Reproducibility
All code should support reproducible analyses. This can be achieved through:
- Makefiles, shell scripts, or other automation approaches
- Including scripts for generating figures in manuscripts
- Ensuring all code is reviewed before the submission of a preprint or manuscript
Good Practices
Write Clean Code
Follow coding standards, use meaningful variable names, and include comments where necessary for clarity.
Document Everything
Maintain comprehensive documentation for your projects, methods, and workflows.
Use Version Control
Commit changes regularly with clear, descriptive commit messages.
Collaborate Openly
Share knowledge, help teammates, and participate in code reviews.
Social Media Policy
Lab members are encouraged to share research and updates via public social media. If a member associates their profile with OMICS Bangladesh Labs, they must adhere to our code of conduct.
Important Note
If required by an employer or collaborator, members should include a disclaimer stating that opinions are personal and do not represent Omics Bangladesh.
AI Usage Policy
Responsible AI Use
This document establishes guidelines for the responsible and ethical use of AI tools in research, development, and lab activities.
- AI tools should be used to augment, not replace, critical thinking and scientific rigor
- Always verify AI-generated content for accuracy and appropriateness
- Disclose the use of AI tools in research publications when applicable
- Be mindful of data privacy and confidentiality when using AI services
GitHub Guidelines
Version Control and GitHub Usage
Our primary version control service is GitHub, and lab members should maintain their code in repositories under the OMICSBD GitHub organization.
Creating a Lab Repository
Create a repository under the OmicsBD GitHub organization
Immediately fork this repository into your user account
Make commits to your personal repository first
Follow the code review process before merging changes
Code Review Process
Code moves from personal repositories to lab repositories via pull requests. All changes must go through this review process:
- Make changes and commit them to your personal repository
- Create a pull request (PR) into the corresponding lab repository
- Assign reviewers to the PR
- At least one lab member must approve the PR before merging
- PRs should focus on a single functional area to facilitate easier reviews
Handling Projects That Didn't Work
Repositories may contain failed projects (e.g., proof-of-concepts that didn't succeed). Keeping track of these failures helps us avoid repeating mistakes and fosters transparency in research.