So,
It's official. We're starting.
Hello everyone, I'm Stefanie Butland, rOpenSci's Community Manager
and I so warmly welcome you to our community call
on maintaining an R package.
I wanted to first acknowledge that everyone here is under extraordinary stresses right now
in light of the COVID-19 pandemic.
None of us knows what weights other people are carrying at this time.
It's a remarkable thing that all of us have decided to take this hour
to come together and be together as a community.
And so many of you I know as sort of warm, generous, accepting people.
And so I thank you all for taking the time to do this,
and for the next one hour of your lives, I've got your back!
And now for something completely different:
rOpenSci is a non-profit initiative, founded in 2011
by Karthik Ram, Scott Chamberlain, and Carl Boettiger.
We enable open and reproducible research by building technical infrastructure
in the form of staff- and community-contributed R software tools
and we build social infrastructure in the form of a welcoming and diverse community.
You can find our bi-weekly newsletter at news.ropensci.org.
We have a code of conduct that applies to both in-person
and online interactions, like this call today.
You can find it linked from the footer of our website
and it includes reporting and enforcement guidelines.
The session is being recorded and the video and any other resources
are going to be posted on our website at ropensci.org/commcalls
within about three business days.
I'm going to tweet from rOpenSci when those things are up.
We use a shared Google Doc, which if anyone's in there
could you please paste the link back into the zoom
so that new joiners can see this.
We typically use a Google Doc in our community calls
for collaborative note taking.
You can find that at bit.ly/ropensci-commcall-maintaining
I'd like you to add your name and your affiliation into the attendees list.
And there's a format there that you can follow because it helps me grab that information.
In this call, it's a different flavor for us, we've decided to do this as a panel discussion
as opposed to a series of talks with attendees asking questions.
And so we're going to have one short presentation,
followed by a panel discussion, full of pre-selected questions.
I've already typed each of these questions that are planning to be asked in the doc
and so invite anyone to add any comments you're interested in capturing from the panelists,
as well as any expertise, any thoughts you might have about this
because we really are a bunch of rich resource people here.
And so audience answers are just as valuable as the panelist answers at this point.
And this is something that we end up sharing as a long-term resource.
It will be accessible forever.
This time, unfortunately, we won't have time for taking impromptu questions
from attendees on the community call
but I've created a separate section in the doc called questions - Part B,
where you can ask questions that come up for you
and I invite anyone to answer each other's questions.
And together, as I say, we'll make this a rich resource for everyone to use.
So finally, it's my pleasure to introduce our panel.
Julia Silge recently joined RStudio
as a data scientist and software engineer.
When we put out a call for a new maintainer for the qualtRics package,
Julia took it on because she was using it in her day job
as a data scientist at StackOverflow at the time
And she worked on the annual developer survey using qualtRics.
She also maintains other R packages, including tidytext,
which has been downloaded almost 900,000 times.
Elin Waring
is a professor of sociology and interim dean
of the School of Health Sciences, human services and nursing at Lehman College CUNY
She teaches research methods and statistics.
Elin was part of the rOpenSci Unconf17 group
that developed the skimr package
which has become very popular at over 250,000 downloads.
Elin works with Michael Quinn to maintain skimr
as they've shepherded it through two major releases already.
She formerly was a contributor and maintainer
for the Joomla CMS project
and her approach to maintaining
is influenced by that experience.
This includes understanding the importance of having a clear concept
of what you're trying to achieve,
being able to politely but firmly say no,
and knowing having users changes everything.
Erin Grand is a data scientist
at Uncommon Schools
and a Board member of R-Ladies New York City.
Erin created and maintains a package
for NASA's Astronomy Picture of The Day
It's called astropic and it was inspired by her early love of astronomy.
And one of her own images was featured
as Astronomy Picture of the Day.
Life goal achieved!
She also maintains a set of Internal packages at her work.
Leonardo Collado-Torres is a research scientist
at the Lieber Institute for brain development.
He maintains several Bioconductor packages,
including recently submitted spatialLIBD for spatial transcriptomics data.
He's a co-founder of the LIBD rstats club,
the CDSB Mexico community of R
and Bioconductor in Latin America
and those members just submitted their first package to Bioconductor.
This represents a dramatic percent increase in Latin American Bioconductor developers.
So, congratulations!
Also, congratulations, Leo, just in the last couple of days,
was promoted to the position of Research Scientist
and he's written a post about that.
Scott Chamberlain, our final panelist, is a co-founder and technical lead of rOpenSci.
He maintains, in his words, probably too many packages.
Part of Scott's work involves finding new maintainers
for rOpenSci peer reviewed packages.
And he tries to find those when current maintainer needs to move on,
like the qualtRics example.
His bio is really shortest because he's actually far too humble.
Julia is going to speak for about 10 minutes
and then for the rest of the hour, she's going to be moderating a panel discussion
with pre-selected questions.
For people who have just joined, thank you for sharing the link
to the shared Google Doc again in the zoom.
Please add your notes there, add your own questions in the bottom.
I am now going to share my screen
because I will note for people joined that Julia is not sharing her lovely face in home backdrop,
because there was an earthquake where she is,
she lost internet.
And so I'm going to be showing her slides.
So if you'll give me a moment.
Sure... Well... [inaudible]
[Julia Silge] Fingers crossed.
Yeah, there was a 5.7 earthquake
at your needs and it was not super big.
But enough that one of the aftershocks knocked out internet at my house
and I'm trying to be able to still speak
If we lose me, then I know that everything will keep going
and in a great way.
So,
So we're going to talk through these slides about just briefly about particular perspectives
on maintaining an R package.
So if we go to that slide about being...
Let's see that, next slide...
Maintaining an R package we often think... we cannot...
There's a Reese's about
when you're building R package, about what we focus on
in the technical aspects.
But once you're in the piece,
though the part of you actually built your package
and people are using it.
There's quite a balance in the amount of time
that we spend managing technical work,
which is, of course, extremely important with social aspects
of who is using the package, if you will,
involves often with asking a lot of the right questions
(go to the next slide)
Some of the right kinds of questions that we ask
when we're thinking about what it takes you to packaging,
the date, or some of these like --
Is this a package that's used really broadly by a lot of different kinds of people
and we can think beginners?
Is this a package that has a specialized use case
or that's used by people who know each other, internally at a company?
Is the person maintaining the package, the person who put it together originally,
or as has it been passed along a couple of times?
When you think about maintaining your package...
I'm interested here as we have our discussion what people's perspectives on like
how do we change?
And so you can either thinking about packages changing over time
or, packages being superseded.
And it's been interesting in our discussions preparing for this community call.
Software doesn't live forever.
And when we build software, do we put thoughtfulness into
what do we expect to happen next?
So we can go to the next slide.
One of the motivating ideas of setting up this community call
is that most software out there, whether you're talking about R packages or not,
have one main person who keeps it running
and a goal of rOpenSci, and a lot of us in this community,
is to build up the sustainability of our software ecosystem.
And it's somewhat brittle and also contributes to burnout
and uncertainty about what is going to happen
when we just have one maintainer.
Some other things you can struggle with are
You know, literally no one else knows what to do with this internal of this package too.
What do you do with one person having to manage sometimes what can feel like
an overwhelming amount of feedback from users.
If you go to the next slide
There's interesting research out there about
both like what is the situation with software contributors
and how can we either navigate that situation,
encourage more or figure out what the right path could be for a community.
The references at the bottom here of analysis of open source contributors
In this analysis, they did --
It's not uncommon to find
casual contributors, like people who are not the main maintainer
and you have a situation where there's a lot of, a long tail of small contributions,
so like half the contributors are responsible for 2% of the commits.
But they are lots of different kinds of commits.
These 2% of commits from lots of different kinds of people
are lots of kinds of things.
You know there are things like typos, but they're also things like fixing bugs
and building new features and refactoring.
This ... contributes --
What this is, is evidence that these are people who could be scaled up
to being more contributor, more contributing,
more significant maintainer or contributors, if that is appropriate for your program.
If you go to the next slide.
We often have this model of software contributions,
where we have to think of it as like an onion model
where you've got the users, and the contributors are inside of there,
and the committers are inside of there.
And that's often how we have this mental model
of like how, why, the software work, you know.
But, we might want to consider whether that is the best model
and instead move to what's on the next slide, which is a hub and spoke model
where the code is central, right?
Like, that's the thing that we're all using. So that is in the middle.
And there are maintainer who work mostly on code,
but there are also other kinds of maintenance activities happening
So there are maintainer of the software who focus mainly on education and docs.
There are maintainers who focus mainly on issue triage.
There are maintainers who focus mainly on evangelism.
And users kind of swim around in this --
swim around in this like in a soup around this hub and spoke model,
and depending on their particular need at any one time,
they engage with these different maintainers. Like, maybe the user-support one,
or maybe the people writing the code, or maybe the people writing the docs
and so like this might be a helpful mental model
for thinking about package maintenance, especially for larger packages
that have more users.
So if you can go to the next slide.
So it turns out we do actually have research and know what can contribute to,
what can encourage more contributions. So the next slide outlines something
For one study that was done, something that somethings that we, you know -
if you're involved with rOpenSci, you've heard this kind of thing
and seen this thing in action.
So, include and enforce a Code of Conduct.
Have cultural norms and include kindness and respect
Something that was here. That is interesting. I don't see a lot in R packages,
but could be interesting to consider.
That's: make more public or explicit any future plans you have.
That can help contributors know what to do.
And then the - if you go to the next slide. This paper also has some very interesting ideas
of how to help newcomers become contributors and maybe eventually maintainers.
These are all here. I'll highlight a couple
Let's talk about that. I'll just highlight that second one:
Have forms of participation that are legitimate in your projects,
that are valued, that are not writing code,
that are on ramps and then those last two I think are very interesting to
To explicitly acknowledge all contributions. To have a culture around your project
that doesn't let contributions just, kind of get, you know, swept away
and also to follow up both on success and failure.
If someone opens an issue or submits a PR that is not a good fit,
To follow up on both the things that succeed and fail.
So, what we just went through in those slides
are just some summary and thoughts on the current situation.
So a little bit of research of what we know.
You can go to the next slide.
The rest of the time that we're going to have here is going to be a panel discussion
If my phone tethering holds up, I am going to moderate this panel of folks
who are going to talk about some of our experiences.
Some of our opinions on maintaining R packages.
And if you will, the next slide that will just have some of the references.
Just to thank you. Where some of those images.
And a thank you to Scott for some of the research that he shared.
So thank you to all that.
And I think with that, we can get started with our discussion.
Alright. So if you're -- So, panelists: Leo and...
So our panelists are: Leo, and Elin, and Scott, and Erin.
So, you all have been introduced, but can you unmute?
And then, to get started, I think the first question
I would love to have us discuss is: What does it mean to maintain an R package?
This is what we're talking about.
So, I would love to get your perspective on that.
So let's go around and so, briefly, let's first have all four of you all say like
What do you, like -- what does it mean to maintain R packages? So Elin, can you start?
So I think it means a couple of different things,
There is this very specific thing, that term you use 'committer' before,
which is people who can commit to the master branch
And in CRAN like the person whose name is going to be there as the email address for
and make the submission and they're going to be the prime contact
So that's one definition which is kind of the traditional
open-source way of thinking about it.
But then there is kind of, I think what you're getting to,
bigger possible group of people who are invested in making sure
that the package is maintained.
Meaning keeping -- just like maintenance on anything,
keeping it up to date, dealing with bugs,
what happens when you stop working, because some other package updated
or because R, base R, change something
So someone who participates in that.
And then also, potentially, in all the other areas you were mentioning.
Yeah yeah nice! Scott?
What do you think it means to maintain an R package?
[Scott] Um, there's a lot of details, I guess. But I think that a very...
Can you hear me good? [Julia and Stefanie] Yeah.
At a very high level, I guess, the thing that came to mind first for me
was just that it's like a constant learning process.
A constant, sort of like, trying to figure out
how to do any particular thing better, whether it's testing or function compos--
like how your function is composed, the parameters or whatever.
And I think another point, about the second point that I came up with
was sort of constantly learning how to design better function interfaces.
You know how the functions are named, and the parameters are named,
and how their default values, their -- stuff like that.
So I think this is constant learning process of how to design easy to use interfaces.
[Julia:] Yeah yeah yeah yeah, all of what you both you just said
really resonate with my own experience with like the different packages I maintained.
Erin, when you think of like, maintaining an R package,
what do you think that actually means?
[Erin] Yeah, first of all, I agree with everything the other panelists said
Something that hadn't been mentioned, I think, is
the sort of ownership around community and communication of the package.
So, being the person who responds to issues or is looking at push requests,
and really, like, dealing with the communication out to contributors or to users
on either changes or what's happening with the package.
[Julia] Yeah. Nice! Yeah, that's absolutely, that's really great
And then Leo, what do you -- what about -- what's your response to this?
What do you think it means means to maintain an R package?
[Leo] So I'm going to echo what some of the other panelists said
but for me it's like you deal with the questions you get from users.
You approve or disapprove changes that you receive from others
and you end up learning about community guidelines,
like my case like the Bioconductor guidelines.
And then you also have to -- you end up learning about like are R-devel
and what changes are coming, how to anticipate those changes,
such that you can fix them before the user sees them.
[Julia] Yeah, that's great.
So one thing I heard a lot of you mention was like deal -- understanding users,
hearing from users... and, the issue of like user feedback
I think is a really interesting one when it comes to maintaining R packages.
So some R packa --
So some, you know, pieces of software are in the situation where you're like --
[inaudible]
[Erin] I think we lost you.
[Stefanie] Julia? We just lost your sound.
Folks, we have a backup plan. And for those of you in here:
Julia lost internet due to an earthquake today.
[Julia] But, you know, on the other --
[Stefanie] Oh! Julia! Hold on. We lost you for like 40 seconds.
[Julia] Oh, okay.
[Stefanie] Could you please restart by asking the question that you were just about to ask?
[Julia] Sure. Sure...
So user feedback is an issue that R packages need to deal with
and many packages need more contributors, not fewer
and so we often want to encourage user feedback.
At the same time, some packages are in the situation
where they have a fire hose of user feedback
And that fire hose can sometimes feel like --
You need to manage that.
How do you manage that? What kind of situations have you been in?
What strategies do you use to deal with user feedback?
Elin, can you start with this first because I think I've heard
you have some interesting perspectives on this, especially as someone who --
with skimr as a very popular package.
(Erin) Sure. So skimr is pretty popular
and we do get a lot of different kinds of user feedback
we get people who want to know how to do things in skimr,
they have questions about it.
We have people who want to make, you know, suggestions for future development.
And then we get people with issue reports and --
I will say... it --
when I said having users changes everything, it really does
because you do have kind of a relationship with them
and they're using -- you've kind of --
It's complex, right? Because you've kind of given them something
And you want them to be grateful that you gave them this thing
and but you also, you know, in terms of --
if you're enjoying your package and you're developing it,
and you want to find out what's wrong.
So it's kind of like you feel good when people are asking you
and tweeting to you and stuff like that.
But it can also get a little bit overwhelming. I will say --
And skimr is kind of a strange case because it was first developed at the unconf.
And so people were tweeting about it like before it was finished,
before even like the first prototype was finished.
And so we had a lot of feedback right away about ideas of things to do
and people started using it.
Um, and so I'll just tell you how I kind of think about dividing it up
like one thing I did was:
within two weeks we had questions on StackOverflow about skimr.
And so in the end, once it got to like five questions,
I just created a tag. And so I have a tag that I follow.
And I find that's helpful.
We don't get that many questions anymore over there, but --
And then we have our issue tracker.
It's the main place where people show up and it's really helpful in a way
because we have some kind of heavy users who come in and say:
"hey, if you're on the development version of tibble, it doesn't work anymore because this happened."
And so that's helping us keep a little bit ahead of the game
because you don't want to find out that it breaks with the development version of tibble,
the day that there's a release and they can be really helpful with that,
On the other hand, the whole issue of --
You know, if you have a package that you're keeping for multiple years now.
You have things like your code style that you want to enforce
like we use spaces some places and
and we want to use the assignment operator and not the equal sign and things like that...
And so sometimes it's hard when users want to send a pull request.
And then you want them -- you want to encourage them to contribute,
but you don't want them --
no, it feels kind of like you're being so OCD on like saying:
"Hey, would you mind adding a space here?"
And so I find it challenging to find the balance with that in terms of saying
I'll just fix it for you, versus asking them to fix.
[Julia] Yeah, yeah, there was -- some of the things you said in there in terms of like,
you know, following a tag on StackOverflow, or
You know, getting that note of should I edit a PR afterwards versus interacting with somebody?
Are things that I also have, kind of had to figure out,
like, what am I, what am I going to do. And so that's interesting.
Um, you addressed some of the issues around also managing feature requests as well,
which was another interesting question.
So Leo. I think you um --
I wanted to ask you about that issue of hearing from users
as someone who works on more specialized packages.
[Leo] Yes, so the packages I work with on Bioconductor,
they don't have as many users
[inaudible]
you needed some very expensive data sometimes
in order to use them.
And so the issue I deal with is that
from one side we have open source tools and we want to provide them
and you know for free and build a community around them.
But the other side, sometimes we have people that have this expensive private data.
Some published under scared about sharing it, even when they have questions.
So you end up getting a lot of emails.
And I try to convince them saying that this doesn't really benefit anyone
Because I mean, I learn from the experience. They learn from the experience,
but no one else really does.
So I tried to convince them to put their questions on the Bioconductor support website
and through it share small reproducible examples.
Sometimes I can write a blog post about the question,
but that's a lot more work for me.
[Julia] Yeah yeah Yeah, yeah, no, the same.
I bet this happens to a lot of folks who maintain packages.
You get the email and and then that's what I do too actually is like,
And sometimes, I will like help the person write the reprex
and then be like now post it because then it's like,
well now at least this person knows how to post a reprex
and can do it next time, because helping someone over email is not --
doesn't multiply in the way that like public stuff does. Exactly.
We've touched a little bit --
[Leo ] Sorry, just for that, like -- what I tried to reward them with
is answering as fast as I can, but
(Julia) Yeah.
[Leo] questions they make.
[Julia] Yes. Yes, being really responsive on those channels.
We have already touched a little bit on, like managing issues and feature request,
but I wanted to get maybe one other person's perspective on that,
like about workflows, or whatever.
Scott, you have a ton of packages,
and I wonder if you have any perspective on user, on issues, feature requests
and any thoughts on like workflows around that.
[Scott] Um, yeah, I guess I have a lot of packages
but none of them are very popular.
So I think it's -- I don't really have that sort of tidyverse problem.
So, but, you know, things I try and do. Or I think Leo said this, you know, responding.
I try and respond to all issues quickly, even if I just say:
'Hey, I got it. And I'm going to have a look at it.'
I think it's important to sort of give people that feedback so they don't walk away
from your package.
And I think that's likely going to happen if they don't have a response.
[Julia] Yeah. Absolutely.
[Scott] Um, and then feature requests...
I think it's always good advice to think about scope creep
And if you're, you know -- if something's out of scope,
then make sure to say that and just, yeah. And instead of --
try not to get your package to be too disjointed for users.
[Julia] Yeah. Nice. Nice.
Alright, so one of the goals that - like one of the motivating goals
for this discussion is that, hey, most packages only have one maintainer.
And it'd be better if there was a broader
broader groups of people who can maintain.
So what is a path for someone, for new contributors to R packages.
So, for example, what it would be a first step.
What should someone do if they want to help maintain one of your packages?
So let's um... so Erin: can you say that,
so you've got like some up like a public package on GitHub.
You maintain packages internally.
What should someone do if they want to help with one of your packages?
[Erin] Yeah, I'll take this from the internal side.
Because I think that's a perspective that I come from a lot more often.
Because I have like four packages in that case in one package external
but in terms of how do I look for new contributors and maintainers,
a lot of my communication and issues and features or feature requests
for an internal package or like a work specific package.
Come via slack, even though the package is hosted on on GitHub, or Gitlab.
The questions and comments and issues come in via like a different tool.
So if someone is constantly asking questions or constantly asking for features,
it's pretty easy to be like, all right, will onboard you to this package
and then voila, you may update it yourself!
Exactly. So I think like, for me, if you're interested in the package,
if you have questions on the package
and if you've like shown an ability to contribute to any package at all before
I think one like first initial step is to have your own package
or have something that you've contributed somewhere
just to show that you know what an R package is in the first place.
But really motivation is the, the important thing.
[Julia] Yeah. Nice. Nice. What about you, Scott?
What, like what do you see as like a path for someone to get on?
And what would be like the first like a first step for someone who is interested ?
[Scott] Yeah, I guess my first, my main point was
what Erin already said was essentially is, you know,
From my experience, like the most successful sort of new contributors
are people that end up taking over packages or contribute a lot
or people that use the package and their package is a dependency
or in a project or whatever.
And so they sort of have this at least short term, you know vested interest in the package
because you know you have drive by contributors that will fix a bug
or do this or that.
But it's often when your package is a dependency
or sort of major part of somebody's project or something.
And so that's always a good, a good place to find contributors. Um, yeah.
[Julia] Yes. Well, speaking of dependencies, speaking of dependencies...
That's a big part.
I mean, that's a big bit of like the decisions around maintaining an R package
like deciding what do I want to take on as a dependency.
Like do I want to, do I want to... like what do I want to depend on
Do I want to like rewrite something internally or take on dependency,
like everything from like something like, you know, off to some little algorithm or whatever.
So, so I would love to hear something about that.
So Leo, what are some of the thoughts you have had
as you have made those decisions in your packages?
[Leo] Yes. So, in the Bioconductor realm,
there's the Bioconductor core team that they did their own grants and funding
and they maintain the core packages, the core infrastructure packages.
So I tried to depend on those
because I know they're going to be professionally maintained.
Also they have access to your package.
So if you depend on them and they make change that breaks your package,
they can actually go and fix yours without you actually doing anything.
And similarly, we try to rely on like the tidyverse packages,
because I know that they're well funded to keep working on the packages and and fix them.
But I also like to depend on packages from authors that I have interacted with in the past.
That's also sometimes how I find out about this packages from like--
[Julia] Yeah yeah
Yeah yeah yeah yeah that -- yeah, those that -- So yeah,
so things that you know are stable projects,
things that you know you have relationships with people,
that you'll be able to communicate with.
Yeah, that all, that all makes sense.
Another, um, some -- so there's dependencies,
and then there's -- then, there are also
like other things that so they can change, right and you have to manage that.
Then there's also APIs that can change.
So like Erin, your package that's on GitHub is an API package, right?
[Erin] Yeah, exactly!
[Julia] And like, so you have to, you have to like pay attention to
when the API itself changes.
[Erin] Yeah, precisely so as an example:
Astronomy Picture of the Day, or APOD as it's more commonly called
can either post a, like a picture or an image or a gif.
And then all of that information is supposed to get transferred back into the API.
But for a really long time, there was an error.
Anytime there was the -- with the API, anytime there was a video
that was accessed.
So it was able to basically download any information about any pictures
but any time there was a video, there was a problem.
So I wrote in this like whole test.
Like: if video, do not pull this day of information.
So that the user doesn't see the error, they just don't get an image back
and then they fixed the --
[Julia] They fixed it!
[Erin] Making my whole little workaround unnecessary.
So like keeping on track of like
(a) what's like issues are happening in the API
to either like find workarounds or solve them
or even like do a pull request to this like API source to fix it for them.
I think it's like an important part of maintaining
a package solely based on an API structure.
[Julia] Yeah and you know that's, um --
There are a lot of parallels just with Just with like if you're dependent
on another R package in general, you know, like everything you just said about the API,
that happens with just other software that you're dependent on.
Either other R packages or non-R software, you know, and that is for sure
part of this whole deal and like, choosing carefully what software
Are you going to decide to use or not.
And, you know, people do -- you know Leonardo shared his perspective.
But people have different sets of priorities they bring to that
and make different decisions, depending on their own perspective
which I think is, you know, makes sense and it's fine.
Um, one thing that happens in packages, is that
They that
Packages don't keep the maintainer forever.
I mean we you know we are talking about the fact that,
like the qualtRics package had a different maintainer.
He wasn't using it anymore. And then I started maintaining it.
And actually, like, since I moved -- I switched jobs from StackOverflow to RStudio
RStudio doesn't use qualtRics for surveys and so I'm actually --
Like I kind of have a stopgap saying in place for now,
but I'm gonna, I'm actually looking for someone else to take over qualtRics in the long term.
Because it like --
it is better, if it's someone who uses it, who is actually actively using it so that
So this is something that has to happen in real in the real world is that
maintainers, packages, pieces of software have to change and maintainers.
And so I'm wondering what sets --
if you have experienced this, what sets that up for success?
And this is something that probably looks different in open source software
versus internal packages versus, you know, and really big packages
versus small packages.
So maybe, Scott, can you talk about what this has looked like for you?
You know, how you would manage that, say in rOpenSci?
[Scott] Yeah.
So for most of the ones I've been involved with
They'd mostly been sort of wholesale letting somebody else
manage the package without sort of me being involved.
And so that's mostly what's happened and I think that's worked okay
and I think like one of the things that you have to be okay with those sort of giving up
being okay with giving up control of your baby.
[Julia] Yeah, it's not yours anymore so...
[Scott] Yeah, that can be hard, but you know, you just have to sort of say,
you know, the new person Is the maintainer and if they want to change the functions
and whatever, like it's you know it's their package, they're the maintainer.
I think it's it's worked pretty well, but I think an important thing is being there.
Being, you have to sort of be available at least for a little while
for people to get oriented and that can take some time.
And I think an important thing when looking for a new maintainer
is trying to find somebody that knows the topic area.
[Julia] Yes, absolutely.
[Scott] That's like if it's a genomics package,
then it should be somebody in genomics probably because they're going to maybe use it
and maybe know the area know this sort of ins and outs of that type of data.
So. Yeah.
[Julia] Yeah, all right.
Erin, can you reflect on that maybe in the internal package domain.
Like what, like, what does it take to pass things off well
because that, actually in my experience, it happens a lot in internal
because people change jobs.
[Erin] Yeah, exactly.
I think one of the major differences that I've seen with passing an internal package
is the like time of notice
[Julia] Yeah.
[Erin] Someone switching jobs, they may not tell the other people
that there's two things out until the like two weeks beforehand,
in which case they have a lot of other things to offboard.
That might not be top priority.
So I think it comes to having clear like guidelines
around what the package does, the style of the code, where it's located,
where questions and answers happen like a side effect in Slack
or effect in GitHub in a way to sort of pass off everything
through written documentation
if like in person or over zoom communication
like can't happen due to other time commitment or at work.
But if like possible, then having like a real like onboarding experience
of walking someone through the ins and outs of a package,
I've found to be very useful.
But there's not always a lot of time for it.
[Julia] Absolutely. Absolutely.
All right, one question I'd like to ask Is about the decision
to submit a package to some kind of like centralized repository like CRAN or Bioconductor
or to do something like peer review, like rOpenSci,
Or just the Journal of Open Source Software versus maybe to say only on GitHub.
And Elin, I was wondering, so you know you maybe in the context of
you've worked in a lot of different kinds of software,
but then you had skimr you all started it at the unconf
and then you know, so it was rOpenSci package
and then you did decide to submit it to CRAN
like what do you think, how do you, what do you think are the right decisions
to consider when deciding when making those decisions?
[Elin] So it's good because it's a really good question.
We took a while to decide to submit it to CRAN
like at first we were just working on getting the functionality and thinking about it.
And we reverted we -- you know version numbers are really important.
And at the conference at the unconf, we kind of started, we said it's version one
but then afterwards, a few weeks later, we went back and said it was like version 0.5 instead
Because once you say it's version one,
you really kind of making a promise to people that it's going to work.
And if you, you can always if it's less than one Kind of, say, it doesn't .
'Yeah we're not promising anything.'
And you can put that in your README. And definitely when you're going to CRAN,
All of a sudden, it really, you know, they're going to do what they do.
Everybody complains, but they're maintainers too, right?
And so they're going to do what they do to make sure that everything works
and they're going to find a million little things that you didn't really follow the rules on.
And then all of a sudden, you have this world of users
and you've kind of made this published manual on the web
that anybody can find and it's just a different feeling
when you once you're in one of those repos, I think in one of those repository.
With just in GitHub, I actually sometimes don't even put a license.
I mean, I know they get mad but I just don't put a license sometimes
because I'm like, I'm not even sure I want people to have that much confidence
in this package. That they should be using it.
And you know, I do have another one from the following year's unconf,
which is called qcoder.
And we actually have quite a few users of qcoder,
but not at the same volume, because it's not, you know,
It could go on CRAN, you know, probably, I could get it ready in a couple weeks.
But I just, I don't feel like ready to have a lot of users there.
So I just think you're making that big decision.
The other thing is, once you're on CRAN, that's actually when --
and I'm sure with Bioconductor as well, then all of a sudden you're going to have
other packages using you as a dependency, and especially because they changed, you know,
Nobody can use a GitHub package anymore. If you're, you know, in CRAN and so it --
but it has, you know --
once you have those other people out there, then depending on you,
that also creates a level of kind of social obligation, social contract
where, you know, you could say:
'Okay, I'm just gonna let my package get archived.'
But then all this other stuff breaks and you know you feel bad about that.
Well, if you're me anyway.
So, you're kind of once you're in, it's there.
There's just a snowballing of it.
And I feel like in, you know, your GitHub, you can just say:
'Hey, I put it out there. Feel free to fork it.'
Right, that's another thing, no one mentioned, right?
I mean, again in open source, there is kind of the social contract
that a fork is the last resort.
But if a maintainer totally ghosts the project, then they someone else can always work the project
and make the fixes and you know, I certainly have done that.
Not for public consumption but just for free.
Yeah, where there's like I use, For teaching I use RStudio Server a lot.
And there's some packages that don't work well on RStudio Server.
And so, you know, I have my little fixes.
They know it's like when you're ready for my bug and interested in supporting it,
I'll send you my pull request again.
But I'm not going to like get into an argument with a maintainer about that.
So it's -- there's just a -- but I do, I feel it is this big you are, it's kind of like going public.
And now you're out there and you have people depending on you
and you said you're ready so...
[Julia] Yeah, yeah.
No, those are really good thoughts on those decisions to submit to those central repos.
Okay, so now it's time for our last question. So for our last question.
I'm gonna -- I want everybody say what their response is,
maybe just kind of in like one sentence, if at all possible, and just like one sentence.
So, for this last question, let's say, let's all say, what does someone need to know
Like in in terms of like need to know or skills to start maintaining a package?
So, Leonardo, can you go first?
What does someone need to know to start maintaining a package?
[Leo] Okay, so for me it's: you have to be willing to communicate regularly.
So that means responding emails or slack messages in a timely fashion.
You have to also learn how to ask questions in such a way that others can help you fast
and ultimately need to practice patience and be patient with yourself,
be patient with others and practice empathy with others
because they're helping you with their time.
[Julia] I love it, I love it. Fantastic.
Erin, what do you think people need to know to start maintaining a package?
[Erin] Leo stole my answer. But I will reiterate it.
What is like really good communication skills.
Both to answer questions and to write up really great documentation
that helps to mitigate the types of questions and issues.
[Julia] That's awesome!
Elin, what do you think somebody needs to know to start maintaining an R package?
[Elin] I think you need to know that you are really willing to do it.
I think you need to know you really like your package actually.
Like you don't put a package out in the in the world
because you want other people to maintain it, right? Or give you bug fixes.
It's because you want it to work.
[Julia] Nice. I love that. I love that.
Scott, what do you think someone needs to know to start maintaining an R package?
[Scott] So if you're somebody that only writes scripts
and what -- which I did, you know, the first probably four years of using R.
Learn functions.
So you can't really make an R package if you just have scripts.
So I would say if that's one thing to learn is to learn how to write functions and use them.
[Julia] Nice. I love that too. Awesome. Awesome! I love this whole discussion that we have had.
And it really aligns so strongly with the experiences I've had
maintaining a couple different packages. And when I think about --
So, I took on the qualtRics package, which is an rOpenSci package
for accessing survey data from qualtrics through their API.
So I took it on from one maintainer from before,
and now I'm thinking about now, like, what will, like what happens if I, you know like now
I need to find the new maintainer., as I pass it on too.
And as I think about all those things you all said.
Like what someone needs to know, I agree entirely.
And I think about like in that particular --
One thing I'm going to add, as I think through this.
Is that, like, really, in an ideal world, like the person is someone
Someone who is like a user of that, like someone who is kind of the audience.
Like you can't --
And it really aligned with what Elin was saying about you care about that domain.
And if you're someone who is the audience for that, then you're like:
'Yep, I'm ready to maintain this because I'm actively using it and know how to fix it!'
And so that is another -- Like for example when I'm --
When we're going to be talking about, like, who's going to take over qualtRics?
Like that's going to be -- that's a big part of it, right?
Like someone who is a person who uses qualtrics and understands how packages are put together,
and has these responsive communication skills.
So thank you so much panelists for that wonderful discussion.
I think that Stefanie is going to wrap us up with a few announcements.
[Stefanie] I am, thank you so much. My heart is full today.
This was really such a wonderful discussion. I love it, particularly because this is we thought:
'Oh, sure. Let's do a community call as a panel discussion.'
But of course, that could just be so disorganized and people chattering.
This was very well planned. And I thank the panel so much
because we all met a week ago to talk about this.
So this is not what an impromptu panel discussion looks like.
A lot of work went into this on the part of the panelists.
And so I thank all of you sincerely. This could not have been more successful I think
We can even function without Julia's house having internet.
So this is wild.
At the peak, we actually had 90 participants attending this call.
So congratulations to everybody for joining. We shared kind of cool thing today.
I wanted, especially to thank,
I noticed Janani Ravi was taking a bunch of notes in responses
as the panelists were talking. So thank you very much for capturing that.
I also noticed quite a number of people have been adding their questions
and answering a bit in questions Part B.
So that's really cool because I didn't notice as the discussion was happening.
In this shared Google Doc, I'm going to leave this open for editing,
at least for another 24 hours,
So, if you have to go off to other meetings, I'll leave this open for editing for a while
so that you can come in, add additional questions you have,
answer each other's questions. Participants here can add their comments.
Ideally, if you're willing to put your name beside that,
add your comments to some of the questions that the panelists were asked,
because we really do have such a rich amount of expertise here in the audience.
After about 24 hours, I'll lock the document to view only.
It, along with the video of this call, is going to be posted on the archive page.
So it'll ropensci.org/commcalls. This will live there forever.
What else do I want to tell you?
Please, before you go, please, add your name to the attendees list in the doc,
I don't share that much.
Just for us to know what countries you came from
and what organizations... That kind of thing.
We have a new discussion category in our public forum.
So our public forum is discuss.ropensci.org, and just in the last couple of days,
we created a package maintenance category.
I encourage anyone, especially people who have said they're feeling a bit overwhelmed,
they're just getting involved in maintaining a package.
Please ask your questions there.
Some of our, sort of like internal maintainers will also get a flag when something's posted there.
So they may be able to come and answer your questions.
You can answer each other's questions. So right now it's empty.
It's just a category that exists, and I encourage you to use it.
Do I have anything else I need to tell you?
I think that's it.
You really, it's only 10 o'clock in the morning for me here in Kamloops British Columbia,
you set me off to start a wonderful day.
I thank you all for joining us wherever you are in the world,
and I wish you both a physically and mentally healthy and happy rest of the day.
Thanks so much, everyone.
Bye bye.