Checklist for taking on dependencies

[jamesmbaazam]

As part of the task force to help improve decision-making around taking on dependencies, we have arrived at a checklist that could be used. The checklist essentially sums up a lot of the recommendations in the blueprints chapter on dependencies. I am going to post it here for further input and to discuss next steps. We could potentially merge this into the section, if deemed useful.

Considerations for taking on a dependency

1. Have you requested code review to check if the dependency can be replaced with a base R implementation?
2. Have you generated a dependency graph (using pak::pkg_deps_tree() for example) to understand the dependency tree?
3. Will your package be submitted to CRAN? If so, is this chosen dependency on CRAN? (This is a CRAN policy. See here)
4. Has the dependency had major releases?
5. Is the dependency used extensively in the core functionalities of the package?
6. Is the dependency used by only a small portion of your application, rather than being used throughout?
7. Does removing the dependency require minimal changes to your codebase?
8. Does the package have an active and responsive maintainer?
   NB: This depends on your own judgement of whether the package needs active maintenance.
9. Does the package require a system software, for example, docker, clang, etc?
10. Does the dependency have other dependencies that will be imported as well?

cc: @bahadzie @jd-otero @davidsantiagoquevedo