DOCSEARCHbyAlgolia
Submit Docs

rOpenSci Development Guide

repository·main·Indexed 41 days ago

https://github.com/ropensci/dev_guide

Guidelines and standards for the development, maintenance, and peer review of packages within the rOpenSci suite. Includes checklists for package assessment, documentation standards, and release workflows using the devguider package for URL and spelling validation.

Tokens
5K
Snippets
6
Records
28
Agent score
50%

What's inside rOpenSci

  3. Prepare for book publication (2 weeks before)

    main

    Two weeks before publication, complete the following tasks:

    • Content Creation: Draft a blog post or technical note regarding the launch. This must be ready for review by the editorial team and the Community Manager.
    • Branch Management: Create a Pull Request (PR) from the dev branch to the master branch. Notify the editorial team via GitHub and Slack, and mention the blog post draft in a comment on the PR.

  6. Submit final approval for a package review

    main

    When completing a peer review for an rOpenSci package, use the reviewer-approval.es.md template to record your final decision. To recommend approval, check the box indicating that the package maintainer has addressed your review comments with satisfactory changes.

    After making your decision, you must provide an updated estimate of the hours dedicated to the review process.

    - [x] **Quien mantiene el paquete ha respondido a mi revisión y ha realizado cambios satisfactorios. Recomiendo aprobar este paquete.**

Estimación de horas dedicadas a la revisión: [Insert hours here]

  7. Review an rOpenSci package

    main

    When performing a peer review for an rOpenSci package, reviewers should evaluate the submission against several criteria including conflict of interest, documentation completeness, functionality, and packaging guidelines. Reviewers are encouraged to check as many boxes as possible and provide detailed feedback in the comments section.

    Review Checklist

    Conflict of Interest

    Documentation Requirements

    • Statement of Need: A README file describing the problems the software solves and its target audience.
    • Installation Instructions: Instructions for installing the development version in the README, including non-standard dependencies.
    • Vignettes: One or more vignettes demonstrating core functionality that run locally.
    • Exported Function Documentation: Documentation for all exported functions.
    • Examples: Locally runnable examples for all exported functions.
    • Community Guidelines: A contribution guide in README or CONTRIBUTING, and a DESCRIPTION file containing URL, BugReports, and Maintainer (all in English).

    Functionality and Packaging

    • Installation: Successful installation following the provided documentation.
    • Functionality & Performance: Verification of all functional and performance claims.
    • Automated Tests: Unit tests covering essential functions with a reasonable range of inputs/conditions, all running correctly locally.
    • Packaging Guidelines: Compliance with the rOpenSci packaging guide.

    Generative AI Usage

    • Disclose if generative AI tools were used to perform the review and explain their contribution.

    Administrative Tasks

    • Hours Estimation: Estimate the total hours dedicated to the review.
    • Credit: If appropriate and agreed upon by the package maintainers, the reviewer may be recognized in the package DESCRIPTION file with the role rev.

  8. Perform editor checks for rOpenSci package assessment

    main

    When reviewing a package for rOpenSci, editors must verify several criteria across documentation, fit, installation, testing, and project management. Use the following checklist to ensure the package meets quality standards:

    • Documentation: Ensure sufficient online documentation (README, pkgdown) exists to assess functionality without installation. Check if the use case is well-defined, the reference index is clear (grouped by topic if needed), and vignettes are detailed and readable.
    • Fit and Overlap: Verify the package meets fit and overlap criteria.
    • Installation: Confirm installation instructions are clear for human users.
    • Tests: For packages with interactivity, HTTP, or plot production, ensure tests use state-of-the-art tooling.
    • Contributing Information: Check if contribution documentation (e.g., tokens for tests, playgrounds) is clear.
    • License: Confirm the package has a CRAN or OSI accepted license.
    • Project Management: Evaluate the state of issue and PR trackers (e.g., presence of outstanding bugs, clarity on feature request timelines).

  9. Execute book publication

    main

    Follow these steps to finalize the publication process:

    1. Validation:
      • Verify URLs using the devguide_urls() function from the devguider package.
      • Check spelling using the devguide_spelling() function from the devguider package. If necessary, update the WORDLIST.
    2. Merging: Squash commits and merge the PR from dev to master.
    3. Releases:
      • Create a GitHub release.
      • Ensure a corresponding release is created in Zenodo.
    4. Post-Release Cleanup:
      • Re-generate the book to update Zenodo metadata (or wait for the daily build).
      • Re-create the dev branch.
      • Finalize the blog post/technical note PR, highlighting key points for social media (e.g., tweets) in the PR discussion.
    # Using the devguider package for validation
devguide_urls()
devguide_spelling()