Merge branch 'main' into ofek/make-a-page-on-deseq2-and-edger

docs/General/Meetings/owl_basics.md

@@ -0,0 +1,17 @@
+# Lab Owl meeting Basics
+
+The Owl is a device that works as video and audio input for all meetings conducted in the BHK lab. It is pivotal to include the Owl in all lab meetings to bridge the gap between the users tuning in remote to the users on site.
+
+## How to find/obtain the Owl
+
+1. Go to Jermiah's work station (W-16).
+2. Grab the key located on the bottom side of Jermiah's desk.
+3. Using the key open the top drawer of the filing cabinet under Jermiah's workstation and grab the key labelled "Owl key".
+4. Use this new key to open the bottom drawer of the filing cabinet directly to the right of the lab/GPU server and pull out the green Owl duffle bag.
+
+## How to use the Owl
+
+The Owl has two major setup components. The Owl must be connected to an electrical outlet and also be connected to your computer via a USB connection.
+If you have a Mac laptop you may need to use an adapter to allow direct USB connection. Once the Owl is connected to power and your computer you may set it down in a spot that will
+be able to easily see/hear everyone participating in the meeting physically. If you're hosting the meeting you also want to verify that the Owl is being used as the
+audio and video input to the call.

docs/General/Presentations/database.md

