So the goals of this introductory session is to be relatively light and to help orient you in where we're going to go. And so I'm going to summarize the motivations for this series, I'm going to help you to understand where the tutorial is going, and what we're going to get out of it. And then I'm going to give you some preliminary readings, there's a number of them, five or six papers, but none of them are super-long, and they're all meant to kind of provoke you into thinking about reproducibility and your own practices.

And so I'd like you to read these before the next tutorial. So this whole tutorial series started as an April Fools' joke for the Mothur software package and the idea was, I wanted to release a package called write.paper, because I've gotten lots of emails from people saying, basically, "Write my paper for me."

I should be able to give you an SFF or FASTQ file, and you should be able to pop out an analysis that does everything I needed to do. And, I think, we agree that that's kind of silly. What's really silly is that years after I posted this as an April Fools' joke, I still got emails from people asking, "Why doesn't write.paper work?"

But this was a motivation for me and sure it was a joke at the time. But, wrapped up into this was the question of, "Well, could I write a command that would take raw data, maybe even go out to the web and pull down raw data, process it automatically, and then spit out a paper?"

And as much as we joked about this as an April Fools' joke and people said, "Ha-ha. Good one, Pat,"that's really the goal of this workshop, is to help you to write your own function, your own code, so that you can go to the command line and say, "write.paper," and it will pull down your raw data, it will manipulate it, it will analyze it, and it will pop out a Word file or a PDF that you can then submit to a journal or give to your PI, or do whatever.

And so, again, as much as this started as an April Fools' joke, it really evolved into thinking about reproducible research. I'm not going to say it's as easy as pounding out write.paper, you still have to tell the computer exactly what to do, but by telling the computer what to do, you're really telling your colleagues and potential collaborators around the world what to do when you analyzed your data and what they can do to analyze your data.

So as we go through this series of tutorials, there are going to be two reoccurring themes. First is thinking about your collaborators, and who are your collaborators? So, you, Mr. DiCaprio up here is telling you, you are the most important collaborator.

And it's a special version of you. It's the version of you that exists six months from now and current you won't have email access in six months, right? I think we can all relate to that where we've had a project, we put it to the side for a few weeks or few months, maybe even a few days, we come back to it, we're just like, "Where was I? Where was I going?"

So the second most important collaborator is your PI, your boss, right? That, they need to know how you have been analyzing and working with your data. Someday, you may leave the lab. You might graduate, you might get a job, you might go on to greener pastures, and your PI's going to be stuck answering all the emails that come in, and they need to understand what's going on.

They need to understand how you've organized things, how you've done your analysis, why you did different things in your analysis. And so you need to make these things transparent to your PI as much as possible. And of course, the third most important collaborator is your future collaborators, right? People who will read this paper, and as I said earlier, will want a riff-off of the work you did to expand it for their own data sets or their own questions.

The second theme that I want to focus on is that reproducible research is a positive thing. This is not meant to be "gotcha" science. Too much of the discussion about reproducibility has really turned into "gotcha" science, where it's, "Aha!" You know, the Superman poses. It's not reproducible.

It's not real. It's garbage science. It's junk. But instead, to think about reproducible research practices as being preventative medicine, right? If we can make sure that our code is reproducible, and that we're using good practices, then we will prevent…we won't necessarily avoid future problems but we'll prevent a lot of problems down the road because it will be easier to track down those problems if they occur.

Right? We'll be more transparent so others could help to improve the work we're doing. We'll have a better idea of what we're looking at months from now when we come back and scratch our heads and say, "How did I make that figure again?" Well, the tools that you're going to get out of this series of tutorials will help you to do that, and in that way, reproducible research methods are considered by many to be preventative medicine.

So as I said earlier when we were looking at the website, we'll cover a number of tools throughout this tutorial series and none of these are really specific to microbiome data. I have used these tools in a wide variety of projects I've worked on that have had nothing to do with microbiome data.

And these five areas really focus on some of the bigger themes that we're going to be diving into as we think about reproducibility. So the first is documentation, and we're going to use a few tools like markdown, Rmarkdown, R, Make, Git, thinking about organization, that organization is very important because if you can't find something, then it's really hard to reproduce it.

So we'll use tools like bash, we'll talk about using high-performance computer clusters, we'll also talk about using Git Version Control as a tool for helping us with organization. We'll also talk about automation. I don't know about you but whenever I get involved in manually curating steps, all sorts of weird things start happening that I perhaps can't reproduce.

And so if we could automate things, then we can overcome a lot of these problems. And so to that, we'll talk about using Bash, R, and Make. Transparency is also a big issue when it comes to thinking about reproducible research. That, we need to be transparent with our external collaborators, with our PI, with ourself, with those out there in the world about how we did our work.

And so tools like ORCID iDs, FigShare, other databases using Git, GitHub, open-source licensing, are all going to be really important as we think about improving the transparency of our data analysis to, hopefully, make it more collaborative. And so that other final issue of collaboration is really critical because I don't want to just do research that begins and ends with me.

I want it to have an impact on others, right? I want people to think of my results as something that they can build off of. But also all the hard work I went through to process my data, to analyze my data, I want that to be valuable to others as well so that they can go off and take my tools that I have developed to analyze my data, to analyze their data.

There aren't many feelings better than getting an email from somebody out of the blue that say, "Hey, thanks for making your code available online. I've been struggling with this problem and I see that you solved it or you found a way to deal with it. And so now I've used it in my code and that's really helped me out."

