# R Contribution Working Group Meeting 2026-01-28

## Present

**R Core**: Michael Lawrence, Peter Dalgaard
**R Foundation**: Hadley Wickham, Heather Turner
**R Consortium**: Terry Christiani
**Forwards**:
**R-Ladies**:
**General R community**: Gabe Becker, Mikael Jagan , Kylie Bemis, Jeroen Ooms, Mossa Reimert

Minutes of previous meetings: https://github.com/r-devel/rcwg/tree/main/team_minutes

## Agenda

- Welcome

### Main items

- [Community Playbook](https://github.com/gmbecker/R_contributor_pathway_pbk/blob/main/the_contributor_pathway.md) (private repo, ask Gabe Becker for access). Some notes added to pad prior to/during meeting without direct discussion.

- HT: Background: this is a product of the Birdaro training for open source leaders that myself, GB and ML attended in Q4 2025. See previous minutes for earlier report-backs.
- HW: Propose quick poll to see if we've all read it.
- About half had, so GB asked to briefly talk through content.
- JO (prior to meeting): Would prefer to work in a public repo under the R-devel organization. Working in the open is part of being a healthy open source project. HW: strong agree. HT: This is the general rule for RCWG, but given sensitivity of topic we though it best to start in a private repo, expanding access to gather wider feedback as proposal develops. Aim to eventually have a public process.
- - HT: Suggest to restrict scope:
- Exclude CoC for now: developing and proposing CoC is in the plan for RSMF and will take some time to work through.
- Section on Conduct, including roles such as CoC member could be added in version 2, or be a separate document.
- Exclude R Foundation: proposing changes to structure/governance of R Foundation is also in the plan for RSMF, currently all as described in statutes.
- Possibly exclude CRAN? Or else this section needs more work. See Lluis' comments: https://github.com/gmbecker/R_contributor_pathway_pbk/pull/2#issue-3851038278 and PR: https://github.com/gmbecker/R_contributor_pathway_pbk/pull/2
- LR argues for including CRAN pathway in https://github.com/gmbecker/R_contributor_pathway_pbk/issues/3
- HW: I think we should drop CRAN pathway because CRAN is not formally represented in this group.
- HT: Exclude defining which roles should be paid or unpaid - focus on the roles we'd like to see then see how we can support them (which would be purview of R Foundation/R Consortium).
- HW: there are a _lot_ of roles currently. Can we simplify? Can drop we translation team for now?
- Consensus to focus on "contributor pathway": general R user to R Core and deal with other roles separately.
- General principles of pathway (GB)
- Not a guaranteed pathway to R Core. As shown in the figure, expect decreasing number of people at each level as not everyone progresses to next step.
- Not intended to be rigid. If people have sufficient experience (and support from R Core), they could skip steps
- Feedback on specific sections.
- Feedback from general users. HT: Is r-devel mailing list the only way to give feedback outside of Bugzilla?
- Suggested required skills for R Core candidates. ML: Should be something in there about social skill. GB: there are sections there covering technical and non-technical skills. Desirable/non-essential skills currently have asterisk.
- Election process.
- ML: Have we compared with other open source projects? GB: Have considered Python process: https://devguide.python.org/core-team/join-team/, https://peps.python.org/pep-0013/. Mentor watches mentee's PRs over a period of time before proposing a vote for the mentee to gain core commit rights (become a core developer). KB: Python also have PEP process for engagement. HT: We are planning to develop such a process under RSMF project, will come later.
- HT: Possibly restrict voting to "active" R Core members (e.g. Python define as inactive no substantial contribution in 2 years: https://peps.python.org/pep-0013/#membership - inactive core developers have commit access revoked, can reactivate any time), then 2/3 of active members in favour. (HW: +1)
- HW: Could apply active/non-active definition to new members, so existing members automatically keep their vote.
- HT: Mentored contributors able to self-nominate after 1 year, with support of mentor?
- ML: Might be able to borrow from R Foundation statutes here.
- Removal from R Core
- HT: Super-majority should also apply to removals from R Core
- HW: Would be good to have emeritus role. Would help with people that aren't able to commit long-term.
- Provisional R Core members.
- HT: Should they continue to submit (non-trivial) changes for review by other R Core members? HW: IMO all non-trivial changes should be reviewed by one other human
- HW: provisional access makes it seem like R Core doesn't trust the newcomers. Would prefer not to add this section. ML: Maybe better to keep it simple and add clauses as necessary to get it adopted.
- Communication. HT: RTAP communal communication space and Mentored Collaborator communication space can be on Slack for now, moving to Zulip is in RSMF plan.
- Community management. HT: Unsure about R Contribution Facilitator role - not how I see it working in short term, will consider this further. HW: I do not understand how this role can possibly successful without commit access, i.e. this should be a role that some on R core plays [edit: not dicussed in meeting, presume HW referring to R Contributor Community Manager role].
- Translation roles (HT)
- Need to be discussed with existing leaders (Gergely Daroczi, Mike Chirico, RSMF contractors, self-nominated Translation Team leaders). How best to coordinate discussion?
- Think that there should be Translations Team Administrators + nominated member of R Core focused on translation (existing or new role). R Core member should have full access to svn, allowing to patch other code, e.g. update message strings.
- HT: Which are important roles for R Core to agree with?
- LR: Listing people in each role: https://github.com/gmbecker/R_contributor_pathway_pbk/issues/4
- HT: Maybe we should propose to update: https://www.r-project.org/contributors.html?
- TB: The real risk is to the existence of the language and the ability to continue distributing it in the EU. There are real consequences to the lack of governance and processes starting in November of 2027. E.g. CoC is essential and needs to be a way for people to have reliable way to engage with maintainers.
- EU Cyber Resilience Act - R Core is considered to be Open Source Software Stewards under the law.
- Approach
- HT: Is this going to R Core, or R Foundation?
- ML: Want to propose framework/draft to R Core, such that they own it and refine/approve a final version.
- KB: Aim should be to propose what we think is best for the long-term sustainability of the community
- TC: Should put forward everything you want to see - let R Core push back on specifics if necessary rather than hedging at this point. R Core may accept more than we might expect.
- GB: Currently there is not a formal proces to even consider our proposal, so need to keep that in mind, in terms of how much we need to consider potential objections in advance.
- KB: Won't get everything right first time. Important to have *a* process to start with and an process for updating it over time.
- HT: What are our main goals we need buy-in for? Initial thought from prior discussion with GB and ML
- Defined process for nomination and election to R Core
- Formal roles between ad-hoc contributor and R Core member
- Collaborating
- Would prefer for initial, quick iteration to move to Google doc.
- Put major versions in GitHub
- For discussion (notes from here on in process of being tidied!):
- ACTIONS:
- GB: will put in Google doc for collaborative comment/editing
- All: transfer your comments from here to there (so they are associated to you) and add any further comments/edits. First round of comments by Feb 6.

* Next meeting
- Currently: Tuesday, February 17, 2026, 19:30-20:30 UTC ([find your local time](https://arewemeetingyet.com/UTC/2026-02-17/19:30/R%20Contribution%20Working%20Group)).
- HT: Suggest Tuesday, February 24 so not same day as Forwards meeting
- TC: Not good - RF/RC meeting February 25.
- 30 min later better? No strong feeling.

## Additional Items

These items were not discussed but noted for information and possible discussion at future meetings:

- R Dev Days (https://contributor.r-project.org/events/r-dev-days/)
- Dates for 2026 (mostly tentative):
- R Dev Day @ Rencontres R 2026, Nantes + Remote, Jun 19: https://pretix.eu/r-contributors/r-dev-day-rr2026/
- US R Dev Day
- Tentaively Friday 26 (tutorial day) at CascadiaR
- morning and afternoon refreshments provided (not lunch)
- discounted conf hotel at Portland State
- R Dev Day @ useR! 2026, Warsaw, Poland, 10 July, TBC
- Contacted organizers. Initial response positive, looking into room bookings.
- R Project Sprint 2026, Birmingham, UK, Wed 2 - Fri 4 September (R Core meeting Tue 1 September), Birmingham, TBC

- Research Software Maintenance Fund update
- Soft launch meeting on February 9
- Inviting project team members, partners, collaborators and R Core developers

- Collaboration with Bioconductor
- Heather Turner and Ella Kaye met with Maria Doyle (Community Manager), Nick Cooley (Developer Engagement) and Kevin Rue-Albrecht (SSI Fellow/Contributor)
- Bioconductor project have gone through several changes we may be able to learn from, e.g. setting up CoC, moving to git (git.bioconductor.org), moving from Slack to Zulip, modernising website.
- Potential for shared initiatives, e.g. participation in European Open Science Cloud; shared infrastructure, e.g. virtual machines; shared meetings
- They are planning to submit to RSMF Round 2. Possible for some joint event as part of that. Initial brainstorming: https://docs.google.com/document/d/1iSpLNcbtoppR6BdkJHIUGCb9YD1X8kZPNGcReG8QneE/edit?tab=t.0#heading=h.fxwd9r62m3st

- Google Summer of Code (https://github.com/rstats-gsoc/gsoc2026/wiki). Do we have an project ideas for this?
- ML: Can we create an AI prompt/context to assist someone contributing to R?
- HT: Maybe something related to multilingual documentation project? Seems to have stalled somewhat.