Contributing to stockplotr

Do you have an idea that would improve stockplotr? Consider making a contribution! We welcome ideas for improving not only our code, but also our documentation, tutorial, and any other material associated with stockplotr. Here are some options and tips for doing so.

Note: To make any contribution, you must agree to abide by the Code of Conduct.

Contributing ideas: code, documentation, etc.

Recommended workflow: fork & submit a pull request

The most efficient way to contribute an idea is to fork asar, make your suggested changes on a local branch, and then submit a pull request to the main branch. This will allow the developers to easily evaluate your suggested changes. Please see the GitHub Docs’ “Contributing to a project” page for step-by-step guidance in using this workflow.

We also follow a few other practices that will help us expedite the review process. After completing the bug fix or feature, please complete the following:

  1. Run devtools::test() to verify the package checks are passing (this includes tests).

  2. If including a feature, please add a test using the {testthat} package structure. If you are unfamiliar with this approach, simply let us know :smile

  3. If including a feature that is a new function, please add documentation using the {roxygen2} package structure.

  • Write clear, succinct commit messages (see some tips here)
  • Limit a commit to a few, rather than many, changes. Smaller commits means more commit messages, which is often helpful for documentation.
  • Ensure your base branch is correct. We merge all branches into main.
  • Test that your contributed code will function as expected under different circumstances.
  • Add comments to the code if it’s not immediately clear what the purpose of the code is, or how it works.
  • Name branches and title pull requests according to the release indicators in the table below.

Release Indicators:

Indicator Description
feat A new feature
fix A bug fix
docs Documentation only changes
style Changes that do not affect the meaning of the code (i.e. white-space, formatting, missing semi-colons)
refactor A code change that neither fixes a bug nor adds a feature
perf A code change that improves performance
test Adding missing or correcting existing tests
chore changes to the build process or auxiliary tools and libraries such as documentation generation

Rules for Indicator Use

  • If the body contains the text “BREAKING CHANGE” then MAJOR version is incremented.
  • If the type contains feat, then MINOR version is incremented.
  • If the type contains a fix, then PATCH version is incremented.
  • If the type contains refactor/style/perf/doc/test/chore, then nothing is incremented and no release will be made.

The above content is modeled after an article on “Automating Versioning and Releases Using Semantic Release” from Agoda Engineering.

Contributing bugs

Found a bug? Tell us about it on our Issues page. Before you create an issue, please check that it has not already been resolved (i.e., is a “closed” issue) or documented in our Frequently Asked Questions (FAQ) vignette.

If possible, please submit a reproducible example (reprex) to help us understand the problem better and, ideally, allow us to reproduce your issue.

Contributing questions

Have a question? Ask it in our Discussions page. You can categorize it under General, Ideas, Q&A, and more.