I mean, that's what science is all about, right? Taking work from other people, riffing on it, expanding it, to advance our knowledge of the world around us. So as I mentioned earlier, we'll use a couple tools that we're not going to go super-deep on, they're important for thinking about scripting and analyzing data, but I deal with teaching these tools in other places.

And so I already talked about R, and that we have a minimalR tutorial, that if you're not familiar with R, I'd really encourage you to go through those materials. You don't need to be an R expert to make it through this series of tutorials but it will certainly help. The second is mothur. So mothur is a software package that my lab has created and maintained for analyzing 16S rRNA gene sequences.

Again, it's not critical that you know mothur. We're going to do some copying and pasting with mothur commands from the mothur MiSeq SOP. It might be worth your while to at least once go through that SOP documentation using the data that I provide in that tutorial.

So, again, it's useful to know R and mothur, but it's not critical. So, as I mentioned earlier, there's five papers that I'd like you to take a look at. They're not very long, they're typically maybe two or three pages long. And so, the first is by Francis Collins and Tabak from NIH. Francis Collins is the director of NIH and Tabak is his deputy.

And it describes their plans to enhance reproducibility. Second is an editorial by Arturo Casadevall and others which reports a framework for improving the quality of research in the biological sciences. This is an outgrowth of an American Academy for Microbiology report dealing with reproducibility in microbiology.

And so it's a very relevant document for those of us in microbiology because this tells us what other microbiologists, generally senior microbiologists, are thinking about reproducibility in our field. Next is an editorial by Jacques Ravel and Eric Wommack published in Microbiome. It was published several years ago titled "All Hail Reproducibility in Microbiome Research."

In here, they lay out several papers that had recently been published that were making use of reproducibility tools. And so it's a very useful paper for thinking, again, about people within our field and seeing how they're thinking about reproducibility. The fourth paper is more nuts and bolts and practical, a paper by Noble, which is "A Quick Guide to Organizing Computational Biology Projects,"it's perhaps the most boring title ever, or it sounds like the worst paper ever, but you read it and it's really rich and really gets you thinking about how we organize our projects.

And these are concepts that we'll come back to later in the workshop. And finally, a paper that I think is just awesome for its humility is a paper by Garijo et al., out of the Bourne Lab. Bourne is a leader in bioinformatics. He was, I think, some type of director at NIH, and so they published a paper looking at the tuberculosis drugome several years ago.

And then Bourne issued a challenge and said, "I'd love for people to come back and try to reproduce the work we did." And so this manuscript, Garijo et al., is a reporting of what happened when people went back and tried to reproduce their work. I think a lot of us cringe at the prospect of thinking of somebody coming back and reproducing our work.

But, again, I tip my hat to Bourne and his colleagues for doing the experiment and seeing where the bottlenecks were. And so we'll come back and talk about all of these papers as we go through the future tutorials. And so it'd be great right now before the next tutorial to read these, to get a sense, again, of where we are in science in general, and microbiology in particular.

Okay. So here's some homework for you to think about and I think these would be great discussion items for your next lab meeting or if you're interested in area of research ethics or, I mean, just your own research, and these are questions that we all grapple with, I think, is that, what about your current data analysis pipelines makes you feel uncomfortable?

Perhaps me talking here has maybe dusted off a few recesses of your memory that make you a little bit stressed out. Are there areas of how you do data analysis, the reproducibility of that data analysis, that make you a little bit nervous? So the second question that is, "If you left your project for six months, how difficult would it be to restart?"

I have a lot of friends in ecology and they commonly go off for fieldwork for maybe months at a time and they're in remote areas where they can't work on a computer, and they come back. How do they get going again? How difficult would that be for you? How difficult would it be for you if you go to a conference for a week and come back and need to get going again?

And finally, how easily is your PI able to interact with your analysis? Are they truly a collaborator or are they a receiver of the analysis and the text you give them?

Is there an interaction? And is it possible for them to interact with you? Maybe you don't want them to, but still the question needs to be asked of, "How easily is your PI able to interact with your analysis?" And there's no good or right answers to these questions. They're questions to motivate your thinking and get you to start to grapple with issues that we're going to be encountering as it comes to working with data and thinking about how we can make our data more reproducible and hopefully, more robust.

Well, thanks again for hanging out with me as I introduced the Riffomonas Project in this Reproducible Research tutorial series. Like I said, it's a project I'm really excited to share with you and to be able to show you how my lab and I strive to make our data analysis more reproducible. It will seem like a lot of content over the next few weeks. What I want to impress upon you, however, is that it's important and okay to take incremental steps to making your work gradually more reproducible.

I think it's unreasonable to expect you to incorporate everything we talk about over these next series of tutorials into your first project or that you should somehow go back and retrofit current or previous projects. Instead, I'll be giving you tools that you can gradually bring to your projects to improve your overall practices over multiple projects.

The next tutorial will define reproducibility and replicability and explore the factors that impede reproducibility and replicability of research. The content of the next tutorial won't be too technical. My goal is to ease us into the more sophisticated and technical aspects of how we make our research more reproducible. A lot of the problems we face with reproducibility, frankly, are human problems where our own behaviors and practices get in the way of our progress.

I think you and the rest of your lab, including your PI, will get a lot out of the next tutorial, even if they aren't actively doing data analysis. So, so long, and I hope you'll join me next time as we dive deeper into this series of tutorials on making our data analysis more reproducible. ♪ [music] ♪