-
Notifications
You must be signed in to change notification settings - Fork 52
/
maintenance_changing_maintainers.Rmd
66 lines (42 loc) · 5.55 KB
/
maintenance_changing_maintainers.Rmd
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
---
aliases:
- changing-maintainers.html
---
# Changing package maintainers {#changing-maintainers}
```{block, type="summaryblock"}
This chapter presents our guidance for taking over maintenance of a package.
```
## Do you want to give up maintenance of your package? {#do-you-want-to-give-up-maintenance-of-your-package}
We have a call for contributors section in our newsletter that comes out every two weeks. The section is called *Call For Contributors*. In that section we highlight packages looking for new maintainers. If you are looking to leave the role of maintainer of your package, get in touch with us and we can highlight your package in our newsletter.
## Do you want to take over maintenance of a package? {#do-you-want-to-take-over-maintenance-of-a-package}
We have a call for contributors section in our newsletter that comes out every two weeks. The section is called *Call For Contributors*. In that section we highlight packages looking for new maintainers. If you are not subscribed to the newsletter already, it's a good idea to [subscribe](https://news.ropensci.org/) to get notified when there's a package looking for a new maintainer.
## Taking over maintenance of a package {#taking-over-maintenance-of-a-package}
- Add yourself as the new maintainer in the DESCRIPTION file, with `role = c("aut", "cre")`, and make the former maintainer `aut` only.
- Make sure to change maintainer to your name anywhere else in the package, while retaining the former maintainer as an author (e.g, package level manual file, CONTRIBUTING.md, CITATION, etc.)
- The [Collaboration Guide](#collaboration) has guidance about adding new maintainers and collaborators
- Packages that have been archived or [orphaned] on CRAN don't need permission of the previous maintainer to be taken over on CRAN. In these cases do get in touch with us so we can offer any help as needed.
- If the package has not been archived by CRAN and there is a maintainer change, have the old maintainer email CRAN and put in writing who the new maintainer is. Make sure to mention that email about the maintainer change when you submit the first new version to CRAN. If the old maintainer is unreachable or will not send this email get in touch with rOpenSci staff.
- If the previous maintainer is reachable, scheduling a meeting will help you get the "lay of the land"
### FAQ for new maintainers {#faq-for-new-maintainers}
- There are a few unresolved issues from the package that I don't know how to fix. Whom may I ask for help?
It depends; here's what to do in different scenarios:
- if the old maintainer can be contacted: reach out to them, and ask for help;
- rOpenSci slack: good for getting help on specific or general problems, see the #package-maintenance channel;
- [rOpenSci discussion forum](https://discuss.ropensci.org/c/package-development/29): this forum is a good option, feel free to ask any questions there;
- [rOpenSci staff](https://ropensci.org/about/#team): feel free to get in touch with one of us via email/pinging us on GitHub issues, we'll be happy to help;
- of course there's general R help too if that suits your needs: [Posit community forum](https://community.rstudio.com/), StackOverflow, Mastodon (#rstats), etc.
- How much can/should you change in the package?
For general help on changing code in a package, see the [Package evolution](#evolution)
section.
When thinking though this, there are many considerations.
How much time do you have to spend on the package? If you have very limited time, it'd be best to focus on the most critical tasks, whatever those are for the package in question. If you have ample amount of time, your goals can be larger in scope.
How mature is the package? If the package is mature, many people likely have code that depends on the package's API (i.e., the exported functions, and their parameters). In addition, if there are packages that depend on your package on CRAN, then you need to check that whatever changes you make don't break those packages. The more mature the package is, the more careful you need to be about making changes, especially with the names of exported functions, their parameters, and the exact structure of what exported functions return. Changes can be more easily made that only affect internals of the package.
## Tasks for rOpenSci staff {#tasks-for-ropensci-staff}
As an organization, rOpenSci is interested in making sure packages in our suite are available as long as they are useful to the community. As maintainers need to move on, we will in most cases try to get a new maintainer for each package. To these ends, the following tasks are the responsibility of rOpenSci staff.
- If a repository hasn't seen any activity (commits, issues, pull requests) in quite a long time it may simply be a mature package with little need for changes/etc., so take this into account.
- Current maintainer has not responded to issues/pull requests in many months, via any of emails, GitHub issues, or Slack messages:
- Make contact and see what the situation is. They may say they'd like to step down as maintainer, in which case look for a new maintainer
- Current maintainer is completely missing/not responding
- If this happens we will try to contact the maintainer for up to one month. However, if updating the package is urgent, we may use our admin access to make changes on their behalf.
- Put a call out in the "Call for Contributors" section of the rOpenSci newsletter for a new maintainer - open an issue in the [newsletter repo](https://github.com/ropensci/monthly/).
[orphaned]: https://cran.r-project.org/src/contrib/Orphaned/README