Transcript#
This transcript was generated automatically and may contain errors.
I would love to introduce you today to not only my Posit co-host Isabella Velazquez. Isabella, would you like to say hello? Hi everyone! Yes, and also special Posit co-host guest today, Rachel is here. Rachel, you want to say hi? Hey, I'm just hanging out. I just happened to not have a meeting at this time, so I'm like, I'm going to jump in. If you don't know Rachel, Rachel is the person who many years ago started the Data Science Hangout, and she's the reason pretty much that the domino effect of all of us being here happened. And of course, our lab manager for today, we have Ella Kaye. Ella, would you like to introduce yourself?
Hello? Yes. Hi, I'm Ella. Professionally, I am a senior research software engineer at the University of Birmingham, which is taking me some getting used to because I've only been there for less than a month. Very excited to be there. I work on Base R and in particular trying to get people to contribute to Base R. So this is very much in my wheelhouse today and delighted for the opportunity to speak on this subject and delighted that so many of you are here. Thank you so much Libby and Isabella for inviting me.
Well, we are super excited to talk about this. I don't know about everybody else, but I learned Base R first. It's all I learned. I learned it in undergrad in university and I did not learn the tidyverse until like 2021. I was mostly grad school, graduated working in my first day at a job. So I would love to hear from everybody in the chat your path through R. Are you a Base R girly? Do you like me think in Base R and then have to translate that actively into something else before you type it? Because I often find myself doing that even after years of teaching tidyverse.
What is Base R vs tidyverse?
So I have for an icebreaker here today some R code and Libby warned me when prepping for this that some folks might not even be quite familiar with the distinction between Base R and tidyverse and might not think that they know Base R when maybe they do know more Base R than they think they do. So we decided to get started with a what's Base R, what's tidyverse. So here is a very short R script which mixes Base R and tidyverse. So let's get started with what's Base R here and what's tidyverse. So I would love to get some feedback from the chat in like what do you recognize as Base R and what do you recognize as tidyverse? Because I have done this to look like tidyverse code, but there is some sneaky Base R sneaking in.
Josh says R library mean C all Base R functions. Library function, mean function and the C function which stands for combine, I believe. It does. I will let you answer that, but I think Josh has it.
Yeah, there's more though. There are more. What else are we missing? What else in there is Base R?
So I snuck in a couple more bits of Base R that might be hard to spot, particularly if people aren't familiar with these relatively recent additions to Base R. One of them is penguins. If you're familiar with the penguins dataset from Palmer Penguins, as of R 4.5, the penguins data is now in Base R. There is no library Palmer Penguins here. This penguins is coming to you courtesy of Base R. And another thing that is might not recognize immediately as Base R, but these color names are built into Base R. So the ability to name a color and have that plotted, the ability to have it as a hex, and again, another relatively new addition is the ability to specify a three digit hex. This was new in R 4.3, I believe.
I've been a little bit sneaky here in my choice of what Base R to add to here because I am highlighting here a couple of contributions that I made. So putting penguins into Base R was something that I worked on as was three digit hexes. So yeah, folks contribute to Base R and the language evolves and changes and it keeps doing so. And these are some recent additions.
So yeah, folks contribute to Base R and the language evolves and changes and it keeps doing so. And these are some recent additions.
That's so exciting. Thank you, Ella. Everybody say thank you, Ella, for making penguins in Base R a thing. But we will also point out that Jeff said, what type of pipe is that? Well, that is the native pipe in R, but that's just the font that Ella's using that turns it into that triangle.
I do, because I really love typography. So yeah, so this, I was going to mention this, so thank you for reminding me that I wanted to talk about this. It's the Base R pipe, and we type it with a pipe like that, and then a greater than or equals to sign, and then that, it happened really quickly, but that put them together. I'll put it into the Discord chat in its original form before it gets transformed by the font.
It's easier for other people to see. I can change my font settings here. So I use a font called MonoVisa, and this I've got by preference of version with ligatures, but I will change that setting. And I think Fira Code is also one that turned that into. Fira Code, we'll do that for you. That's a free font.
Setting up the R dev container
I am going to do a live demo, and the thing that I'm going to live demo necessarily takes time, because we're going to talk about contributing to Base R, and we're going to do that by means of a live demo of me fixing a bug in Base R. I wasn't quite brave enough to do an outstanding bug. I'm going to take us back to a bug that existed in a previous version of R that is now fixed, and I'll talk to you when I do it about why I'm doing that bug.
So, I'm going to start by going to a GitHub link on the RDevel organization. So, this is the organization that belongs to the R Contribute Working Group, and I'll be saying more about them later. And I am going to go to RDevEnv. And what I'm going to do here is I'm going to scroll down from here, and we're going to spin up a code space by clicking this open in GitHub code spaces. And most of these settings are good, except I'm in the UK, so I'm going to choose Europe West here. We're going to create a code space, and this is going to take about two and a half to three minutes just to initialize that.
So, while we're doing that, I'm just going to talk a little bit about what do I even mean by base R and by contributing to base R. So, we had a look at a few base R functions, but really when we're talking about base R, what I mean by that is what we get when we download R. Like, if we go to rproject.org and click through to download R, what are we getting?
And it is a little bit of a fudge to call this base R because the R distribution that you download, the functions that you can run without any other calls to library is actually a collection of packages. We don't always think of them as packages because we don't have to load them with library, but there are a collection of packages, and base is one of those packages, but there are many others. So, there's base, but there's also utils and data sets and stats and a whole host of others. So, that's what we mean by base R. I'm using it to refer to that whole distribution.
And by contributing to base R, there are lots of different ways that people can do that. So, by contributing to base R, tons of different ways to do that with varying different levels of technical proficiency. So, one thing that people can do is review bugs and analyse them and comment on them. There's the Bugzilla platform for that that I'll be showing later. There is also the opportunity to fix bugs and to test proposed fixes, or even filing a bug report. But it's not all about the code. There's also documentation, so there are contributions around improving documentation for functions in base R. And then there's a whole other side of contributing to base R, which is around translations. So, all of our messages, everything that appears in the console was written in English, but there has been extraordinary work going on for a number of years to translate those messages so that those are picked up by people's locales.
Finding the stem() bug
So, we are going to fix a bug in the stem function. So, I'm going to show a script that I've got here, which shows stem. But I'm also up here, I'm in the latest release of R. I'm in R 4.5.3. But R has the Positron makes it really easy to switch between different versions of R. So, I'm going to open up a new interpreter session, and I'm going to go back to R 4.4.3, which is where this version of the bug last existed.
So, we have a vector in R. Here is stem on a vector of 2, and here is stem on a vector of 1. Hang on. No, nothing. We're not seeing anything, right? There is nothing. If you do stem on a vector of 1, you don't get anything, and admittedly, it's not a great plot, but there is no reason in principle why you couldn't at least have that. And it feels weird to have a line of code where you could expect something and just for nothing to happen. So, not a life-changing change to the base R code. Stem is a bit of an anachronistic historical function anyway, but this is a kind of nice example.
So, what we're going to talk about is how we get to this, how we dig down to this problem, and how we fix it, but to do that, we need a copy of the R source code to play with. So, we don't want to go well, even if we wanted to, we can't go right to the R code itself. That's maintained and managed only by the R core team, obviously, for good reason. So, we need a copy, and the easiest place to browse a copy of it is at github.com slash rdevel r-svn. And the reason it's r-svn is because R is actually developed and version-controlled on subversion, not with Git, and not on GitHub, so this is only a mirror.
This gives us a copy of the source files, the source code files to play with and edit, but we are still missing a couple of other crucial ingredients, and one of those is the ability to build R from source. So, you've got this bunch of files. It's really just text. We need to kind of build that into R, and this has historically been a really big barrier to people contributing to R, because you can build R from source on your own computer, but it takes a lot of set-up, and it's a big hurdle. And there is a third thing we need, which is the ability to create patch files. So, sort of like a document that's going to be, you can think of equivalently to a pull request. So, it's a text file which creates your changes, which records the changes that the R core team can patch into their copy of R.
So, we need three things, and there is a place now where we can get all of those, and that is in this R dev container which I've just set up. We have this dev container, and at the moment, it's just a container. There's nothing really in it. So, we're going to walk through a tutorial to get through it.
So, I'm going to have that on one side. I'm going to have the dev container on the other side, and you're just going to see me walk through all of this. So, we're going to go in here, and we're going to go through the tutorials, and we're going to specifically go through the one on building R. And this talks us through it, and it talks us through what we've got. So, the R dev container comes with some handy things. So, it comes with some environment variables, the build directory, build here, the top source directory, and the patch directory.
And the first thing we're going to do is we're going to check out the R source code. So, instead of downloading it from a copy from Git, we're going to get these from Subversion, and there's a code to do that here. And typically, when we are working on patches and developing base R, we do that from R develop. We do that from the very latest version of the source code. And that's called the trunk. But that is not what I want, because I want to take us back in time to the last version of R that had this bug, and that was R4.4.3.
And what, not if you follow these steps. And you work in the R dev container, because the R dev container has everything you need in it. So, it's got Subversion, it's got everything we need to build R, and the steps that I'm going to talk you through, both through the building R and the developing a patch, will just show you the commands that you need to run, and those are the only ones that you will need.
So, we now have in this Subversion, this SVN directory, this is all the source code. These are all the source code files for R that we have now copied and have available to us. And then the next thing we're going to do is we're going to download the recommended packages. So, I'm going to run this line of code. The rest, other than that one change to 4.4.3, everything else is going to run. So, I'm downloading the recommended packages. So, we have things like foreign and lattice, and this is like best practice. And now we're going to change, so that's the source code, which we've put in the SVN, and now we're going to change to the build directory.
And we'll see here, this is where it is. There's nothing in here yet in this build directory, but we're making it and we're in it. And now we're going to configure the build. So, we're just going to not worry too much about what any of these lines of code are doing, other than knowing that we can just kind of copy and paste them, and they're all going to work, because we are in the ARP, you know. They're all going to work. It's just going to work, because it's exactly what we want in a live demo. It's everything just working. So, this is going to run for about a minute.
While you are voting, I am going to run the command that is going to take the longest. So, we have all these sources to it. We've got all these, the source code, and we've configured our build, and now we need to make it. So, we need to actually build R, and to do that, we run this make command, and this is going to take five to 10 minutes. Don't worry, we've got other things to talk about for five to 10 minutes, but we are going to set this going. We are going to make R, and while we are doing this, we are going to dig down and find the stem bug.
So, we know what to fix when this is all made. And to do this, I'm going to take us back into our Positron, because there are some really nice things that we can see here. So, this is a trick that folks may or may not be familiar with, but when we want to debug something, we often need to look at the source code for a function. And if you, in Positron or in RStudio, write the name of a function, but no parentheses, and click enter on that, send that to the console, there it is. This is the base R code for the stem function.
But that's actually something even nicer. This is nice in RStudio, but it's even nicer in Positron, is if you view a function, this will pick up in here. This is the graphics.R, which is the file in the base R source code that contains a stem function, and we've gone right to the stem function, and now we can see it. And we can see the definition, and we can see exactly where it is, and we can see this definition, and we can see that we're starting off by doing a bunch of checks on the arguments. And then you get this here. Dot call C underscore stem leaf. So, we found something that looks like C.
So, let's go back and check this. C underscore stem leaf, because that worked really nicely for our R function, it doesn't for C functions. Unfortunately, it's looking for an object. It does not recognize it. So, this is where we need to go back and look in the source code, but we're in a dev container, which is a version of VS code. So, we should be able to do this. C underscore stem leaf, and find it here.
So, I went control shift F, C underscore stem leaf. Unfortunately, we know that there is a bug in the current released version of the dev container where this search isn't working on the first thing. This is fixed in the dev version, but for this version, we are going to open our settings and we are going to unclick search ignore files. So, that's just like something that will be fixed in the new release.
And now, if you've done that fix, we now see it. And here we go. There are a few different functions here. The namespace and the stem.r, which is where we're calling it. Graphics.h. H is a header file. What we want is a C file, and we have it here. Stem.c. This here is our definition of C underscore stem leaf. And now this might be looking a little bit weirder because this is C code, and it's not only any C code. This is R's C API. So, even if you know some C code, some of this might look unfamiliar. And in particular, this thing, the S exp is how all our objects are stored in C.
And if we go through this, even if we've never seen R's C API before, if we look at this a little bit, we might start seeing things that look familiar, or at least we think we can get our head around. So, we're looking at the type of something. So, that seems kind of intuitive if you're familiar with types of C objects. And if it's not a real S exp, so, we're looking at something that is real so that we can start to get our heads around the kinds of things that these must be doing. And we're getting errors if they're not, and we're kind of keeping on going down, and we're doing lots more checking. There's lots more if, if, if, and then we get to the meat of something else, which is this function, stem underscore leaf.
So, this is another function here that this seems to be where the meat of the business is, in this stem underscore leaf function. So, now we can search for stem underscore leaf.
So, we've dug down, we've seen the stem function, we've seen C underscore stem leaf, and now we're looking at stem underscore leaf. And if we look here in line 60 and 61, we have found our problem. So, we might argue that this, at least for the case where you're not seeing anything for running a command like stem of two, it is because here it is baked in that if we have fewer than one argument, or less than or equal to one argument, it is just going to return false. And we are done. So, we could technically argue that this is not a bug because this was deliberate behavior that somebody in our core wrote into R at some point.
Bugzilla and the patch process
So, one good place while we're just waiting for this to finish building to look at is Bugzilla. So, I've mentioned Bugzilla a couple of times now. So, Bugzilla is bugs.R-project.org, which is the bug tracking system for R. So, this is the R's version of Bugzilla. And I've got an account in here. And this is where the bugs are. You can think of this a bit like GitHub issues, but not GitHub and not Git. You can browse. Here's browse for R, the latest bugs by various different categories. Or if you know the number of the bug, you can type it in here. And we know that well, you might not know. I know that this is bug 8934. We can see it's closed fixed. But what you want to be looking at on Bugzilla is, is this a bug that has been reported? If so, is there any discussion by any member of our core about what kind of fix they would be willing to consider?
The next thing that you would typically do, if you are following through this, is to check that the build has worked. And sometimes on RDevelop, very occasionally, it doesn't. It should always be a working version of R. I am not going to run that now. Because this is a tagged release of R. We definitely know that this works. But this is an important command to know. Because if we, when we are making any changes, we have to run make check to check that we haven't broken R with our changes.
There is a little script built into the dev container, which is which underscore R. This is going to tell us which version of R we want to use when we do this. The version we're building ourselves or the version that is built into the dev container. In the current release of the dev container, the built-in version is R4.4.1. In the version on the devel branch of the dev container, that's now up to R4.5. Here, number two is Rdevel. As I said, we will typically be checking out Rdevel, and it therefore calls this Rdevel, although in our case, what is Rdevel is really this 4.4.3.
I'm going to do number two here. When we start an R terminal, it's going to use the version that we're building, which is in this build directory that we now have. That's R. We've got R built into our container and our development version of that. If I click down here at the bottom, R, not attached, this is going to attach R, and it is going to give us a familiar-looking R console. Let's just check this. Stem of two on the version that we have is not working. Nothing is happening.
Stem with one argument, which in this case, I've made it two, and the reason I've always done this is because that was the version that was in the original bug report. Let's see what happens. If we go and play with the R source code, let us comment out these two lines of code.
So I have deleted two lines of the C source of the R source code, only in my local copy, only in this dev container. But we are now going to go back to our terminal. We're going to quit out of R because we now have to rebuild R. And we do that by running make again. And thankfully this time it's not going to take five to 10 minutes because it only changes the things that were changed. So that was pretty quick. So now let us reattach R.
And this will be our devel version because that's what we said we wanted, the one based on our source code. And now let's do stem of two. We have stem of two. Hooray. We fixed R. We fixed R in the R source code, but only in the dev container.
So the next thing that we would do is run make check. So we're going to let that run for about three minutes. This always takes the same amount of time. But while we are running make check to check that taking out those two lines of the source code didn't break anything, we are going to look at another part of the tutorial.
So we are going to do that in a second. Are there any questions while we are waiting for the check to happen? It's scientific proof that if something has never gone wrong before, it will go wrong when you're live coding. But thanks to my keyboard and not the dev container and not R or anything like that. So we're running this make check and it's checking and we're seeing lots of okays. So this is encouraging. So it goes through and it tests all its examples.
Like I would be very surprised if taking out those two lines of R code broke anything. But you still have to go through this process. And I have worked on bugs that I did not expect to break things that have broken things.
We are going to talk about this creating a patch file. So what we're going to do is create something that's good. It's a diff file. So these kind of things you might be familiar with the appearance of them if you've ever used Git and seen those differences.
But when we started this, I said that we had these three different kind of environment variables built in. So we have been working in the build directory. That was where we were running make and make check and the like. So the first thing we are going to do when we have our console back is we are going to go back, change directory back into the source directory. And this kind of to answer the earlier question about SVN, this is the only other SVN command that we are going to use. So this is the SVN command. It's going to create a diff. So we'll look for anything that's different. And it's going to send this into the patch diff that we created and which we can see in here is the one that we called patches.
Okay. So we're going to change back. So we're currently in the build directory. So we're going to copy and paste that and we're going to go back to now we're in our source directory, the source code files. And we're going to run this SVN command to create a diff and we're going to put that output into a file in the patch directory. And we're not going to call it this, because as they advise, you want to name it something that's related to the bug number and give it some kind of descriptive name. So this is 8934. We're calling this n equals one. So and that's a dot diff file. So that's the extension. And we're going to run that.
And if we now look back here into our Explorer, we've got in our patches file, here it is. This is our diff file. So it's not a big diff, because we didn't change a lot. But we have a revision against our working copy, working copy against the version that was checked out. And we have deleted three lines of code. So we see that in red, you know, sort of dark red, it's hard to see. And we've got these subtract signs, because we've taken that away.
So now we have a file. But that file is still stuck in the RDEV container. So we need to get it out of the RDEV container. And the way we do that, we're going to right click on it, or whatever you need to do, or whatever operating system you are to get off that menu. And we're just gonna, we're gonna download it.
So you named it 8934. Was that from Bugzilla? That is Bugzilla. Yeah. Okay, fantastic. That was the name of the bug that was that you'd already looked up, but if it didn't exist yet, it we wouldn't have a bug number. Exactly. And you would definitely want to be raising a bug and getting some buy in from Arcore before you went about creating a patch.
But also, while we're on the subject of how we find good first issues, the way that I came about this, and went to work on it was through, I mentioned under the RDEVEL organization, the RDEV day. So these are issues that kind of get handpicked as like, good contributor issues. And this one is now closed. But if I call look for stem in the closed issues, that this was an issue that was pulled out for an RDEVEL day, which I'll be talking about very, very soon, that says a little bit more about it and some discussion about how that fix is going to go.
But I've downloaded that, and we should now have on my computer this fix. If we were now working on this, and we went back to our bugzilla, we would have an option to add an attachment here, which would be essentially like a manual way of submitting a pull request. So that is what the our core team could take and then patch into into beta, which is sort of what happened in this case.
Although, actually, in this case, the fix that we made during the RDEV day was to the vertical bar alignment issue. And this n equals one issue was such a small one that somebody from our core team actually just went in and fixed it. And just changed it. No need to submit.
How penguins got into Base R
This was a completely and utterly different process. So when I got in touch with the authors of Palmer penguins, it's like, hey, wouldn't it be great if this was in base R? And they said, yes, it would be. So we had the R project sprint coming up. So there was some R core people there. So I had a chat with some people from our core about whether they would like that. And they said that they were happy to. So I did some work on preparing that. And actually, I do have a link for that.
Because I have put onto Zenodo, as part of the prep for that patch, I had put onto Zenodo all the files that changed. But like the hardest part of that part of that project was convincing our core to do it. That they wanted it because the data is available in part of the penguins. So they needed to be convinced that it was worthwhile having it in base R. And they also wanted so that the data was originally published in a plus one article. And they wanted to know that the results that were reproducible. So actually, a big part of that piece of the work was going through Kirsten Gortman's original paper and reproducing.
Getting involved with the R contributor community
So I believe, if you if you mean, like, actually, on the R core team, I believe that's about 20. I'm not 100% sure that would be my, my guess. But in terms of a community of contributors, many dozens, if not hundreds of people are making these these kind of contributions.
And so that's what I want to talk about next is getting involved. Because I'll wait to see what's kind of coming in on the discord. But I know I've spoken to people about this. And they just kind of think it's, it's not for people like me, whoever. But one of the things I want to highlight is just how very diverse a group of contributors to base R is.
Renato sort of echoed what you said. Renato said, like, it feels outside my abilities. I don't know anything about C, and I've never even made an R package. And I think that's a very common sentiment. Okay, so I want to kind of debug this in two ways. So first of all, I want you to look at this picture of people who contribute to base R and see a whole range of it. So there's a whole range of experience levels that are novice, everyone here from novice contributors, people who haven't contributed to base R before this photo was taken, through to many members of our core. People are coming from all over the world. We have a good R-Ladies representation. We have good Rainbow R representation. We have a lot of people, particularly from the global south. This was all funded. So people's travel and accommodation were funded. And if you think, oh, no, I missed that. That was three years ago. We're doing it again in September. And applications are open.
But the other, I think, part of it is that kind of feeling of not having enough experience. So just to kind of clarify the level, so you don't need to, obviously, you don't need to have contributed to base R before to make your first contribution, that would be kind of circular. But most contributors would have, like, we would expect people to have a good knowledge of R programming, be able to write functions, be able to debug functions, you might have some familiarity with writing help files. And being able to use Git or subversion or some familiarity with the idea of version control is useful. But it's, like, it's not that high a bar on our knowledge. Just, like, a reasonably good knowledge and being able to write functions will do.
There are some skills that are useful, being able to program in C can be helpful, having a knowledge of S3 or S4, knowing something about the stats method that underpin the functions in packages like stats and splines. That's all helpful. But really, the most important thing is a keenness and an interest. So there is a bit of an investment in getting started with this. So we'd like people in the contributor community who, once they've learned how to do it, want to be able to want to keep contributing.
But really, the most important thing is a keenness and an interest.
So if you take away one website, one link from today, can it be contributor.R-project.org. So this is a website for the R contributor working group, and this has, like, everything we do on it. So how you can join our Slack group, the events that we have coming up, there are tutorials and demos, and then there are a link to a whole bunch of other resources. So here, the R development guide is a great one if you want to get started contributing to R. That goes through the whole process of how to do it.
We have R contributor office hours. So these happen once a month, usually not always, but usually on the second Tuesday of the month, and usually at two different times on that day. And we've just updated this website. So if you look at this site, hopefully the times you see here will be in your local time zone. So these are the usual times on the usual days where this happens. So this is a really great place to come, and it's an office hour, so you just kind of come and chat. And you can just come and hang out and find out more about it, or you can come with specific questions or things you're interested in exploring.
But the really super exciting thing are these R Dev Days. There are four of them coming up, and there are three of them are satellites to other events. And they are different because the rencontre R, which is based off an event in France and Cascadia R in Portland, if you click through to these links, you can just sign up to go. Either in person, if you're at those events, or hybrid, and anyone can sign up to go to those. There are two bigger events, and that's one that is a satellite to the UseR conference that's happening in Warsaw, which is a one-day event in Warsaw. And then a standalone event, a three-day R Project Sprint, which is going to be a fabulous get-together of, again, like that photo I showed, everyone from novice to R core coming together for three days to really get stuck into this, contributing to Base R.
So both the UseR one and the R Project Sprint, we're taking applications for those because we want to ensure we have a good balance kind of from novice to experienced. This is actually me and Kelly Bodwin and Martin Mechler from R core, and this is actually us working on the STEM bug as it happens.
And I think that attending one of these R Dev Days will help answer some of these questions for people. So one says, I considered, yes, but not always sure what the first step is. I tried getting a Bugzilla account, but got a reply back that I should decide first, not just consider, but then I don't know how to decide before being able to poke around. Another is like, I saw a feature request for D player turned down because it was outside the scope of the package. And I kind of assumed by extension that maybe base R would similarly have a scope and that additions that I would make might be outside of it.
Yeah, that's valid. And R core like very conservative about what they've done. But you don't know. So I would say like the best places to get started are through the R contributor. Anything that the R contributor group does is like a really friendly, lovely way to get involved. So I would recommend joining the Slack group. Instructions there, coming along to an office hour. And if you are going to be in Warsaw, you don't have to go to use R to come to it. And applying for the R project sprint because that is a standalone event and there's funding as well for travel and accommodation for those three days.
The last one, since we have one minute left, was I haven't thought about contributing to base R because I thought of it as static software, unlike R packages, which are kind of always changing and are the preferred way to contribute to R. Yeah. So there are there are major release. Well, the very major release of like 4.5 point they happen every several years. But the point releases 4.4, 4.5, 4.3, those happen once a year around April. So our point 4.6 is coming out very soon. And then the patch releases happen every three months. So, yeah, R is a living, breathing language and we need contributors to keep it living and breathing.
So, yeah, R is a living, breathing language and we need contributors to keep it living and breathing.
Absolutely. And the last question that we have time for is from Brendan. Is there a similar process for contributing bug reports or fixes in R tools? If you happen to know, it looks like bugzilla is empty. Oh, is it empty? I would have said go to browse R tools. But if it's is it empty? No. Well, maybe the R tools people are just really on top of fixing all that. Possibly. Maybe there are no problems in R tools right now.
I don't know. I am also super happy to keep talking about this and answer any questions. I am going to have to hop it at the top of the hour, but I will come back and I will at some point over the next few days and be around on the Discord and really happy to keep asking and answering questions. Fantastic. Brent says use R in person only. I believe that that is correct. It is in person. I believe, yes. Particularly for novice contributors, I think we would want those people there in person. But the other two are hybrid.
All right. Thank you, everybody. This was so fun. If you are going to come to the Hangout on Thursday, I will see you there. Otherwise, I will see you on Tuesday of next week. I will be in the Discord. Thank you, Ella. This was really fun. We had fun, too. Thanks, everybody. Bye, y'all.