@@ -0,0 +1,38 @@
+# Presentations Database
+
+This page contains links to previously created presentations and is intended to support the creation of future presentations.
+
+## 2024 Presentations
+
+**Radiomics and Pharmacogenomics: From Research To Clinic** ([Slide Deck](https://docs.google.com/presentation/d/1opViHXEd1PjO7glqesinhdQfJUf4_HUQ6F-uol_hCrA/edit#slide=id.gc3323ced22_0_0))
+
+   *Joint Symposium in Cancer Biology and Ecosystem, October 2024*
+
+**Pharmacogenomics Data Analysis** ([Slide Decks](https://drive.google.com/drive/folders/1TO5YAc3wJpZWoMdR1EISqGa5CWyb53rm?usp=drive_link))
+
+   *Canadian Bioinformatics Workshop, October 2024*
+
+**An Open Science Approach to Computational Pharmacogenomics** ([Slide Deck](https://docs.google.com/presentation/d/1mR4wYLbbRcaz6ZVBCZyXhtMnvn-XDBcuL1L_PB_TmeQ/edit?usp=sharing))
+
+   *RECOMB/ISCB Regulatory & Systems Genomics/DREAM conference, October 2024*
+
+**An Open Science Approach to Drug Response Prediction in Sarcoma** ([Slide Deck](https://docs.google.com/presentation/d/15n0wnM5_33EJBr5580JchIyt_bZB6BeRwEtpJVe2RHI/edit#slide=id.gc3323ced22_0_0))
+
+   *2024 NLMSF-SPAGN International LMS Research Roundtable, September 2024*
+
+**Development of Chromatin Accessibility Liquid Biopsy Biomarkers for Breast Cancer Drug Response Prediction**
+([Slide Deck](https://docs.google.com/presentation/d/16fTvMb6qgN3fL1nlzBLlS8HnQdWB1XBTWpckxBjFAcc/edit?usp=sharing))
+
+   *2024 Collaborative Breast Research Internal Award, June 2024*
+
+**Hallmarks of Drug Response Models: A Qualitative Framework to Evaluate Multivariable Predictive Biomarkers** ([Slide Deck](https://docs.google.com/presentation/d/12_qdW8u5jGVSvAJ22-kaorGUlcPN6C44-HTWMG4Lh-w/edit#slide=id.p1))
+
+   *AACR Annual Meeting - San Diego, April 2024*
+
+**AI for Clinical Trials** ([Slide Deck](https://docs.google.com/presentation/d/18R2ZfBfW_gfx0Yti3GB5J46vKVGOh5HIfiN-iTQ_hk4/edit#slide=id.gc3323ced22_0_0))
+
+   *Amplitude, April 2024*
+
+## Previous Presentations
+
+For presentations from 2023 and before, please visit the [BHKLab website](https://bhklab.ca/#presentations)

docs/General/Presentations/index.md

@@ -1,7 +1,41 @@
 # Presentation Standards
 
-TODO: #35 Add Presentation Standards
+## Talk Standards
+
+### Key Slides
+
+- **Title slide**: Include your name, date, affiliation, event/conference, and contact information (e.g. email). Optional: include the BHK Lab logo and others (e.g. UHN, University of Toronto, etc)
+- **Acknowledgements slide**: Include names of lab members (or can reference 'BHK Lab') and other collaborators along with your institutional affilications/funding sources (e.g. UHN, CIHR, NSERC)
+
+### Other slides
+
+- All slides should include slide numbers
+- Slide headings should be short (1-2 lines max) and descriptive
+- Use visuals whenever possible (feel free to take from existing presentations in the [database](database.md))
 
 ## Poster Standards
 
-## Talk Standards
+### Components
+
+- **Heading**: Include title, author(s) name, supervisor name (if student poster) across the top border
+- **Abstract** (optional): Brief paragraph (~250 words) outlining purpose, methods, results, and conclusions
+- **Introduction**: Background information pertinent to your project to help audience understand motivation. Outline the goal, objective(s), and hypothesis(es) of your research.
+- **Materials and Methods**: Brief outline of materials and methods used in your work, listed clearly and logically.
+- **Results**: Present data in photographic, graphical, or tabular form. Include descriptive figure titles and avoid lengthy captions. Be sure to not include abbreviations not explained in the text.
+- **Discussion**: Address results and describe relevance to objective(s) and hypothesis(es).
+- **Conclusions**: Stated clearly and concisely, addressing project objectives and stating overall significance.
+- **References**: All references (publications)
+- **Acknowledgements**: Any key lab members, collaborators, and funding sources.
+
+### Text Sizing
+
+Size of lettering must be large enough to be legible from approximately 2m. Use a clear and simple font between 18 point and 30 point in size. We recommend the following for Arial:
+
+- 18 point: best viewed at 1m (for figure titles, legends, acknowledgements, etc)
+- 24 point: best viewed at 2m (for main text)
+- 30 point: best viewed at 3m (for section headings)
+
+### Suggestions
+
+- Avoid overloading with text, use bullet points where possible
+- Whenever appropriate, use clear diagrams, figures, and tables (e.g. materials and methods)

docs/General/Presentations/tools.md

@@ -1,10 +1,38 @@
 # Presentation Tools
 
-TODO: Add descriptions of presentation tools
-
-- Google Sheets
-- Templates
-- Miro
-- Flaticon
-- Biorender
-- Slido
+This page describes standards, tools, and resources for creating presentations for the lab.
+
+**Google Sheets**
+
+All external presentations (conferences, workshops, external working groups), should be created on Google Sheets directly by or shared to the `[email protected]` account.
+
+Internal presentations, such as journal clubs, should also be created on Google Sheets. *Link Lab Meeting and Journal Club pages here.
+
+
+**Templates**
+
+Several slide templates have already been developed for the lab: 
+
+- [BHKLab Internal Presentations Template](https://docs.google.com/presentation/d/1GRdR3ExBVbXwgmjkHBp82i3x_mdQZPzJNHsEz1LiYWk/edit)
+- [BHKLab External Presentations Template](https://docs.google.com/presentation/d/1B-iTfzHvVSOD9fW80NZz14ct6HENHWOgTxU8C673TmY/edit)
+
+
+
+**Miro**
+
+[Miro](https://miro.com/login/) is a collaborative white board platform that enables simple diagram and multi-figure panel creation for presentations and/or manuscripts. For diagrams that will be used and updated by others in the lab, please request a Miro Board be created via the BHK Lab Miro account.
+
+
+**Images and Icons**
+
+The following are open-source biological imaging databases and platforms. The BHK Lab holds a premium Flaticon account. If Biorender and/or BioArt are used, please remember to add them to the acknowledgements.
+
+- [Flaticon](https://www.flaticon.com/)
+- [Biorender](https://www.biorender.com/)
+- [BioArt](https://bioart.niaid.nih.gov/)
+
+
+
+**Slido**
+
+[Slido](https://www.slido.com/) is an interactive polling platform that can be easily integrated into Google Sheets. We recommend using this platform to improve engagement in presentations, particularly workshops or other relevant use cases.

docs/contributing/adding_content.md

@@ -52,14 +52,15 @@ $ git checkout -b jjjermiah/adding-getting-started-page
 If you already have a named branch, you can switch to it with the following command:
 
 ```console
-git switch jjjermiah/adding-getting-started-page
+git switch <branch-name>
+$ git switch jjjermiah/adding-getting-started-page
 ```
 
 ### 2. Add your new content to the `docs` directory
 
 ??? question "How do I know where to create my file?"
 
-    This will create an empty Markdown file called `my_new_page.md` in the `docs/onboarding` directory.
+    The command below will create an empty Markdown file called `my_new_page.md` in the `docs/onboarding` directory.
     The relative path to the `docs` directory, will be the link to your new page. <br>
     i.e the link to your new page will be `<website-url>/handbook/onboarding/my_new_page/`
 
@@ -71,27 +72,46 @@ $ touch docs/onboarding/my_new_page.md
 You should now see a new file at `docs/onboarding/my_new_page.md`.
 ```
 
-To learn more about how to actually write content, see the [HandBook MkDocs Page][mkdocs] and
+To learn more about how to actually write content, see the [Handbook MkDocs Page][mkdocs] and
 [Handbook Markdown page][markdown].
 
 ### 3. Preview your changes
 
 The following is a [`pixi task`](https://pixi.sh/latest/features/advanced_tasks/)
-that will start a local server and preview the documentation at `http://localhost:8000`.
+that will start a local server and preview the documentation at `http://localhost:8001` (aka `http://127.0.0.1:8001`).
 
 ```console
 $ pixi run serve
 INFO    -  Building documentation...
 INFO    -  Cleaning site directory
 ...
-INFO    -  [08:55:05] Serving on http://127.0.0.1:8000/handbook/
+INFO    -  [08:55:05] Serving on http://127.0.0.1:8001/handbook/
 ```
 
-You should see your changes appear at `http://127.0.0.1:8000/handbook/onboarding/my_new_page/`
+You should see your changes appear at `http://127.0.0.1:8001/handbook/onboarding/my_new_page/`
+
+!!! tip
+    You can set the handbook website to automatically open in your default
+    browser by using the `-o` flag:
+
+    ```sh
+    pixi run serve -o
+    ```
+
+!!! note "About the port number"
+    By default, we host the local site on port `8001` because it is more likely
+    to be unused and available for the local server to use. In the case that you
+    would like to manually specify a different port (e.g. if it's in use by
+    something else), you can use the `-a` flag after `pixi run serve`.
+
+    For example, to run on port `1234`:
+    ```sh
+    pixi run serve -a localhost:1234
+    ```
 
 ### 4. Commit and push your changes to your branch
 
-```console
+```sh
 git add .
 git commit -m "Add new getting started page"
 git push --set-upstream origin jjjermiah/adding-getting-started-page

docs/contributing/conventional_commits.md

@@ -1,6 +1,6 @@
-# [Convential Commits](#convential-commits)
+# [Conventional Commits](#conventional-commits)
 
-We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification for commit messages. This helps us automate our release process and keep our commit history clean. 
+We follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification for commit messages. This helps us automate our release process and keep our commit history clean.
 
 This style is mandatory for [merging pull requests][modify-the-commit-message-as-needed] on the handbook, but are recommended for all commits.
 
@@ -30,14 +30,13 @@ The `<scope>` of the header is optional and provides context for where the chang
 - `perf`: A code change that improves performance.
 - `test`: Changes to the test framework.
 - `build`: Changes to the build process or tools.
-- `ci`: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
-- `chore`: Other changes that don't modify src or test files
+- `ci`: Changes to CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs).
+- `chore`: Other changes that don't modify src or test files.
 
 Other types may be defined per project, but these are the most common.
 
-
 ## Sources
 
 1. [Angular Commit Format Reference Sheet - Brian Clements](https://gist.github.com/brianclements/841ea7bffdb01346392c)
 2. [Origin of Angular Commit Style - AngularJS Git Commit Guidelines](https://github.com/angular/angular.js/blob/master/DEVELOPERS.md#commits)
-3. [Py-Pkgs tutorial - Automatic version bumping using Angular Commit Style](https://py-pkgs.org/en/latest/development/commit-guidelines.html)
+3. [Py-Pkgs tutorial - Automatic version bumping using Angular Commit Style](https://py-pkgs.org/en/latest/development/commit-guidelines.html)

docs/contributing/merging_pr.md

@@ -27,7 +27,7 @@ This is called a **Merge Commit**.
   <figcaption>Merge commit example</figcaption>
 </figure>
 
-We will be using the **Squash Merge** strategy for merging pull requests.
+We use the **Squash Merge** strategy for merging pull requests to the lab handbook.
 
 Squash merges are a way to combine multiple commits into a single commit.
 Instead of seeing all the author's individual commits in the main branch's
@@ -68,15 +68,20 @@ Feel free to modify the body of the commit message to include only the relevant
 
 !!! note
 
-    Only the PR Title needs to follow the [Conventional Commits][convential-commits] specification.
+    Only the PR Title needs to follow the [Conventional Commits](conventional_commits.md) specification.
     The commit message body can be modified to include any relevant commits.
 
 ![better_pr](images/better_pr_body.png){: style="height:100%;width:100%"}
 
 ### Verify GitHub Pages Deployment
 
 After merging the pull request, the changes will be deployed to GitHub Pages.
-Check the website at `https://bhklab.github.io/handbook/` to verify that the changes are correct.
+Check the website at [`https://bhklab.github.io/handbook/`](https://bhklab.github.io/handbook/)
+to verify that the changes are correct.
+
+!!!note
+    To view the latest merged PR changes, ensure you are on the `dev` version of
+    the site. The version dropdown selector is located next to the site title.
 
 ### Delete the branch
 

docs/contributing/release_deployment.md

@@ -36,10 +36,10 @@ the latest version of the website.
 
 ## Releases and Versioned Documentation
 
-We leverage both [release-please](https://github.com/googleapis/release-please)
-and `mike` to automate the release process and manage versioned documentation,
-making it easier to maintain version control, changelogs, and multiple
-documentation versions.
+We leverage both [`release-please`](https://github.com/googleapis/release-please)
+and [`mike`](https://github.com/jimporter/mike) to automate the release process
+and manage versioned documentation, making it easier to maintain version control,
+changelogs, and multiple documentation versions.
 
 ### How Releases Work
 
@@ -52,7 +52,7 @@ You can view the release automation action at
 
 Key aspects of this combined approach include:
 
-- **Automated Release Creation with release-please**: The tool automatically
+- **Automated Release Creation with `release-please`**: The tool automatically
    generates a release with changelogs and updates the version number based
    on the changes merged into `main`.
 - **Dynamic Pull Request Updates**: If additional changes are pushed to the
@@ -62,14 +62,13 @@ Key aspects of this combined approach include:
 - **Controlled Release Process**: Maintainers can merge changes into the
   release PR only when they are ready to publish a new version, giving them
   full control over the timing of each release.
-- **Versioned Documentation with mike**: Once a new release is prepared,
+- **Versioned Documentation with `mike`**: Once a new release is prepared,
   `mike` is used to manage and deploy versioned documentation. This allows us
   to provide a separate set of documentation for each release, maintaining
   historical versions accessible on the website.
 
 This automated approach ensures consistency, reduces manual effort, and allows
 users to access documentation relevant to any specific version of the project.
-required to manage releases.
 
 ### Manual Release Process
 

docs/contributing/submitting_issues.md

@@ -7,7 +7,7 @@ the documentation, you can submit an issue directly on our GitHub repository.
 We have a set of pre-defined issue templates to help categorize and address
 your concerns efficiently.
 
-link: [Submit and view issues](https://github.com/bhklab/handbook/issues)
+Link: [Submit and view issues](https://github.com/bhklab/handbook/issues)
 
 ## Available Issue Templates
 
@@ -44,7 +44,7 @@ When creating a new issue, you will be presented with the following options:
 
 1. Go to the GitHub repository and navigate to the "Issues" tab.
 2. Click on the "New Issue" button.
-3. Select the appropriate issue template from the list
+3. Select the appropriate issue template from the list.
 4. Fill out the template, providing as much detail as possible to help us
    understand and address your issue.
 5. Submit the issue.
@@ -60,5 +60,3 @@ also select **Open a blank issue** to describe your concern freely.
   section, page, or example, include links and screenshots to provide context.
 - **Suggest Solutions**: If you have an idea on how to fix or improve the
   issue, let us know! Your suggestions can help expedite the process.
-
-Your feedback is invaluable, and we