July 1, 2022 From rOpenSci (https://ropensci.org/blog/2022/07/01/evaluating-github-activity-for-contributors/). Except where otherwise noted, content on this site is licensed under the CC-BY license.
Say you have a bug report or feature request to make to a package. How can you use information on GitHub to manage your expectations (will there be a quick fix) and actions (should you go ahead and fork the repository)? In this post, we shall go over sources of information and explain how they can be used. In the end, there is no magical recipe, except perhaps graciousness, as software is made by humans. 😉
Look whether the repository is archived on GitHub.
If the repository is archived, clearly the authors are not going to work on it any more.
If you are very invested in the fate of an R package, it might make sense to custom watch it on GitHub: you can for instance to choose to be notified of all issues and PRs or only of releases.
Note that if you just watch a repository you are publicly listed as watcher, but to the best of my knowledge custom watchers are not publicly listed.
Watching activity in the repository will make you aware of
Now it won’t help you if right now you are looking at a repository you were not watching before, but it’s good to know for next time.
If the repository has a contributing guide (file
.github/CONTRIBUTING.md) and it seems to have been at least a little bit customized compared to a standard model, pay attention to it. 😸
If the docs have any mention of development lifecycle (a badge, some text), also take it into account.
Last but not least, seeing the repository has a code of conduct can help one feel safe! rOpenSci code of conduct applies to all rOpenSci packages.
It’s direct information from maintainers on what they expect from contributions, so it can help guide you in how to make contributions and what kind of contributions are welcome.
On the GitHub repository homepage you can find the time since the latest commit on the default branch. In the branches page you might see there’s code activity in another branch (see for instance https://github.com/ropensci/readODS/branches). In the releases tab you can see how old the latest released version is, and whether there’s a regularity in releases (see for instance https://github.com/ropensci/magick/releases).
If there’s current code activity, your contributions might be tackled more quickly. If you see the code activity is bursty (the developers focus on it for a period of time, release a new version, then ignore notifications for a while), you might guess you will have to be patient.
Sort issues and PRs by recently updated (the default when using the browser extension RefinedGitHub). Are repository members actively answering issues?
Look at milestones: what’s the content of the different milestones? Are there expected dates of release? (See for instance https://github.com/ropensci/dev_guide/milestones.)
If issues get a fast first human response, lucky you, you can politely ask whatever you wanted to ask and hope for a rather quick answer. If the planning is transparent and current (it’s hard to curate milestones 😅), you might get an idea of where your contribution will fit.
Identify main contributors:
Head over to their GitHub profile, and even their R-universe profile: Have they been working on other things? Do they have a status (parental leave, vacation)? Is there a mismatch between the repo organization and the contributor’s job?
Sometimes there might be something obvious: if the maintainer changed jobs, maybe they dropped the repository of interest. However, more importantly, while it helps to be aware of the public activity of contributors you never know what a person is going through, so be gracious and patient.
Head over the page of continuous integration status for the repositories, for instance it might be the Actions tab. Look at the CRAN status if the package was ever on CRAN.
Failing checks that are not tackled might indicate the repository is not actively worked on.
In this post we summarized some sources of information you, as potential contributor, can use to assess whether and how much a repository is active, to calibrate your expectations and offers of contributions. If a repository looks particularly abandoned, you might perhaps email authors to ask whether future work is planned and if not, whether you might take it over. Be considerate in all your interactions with code maintainers.
If you are the maintainer of an rOpenSci package and need some punctual help or longer term maintenance support, please get in touch with us at
We can for instance add a call for co-maintainers in our monthly newsletter.