Repository navigation
Community Feedback Survey #2 - Responses #228
Locked
UMGCCCFCSR
started this conversation in
Ideas
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Thanks to everyone who completed our Community Feedback Survey # 2, since this is our first year offering this course, we are especially grateful for the feedback. Since the survey is anonymous, this post is intended to provide a means to answer any questions that were asked, as well as provide our thoughts on some of the suggestions. Best Wishes- David.
Summarizing a total of 27 responses, those who completed the survey thought that providing comprehensive material, in a structured, gradual manner, available both via website and recordings on-demand was helpful.
Summarizing a total of 21 responses, those who completed the survey mentioned the general improvement of their R skills pre-course, being able to apply what learned to their own projects, how to use Positron (instead of Rstudio), visualizing data, as well as understanding what computationally goes on behind the curtain for flow cytometry analysis. A few also enjoyed learning how to write functions (although given areas to be improved comments that opinion is not universal).
Summarizing the 18 responses, main concerns and suggestions that were raised:
On our end, we also agree, since it now is taking us 1-2 full weekends worth of effort to write the course material (compared to earlier in the course where it was 1 weekend day's worth of effort). Our main reason in trying to get all the material out as quickly as possible was due to the possibility of after graduation David getting hired by industry, and the course coming to a hard stop (due to intellectual property sign-offs, etc.). Since the timeline has since expanded, we are amenable spreading the content out over several weekly topics, but are balancing the trade-off that will mean additional weeks overall, pushing into December? Thus the survey.
The easiest way to access the course material is via our website. You need to look at the left sidebar, and it will show you links for the individual weeks. On ending up on the weekly page, you can also see the slide deck as well as the embedded YouTube video.
In general, most people don't try to follow along within the slide presentation. Instead, they will have the website open in one tab, and use the copy-paste code option to paste this into their Positron/Rstudio session. The format is not directly amenable to circling between YouTube livestream and Positron/Rstudio since content is being covered in an hour, but for the recording this method also works. Ultimately, do what is best for your way of learning, as that is what matters most.
Great question! Turns out, flowWorkspace packages arcsinh integrates the co-factor in differently compared to what the flowCore implementation, where you have more fine-tuned control (5, 10, etc). Since it doesn't plug in directly, this is confusing. I am planning to circle back and see if I can show the flowCore implementation within our typical workflow, in which case we will update the documentation for Week 7, as this is the one the literature uses more often.
I like the idea, we would likely need to do these either via Zoom or the Cytometry Discords live chat feature, but we could likely mix a bit of social with a bit of troubleshooting. Finding a time that works for everyone would be the fun part.
If you feel like Week 9 was a jump in course complexity, you are not alone. However, this is partly intentional on our part, since being able to implement functions is essential to the spectral flow cytometry workflow, as well as being able to reliably run the unsupervised algorithms when documentation is lacking. There are over 20 all-in-one analysis R packages that we have encountered, most of them are broken. We don't want your analysis to be at the mercy of the maintainer responding to your issue or question
Several people brought up the R package bugs. We have unfortunately had to find workarounds at two points in the course due to unexpected changes that package maintainers have implemented (first for ggplot2 moving to version 4, causing ggcyto and flowGate to break), and more recently BiocGenerics changes causing ggcyto and flowGate to break again.
The packages we included for use in the course are supposed to be stable packages, that have wide-community buy in. I have intentionally steered far clear of R packages that don't have community buy in, and are horrid buggy messes. But it is the nature of open-source packages to change with time, which means they will occasionally break. As much as possible, I try to provide temporary fixes when the packages we are using in the course stop working. But their implementation into the overall package is still reliant on the package maintainers bringing in those changes.
At the end of the day however, given the nature of a job in a cytometry core facility, I am not going to be able to bug-fix before the weekend. So this is an area that attempting to do everything on my own is resulting in the ball being dropped.
If you are still having an issue with broken packages, don't suffer the issue in silence, post about it on our Discussions Page, and sporadically re-comment. I may miss it the first time, if we actively have a cell sorter melting down and four users with issues, but not if there is repeated recent activity.
Both in-person and online, some learners feel trapped in a copy-paste cycle, where they copy the code, paste, run it, but don't feel like they are actually learning, vs. going through the motions. I just want to say, we all feel like this at part of our journey, so this is not just you. One thing I would recommend is to slow down. You are not obligated to maintain the same pace as the course, you can circle back, repeat, and try again and still get to the destination on your own time. This is a ultra-marathon, not a sprint, and it's perfectly acceptable to walk the hills and eat all the aid station food on the journey.
A couple additional suggestions as far as ways to try to minimize the disconnect. Try to implement what is being covered with your own data. Instead of copy and pasting bulk code lines, type them out, run them, and then run the output variables as their own line to see what kind of object was produced. Viewing the intermediates instead of just the final outputs is useful in this regard of trying to understand why individual lines of code are run where they are.
So far, we are in the portion of the course where we are working with smaller datasets, since we are trying to build out from the basics. In terms of methods for analyzing larger-than-memory datasets, these are slated for later on, since not everyone falls into those use cases. However, since we encounter these issues frequently in our own research (and when mining the core-acquired files for auto fluorescence signatures), you will get these workflows later on.
Noted! We are in a spectral heavy section, but we will be out of it in a couple weeks, at which point the analytical steps converge back together again. I also still need to circle back to the compensation portion, given its importance to conventional. I however am struggling to understand how it is implemented behind the scenes in a GatingSet, which slowed the initial writing as I need time to dig in to the code behind the scenes to be able to better explain it. Similarly, AutoSpill although originally implemented in R, has become abandon-ware and not working for most computer operating systems. I was working on bug fixes in January, but haven't had time to circle back. But still on my radar.
I can likely provide additional hands-on-practice, troubleshooting exercises. But they need additional time to write, which finding time has been the struggle for this summer stretch. But I can likely accomodate, so will see what can be done.
Having streamlined code that can be rapidly implemented for each section as part of a pipeline could be something that might be useful. My main concern is that learners would reach for this first trying to speed-run the process. I could likely implement something ala an additional .R file containing only relevant code on a per week basis, but will likely be after the course completes, and be more in the clean-up/long-term maintenance phase if we are being realistic given current schedule overload at work.
I apologize, the homeworks /pull-request section is where the ball has been most dropped at this point. This is mainly due to pulling 80-hour weeks at the core, and weekends ending up in course writing. Not sure when I will manage to get to the backlog. Additionally, we have the issue of issues with the pull-request merge conflicts.
So the weekly emails go out as a mail merge, which takes the list of emails, and sends them out as individual emails to your respective email accounts. This approach works for the vast majority of everyone. The issue, is certain institutions email servers flag this approach as spam, and consequently nothing arrives on your end. This is particularly case for the Moffitt and Moderna people who signed up, I constantly get admin blocked your email bouncebacks.
I have been reposting the emails on the Discussions Forum, you can also see the list of prior emails in our Announcements tab on the main website.
All reactions