Evaluating GitHub Activity for Contributors

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

Look whether the repository is archived on GitHub.

🔗 How it helps

If the repository is archived, clearly the authors are not going to work on it any more.

🔗 (Custom) watch the repository

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.

🔗 How it helps

Watching activity in the repository will make you aware of

• ongoing development,
• development rhythms (for instance “cyclic but with quick fixes for crucial bugs”),
• workflows (are PRs welcome or do maintainers prefer to confirm interest in an issue first),
• the tone in that repository (if the tone is not friendly, run!).

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.

🔗 Read the contributing files

If the repository has a contributing guide (file CONTRIBUTING.md or .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.

🔗 How it helps

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.

🔗 Look at latest code activity

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).

🔗 How it helps

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.

🔗 Look at planning and user support activity

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.)

🔗 How it helps

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.

🔗 Look at authors’ activity

Identify main contributors:

• The DESCRIPTION file might not be that informative as it can contain historic contributors.
• Look at the graph of contributions to see who are the current / recent active contributors (see for instance https://github.com/ropensci/dev_guide/graphs/contributors).
• Also notice who responded to the latest issues and PRs.

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?

🔗 How it helps

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.

🔗 Look at repository checks

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.

🔗 How it helps

Failing checks that are not tackled might indicate the repository is not actively worked on.

🔗 Conclusion

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 [email protected]. We can for instance add a call for co-maintainers in our monthly newsletter.