We would love for you to contribute to RDS-R and help make it even better than it is today! As a contributor, here are the guidelines we would like you to follow:
Help us keep RDS-R open and inclusive. Please read and follow our Code of Conduct.
Do not open issues for general support questions as we want to keep GitHub issues for bug reports and feature requests. You've got much better chances of getting your question answered through our help desk.
This repository follows the Gitflow workflow. We believe this will make the rds-r package easier to use in through devtools::install_github("mtna/rds-r")
as master should always be the latest stable released version.
The main branches to be aware of are:
If you find a bug in the source code, you can help us by submitting an issue to our GitHub Repository. Even better, you can submit a Pull Request with a fix.
You can request a new feature by submitting an issue to our GitHub Repository. If you would like to implement a new feature, please submit an issue with a proposal for your work first, to be sure that we can use it. Please consider what kind of change it is:
Before you submit an issue, please search the issue tracker, maybe an issue for your problem already exists and the discussion might inform you of workarounds readily available.
We want to fix all the issues as soon as possible, but before fixing a bug we need to reproduce and confirm it. In order to reproduce bugs, we will systematically ask you to provide a minimal reproduction. Having a minimal reproducible scenario gives us a wealth of important information without going back & forth to you with additional questions.
A minimal reproduction allows us to quickly confirm a bug (or point out a coding problem) as well as confirm that we are fixing the right problem.
We will be insisting on a minimal reproduction scenario in order to save maintainers time and ultimately be able to fix more bugs. Interestingly, from our experience, users often find coding problems themselves while preparing a minimal reproduction. We understand that sometimes it might be hard to extract essential bits of code from a larger codebase but we really need to isolate the problem before we can fix it.
Unfortunately, we are not able to investigate / fix bugs without a minimal reproduction, so if we don't hear back from you, we are going to close an issue that doesn't have enough info to be reproduced.
Before you submit your Pull Request (PR) consider the following guidelines:
shell
git checkout -b feature/my-new-feature develop
shell
git commit -a
Note: the optional commit -a
command line option will automatically "add" and "rm" edited files.
shell
git push origin feature/my-new-feature
In GitHub, send a pull request to rds-r:develop
.
If we suggest changes then:
Make the required updates.
Rebase your branch and force push to your GitHub repository (this will update your Pull Request):
shell
git rebase develop -i
git push -f
That's it! Thank you for your contribution!
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository:
shell
git push origin --delete feature/my-new-feature
shell
git checkout develop -f
shell
git branch -D feature/my-new-feature
shell
git pull --ff
To ensure consistency throughout the source code, keep these rules in mind as you are working:
devtools::check()
) and result in 0 errors, 0 warnings, and 0 notes.Add the following code to your website.
For more information on customizing the embed code, read Embedding Snippets.