Code maintenance and contributions

[fontikar]

Quoting @rmegirian

A common barrier to sharing code is concern about ongoing maintenance or support, so being explicit about what, if any, subsequent responsibilities or expectations exist is likely to increase participation

A very valid point and definitely would be on the minds of those who consider code sharing as additional work. They would be even more apprehensive if it entailed more work.

I think some tier structure on code maintenance would help set expectations. This could a variable in the database and is defined by the code owner depending on their level of engagement AAGI-AUS/PBS-COP#10 and mirrors the EAST framework.
Tier A: Stand alone functions (shared as-is, minimal docs, no promises)

Tier B: Reproducible pipelines (example data + pinned environment)

Tier C: Supported packages / libraries (governed, versioned, changelog)

Some common strategies:

1. Very explicit READMEs on code maintenance and what is needed for reprex

   • “This repository is shared as-is; we welcome issues/PRs, but we can’t guarantee response times.”.
   • "We welcome contributions see CONTRIBUTING.md, issues and PRs are reviewed on a XX basis"
   • "Please use the issue template and include a minimal reproducible example so we can debug efficiently. LLM can help with generate one"
   • “Security / correctness bugs prioritized; feature requests may not be implemented”

2. Encourage Github Issue templates for bugs with reprexes "the code aborts on lines ..." and GitHub discussion boards for questions "how do I..." if code is open and hosted in a repository

   • Use labels for issues to triage issues and invite contributions

3. Contributing guidelines

   • Use labels "Good first issue", "help wanted"
   • CONTRIBUTING.md that gives details on how to run tests, how to fork and PR or make a contribution if not Github familiar, style expectations

At this stage, prioritise sharing as is and license so that allows appropriate reuse and modifications. More substantial maintenance will lie on those R package contributors which will have their own governance structures

[fontikar]

One option is have a template repo that will have READMEs, minimal contributing guidelines ready for copying and pasting? and this repo will get linked in on the website?

Wdyt @rogerssam