Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Training stories/philosophies for training handbooks #1056
As discussed during the Instructor meeting #1009, it would be nice to develop some handbooks for instructors and workshop organizers with pedagogical/technical recommendations/checklist.
What would be the targets for you?
We thought about taking inspiration from the Carpentries handbook, linking to it for general recommendations and extending to Galaxy specific recommendation.
We started the handbook and we realized something essential is missing: training stories/philosophies
We are all giving training in a different way (own pace or step by step, using only slides/training or alternating between them, showing only Galaxy, etc), depending on many factors and how we learn it. It would be nice collect all these stories/philosophies here and we will add them in the handbooks later on. It could help instructors to identify what could fit the best for them.
I will then start with my training story/philosophy.
When I am giving a training using Galaxy (e.g. ref-based RNA-seq), I usually give a 10-20 min introduction to RNA, RNA-seq using the slides that in the transcriptomics topic.
Then I switch to the tutorial. I show the participants where to find the tutorial on the training material website. I introduce the tutorial story: explain that we want to reproduce an analysis from a paper, introduce this paper, talk about the datasets/samples we will use.
After that, I open Galaxy and I go step by step through the analysis with them:
At some point, I introduce the step and explain the purpose of the step, but let them do it by themselves.
At the end of the tutorial, I spent some time to go through again each step, asking them again why this step, what were the inputs/outputs and in which format, repeating again
Here is the way I usually give a data analysis training using Galaxy. What is your way?
Adding my training notes for Galaxy workshops.
I prefer to have workshop attendees interacting with Galaxy as much as possible during a workshop. I begin workshops with an overview of the agenda and some brief background on the Galaxy Project. I quickly move attendees over to the Galaxy instance and interactively walk through the Galaxy interface and have them register accounts.
Things to do before the workshop
Things to do the day of the workshop
First off, I really like this idea of collecting different instructor's experiences, and love hearing about other people's styles, I am still trying to find what works best in which situations and this is great!
I have a similar philosophy, I like to start off with introductory slides, but not too long, I prefer the focus to be on the hands-on part. How exactly I do the hands-on part (whether I perform each step centrally and have students follow along, or if I have them work through the manual at their own pace and walk around for some 1-on-1 questions/discussions- depends heavily on the audience and topic. Some considerations:
Other random points:
EDIT: I just wanted to add that this is just a list of things I try to do and stick to, but in reality I often forget to do several of these things or things don't work out as intended/hoped or are complicated by circumstances of the day. And I am still continually revising this list and updating how I do things based on feedback from participants and tips I pick up from watching others teach etc
Love this idea! Y'all's posts were really helpful in the past days to give me some ideas and inspiration and maybe? a bit more confidence for holding my section of a workshop tuesday. It's been... a couple of years since I gave a training, so I feel incredibly unqualified to post next to y'all since y'all do this way more regularly.
But I gave a sysadmin-focused training yesterday and it was somewhat different to most of the stories here, so I'm writing this in case other admin trainers can find something useful.
Some philosophy things
Things I wish someone had reminded me of before hand
I have been working in three very different training environments.
I agree with everything said above so I will try to add some more specialised flavour. I would also like to add that I think the Galaxy Training resources are absolutely fantastic and if I get the opportunity to hold a more comprehensive course (ie more than half a day) I will structure it so that we have one quick joint introduction and then conduct a number of interactive tutorials using the training portal.
Case 1 students
Case 2 experts
Case 3 system administrators
I mostly do training sessions for Conda and Galaxy tool dev, and some of the tutorials from GTN, mainly assembly and annotation until now.
The last time we did the Conda/tool dev one, some people wanted a tool dev training, some others wanted a Conda training. So we made it in 2 (small) days: 1 for conda, then 1 for tool dev. It worked great like this, people could come to Conda only or both Conda + tool dev.
For data analysis trainings, we usually focus on one topic, for half a day, or a full day.
For all these trainings, we have well-equiped training rooms with 1 PC for 1 or 2 people. Often people come with their own laptop. We leave them free to use it: if it's for data analysis, it should just work with a modern web browser (and it's good to work in their familiar environment). For dev, they just use a ready to use virtualbox image (we have it on usb stick if needed).
A few principles I try to adopt:
We also do a full week of bioinformatics training for biology students (I don't participate to all the sessions though). Most of them have never manipulated a fastq file, but they have a good biology background.
For the hand-on we (2 trainers) usually give them access to the tutorial, give them a brief overview of the goal, and then just let them work. We keep on circulating, checking that no one is blocked, answering questions. When we get 2 or 3 times the same question, or if we see they have difficulties, we stop everyone and clarify the problem.
That's it for me.