Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestions for general and QC improvements #27

Open
bswhite opened this issue Sep 12, 2024 · 0 comments
Open

Suggestions for general and QC improvements #27

bswhite opened this issue Sep 12, 2024 · 0 comments
Assignees

Comments

@bswhite
Copy link
Collaborator

bswhite commented Sep 12, 2024

Dan, would you please address these comments, insofar as they are applicable to sections you taught. We will all be doing the same. These are just general comments -- I didn't see any that were specifically applicable to your sections.

General (All – for your respective sections)

  1. Few slides before each section to give a conceptual overview (Aug). Sue – add your figure to each section, highlighting where we are at.
  2. A deeper higher-level understanding would be great for each step, i.e., differences between each normalization method. (Aug)
  3. Similar comment specifically about deconvolution: I was a bit confused as to why we were doing each step of deconvolution. (Aug)
  4. Another thing that you did well but could do even more of is summarizing before we switch to a new topic or instructor! To do noted by Dan/Sue/Brian: let’s revisit our objectives and take aways for each section. These could be more meaningful and informative.
  5. A little more description about why we are doing each step, as I have very little omics experience. (Aug)
  6. Participants would benefit more from the course if instructors provided more explanations of the science and justifications for adopting approaches or parameters where necessary (Aug).
  7. Add comments to code to consolidate what we are going to do. (Aug) Dan did this, but others didn’t.
  8. The pacing is a bit fast, mostly the explanation of the purpose of each function. I try to input these explanations into my notes. (June, Day 2)
  9. My only suggestion would be to do a little less live coding but instead have the code and explain what each line is doing more thoroughly. So we can run it line by line together and take notes on our code of parameters that can be changed and how they would change things. We did this with the live coding, but with people running into errors sometimes the learning went away to fix the code instead. To do noted by Dan/Sue/Brian: let’s copy large blocks of code from lesson plan. Don’t need theme stuff (e.g., large fonts) in live coding, but do leave this in lesson plan.
  10. I would suggest that the instructors copy the very long codes from the course material instead of typing them out. This would prevent participants from getting ahead of the instructor and waiting for the instructor to type out all the codes (Aug).

QC (All – for your respective sections, but particularly Antonis and Brian, including for Elaheh’s deconvolution section)

  1. What things in your experience usually go wrong? What should we be checking that isn’t here? Do you have to worry about cell cycle (June, Day 1)?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants