This is how you can contribute to ambiR. The authors are happy to receive all forms of feedback so that we can maintain and improve the package.
Code of Conduct
By participating, that is by contributing to, or commenting on the ambiR project, you agree to abide by the code of conduct.
Raising issues
An issue can be used to propose a change to the package. There can be many reasons for opening a new issue:
- fix a bug
- modify or add documentation
- suggest new features or functions
- make corrections or additions to the AMBI species list
After creating an issue, we can collaborate on resolving problems or making changes and track progress made.
If you want to raise an issue, what should you do?
Some general principles apply, regardless of which type of issue you have. The preferred place to register an issue is in the ambiR GitHub repository
You don’t have to be an expert to do any of these things. If you have never used GitHub before, please try it out. However, we would rather receive your input and feedback by email rather than not at all. So do not feel that any of these rules are absolute.
Before you create a new issue, you should first search existing issues to make sure that the same issue has not already been recorded by someone else. This check should be made irrespective of how you intend to report the issue.
You do not need to be a registered GitHub user to view issues. However, to create a new issue directly, you will need to register as a user.
If have an issue but you do not want to register with GitHub, please contact aborja at azti.es or cjm at niva.dk. Even if you are not using GitHub to record the issue, please check first if the same or a similar issue already exists.
If you find that the issue has already been created, it is still possible to contribute with new information or comments.
When creating a new issue in GitHub, please apply a suitable label to categorise the new issue.
Read more about issues in the GiHub Docs: https://docs.github.com/en/issues/tracking-your-work-with-issues/learning-about-issues/about-issues
Corrections to species list
Issues relating to the species list should be identified by adding the ‘Species data’ label.
Examples of modifications or corrections to the species list could include:
- fixing an incorrectly spelled species name
- changing the group to which a species is allocated
- adding a species not yet on the list
Before suggestion modifications, please check that your issue does not already exist by searching specifically for issues with the ‘Species data’ label:
https://github.com/NIVA-Denmark/ambiR/issues?q=label:“Species data”
Create the new issue directly, remembering to apply the ‘Species data’ label. Alternatively, contact the package authors at aborja at azti.es or cjm at niva.dk.
Corrections will be gathered and used to update future versions of the species list. Remember that, while you are waiting for updated versions, you are free to use your own user-defined species lists, including any corrections you deem necessary.
Bugs
If you suspect that you have found a bug, your first step should be to check if someone else has already found the same issue.
The next step should be to create a minimal reproducible example or “reprex”. That is, you should strip away as much code as possible that is not related to the part you think is causing problems.
As the tidyverse team write:
“80% of the time creating an excellent reprex reveals the source of your problem. It’s amazing how often the process of writing up a self-contained and minimal example allows you to answer your own question.” https://tidyverse.org/help/#reprex
A reprex that allows others to reproduce the error you found can be included in the description of the bug when opening a new issue.
If you are familiar with pull requests, forks and development in general, you are welcome to contribute directly. Otherwise, opening a new issue so that someone else can fix the problem also helps.
And, as mentioned above, if none of that it possible, then please contact the authors by email.
Documentation
The authors have done their best to explain how the functions in ambiR should be used. We have spent time testing and trying things out on new users. However, it is not impossible that some of the explanations could be improved.
If there is something you don’t understand, or if there are parts you think could be explained more clearly, please let us know. Either by opening a new issue (please add the ‘documentation’ label) or by contacting us through other means.
Again, you are welcome to make your own contributions.
We have created the AMBI figures vignette to demonstrate how to produce a figure showing AMBI results. As explained, this is not a core feature of the AMBI package but is intended as a helpful example and to provide inspiration. If you have similar examples or ideas for vignettes, this is the place to suggest them.