Skip to contents

Pedixplorer: Contributing Guidelines

Source: .github/CONTRIBUTING.md

Hi there! Many thanks for taking an interest in improving Pedixplorer.

We try to manage the required tasks for Pedixplorer using GitHub issues, you probably came to this page when creating one.

Contribution workflow

If you’d like to write some code for Pedixplorer, the standard workflow is as follows:

  1. Check that there isn’t already an issue about your idea in the Pedixplorer to avoid duplicating work. If there isn’t one already, please create one so that others know you’re working on this
  2. Fork the Pedixplorer repository to your GitHub account
  3. Checkout the devel branch and create your work environment
  4. Make the necessary changes / additions within your forked repository
  5. Submit a Pull Request against the devel branch and wait for the code to be reviewed and merged

If you’re not used to this workflow with git, you can start with some docs from GitHub or even their excellent git resources.

Tests

You have the option to test your changes locally by running the unittests. Execute all the tests with the following command:

devtools::check()

When you create a pull request with changes, GitHub Actions will run automatic tests. Typically, pull-requests are only fully reviewed when these tests are passing, though of course we can help out before then.

Patch

⚠️ Only in the unlikely and regretful event of a release happening with a bug.

  • On your own fork, make a new branch patch based on upstream/main or upstream/master.
  • Fix the bug, and bump version (X.Y.Z+1).
  • Open a pull-request from patch to main/master with the changes.

Package contribution conventions

To make the Pedixplorer code and processing logic more understandable for new contributors and to ensure quality, we semi-standardise the way the code and other contributions are written.

Adding a new function

If you wish to contribute a new function, please use the following coding standards:

  1. Use snake_case
  2. Lint the code
  3. Add documentation and example through Roxygen2 syntax
  4. Add a unittest and aim for a full coverage