Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
In case you identified a security issue on the project, please report it to the e-mail address given in the security policy.
Report bugs at https://github.com/rero/rero-ils/issues.
If you are reporting a bug, please include:
- Your operating system name and version.
- Any details about your local setup that might be helpful in troubleshooting.
- Detailed steps to reproduce the bug.
Look through the GitHub issues for bugs. Anything tagged with "bug" is open to whoever wants to implement it.
Look through the GitHub issues for features. Anything tagged with "feature" or "enhancement" is open to whoever wants to implement it.
rero-ils could always use more documentation, whether as part of the official rero-ils docs, in docstrings, or even on the web in blog posts, articles, and such.
The best way to send feedback is to file an issue at https://github.com/rero/rero-ils/issues.
If you are proposing a feature:
- Explain in detail how it would work.
- Keep the scope as narrow as possible, to make it easier to implement.
- Remember that this is a volunteer-driven project, and that contributions are welcome :)
Ready to contribute? See the installation procedure to setup a local development environment.
Before you submit a pull request, check that it meets these guidelines:
- The pull request should include tests and should not decrease test coverage.
- Your code is as clear as possible and sufficiently documented (comments, docstrings, ...).
- All tests on GitHub Actions should pass before merging.
Your commit message should follow Invenio's style guide. Commit message is first and foremost about the content. You are communicating with fellow developers, so be clear and brief.
(Inspired by How to Write a Git Commit Message)
- Separate subject from body with a blank line.
- Limit the subject line to 50 characters.
- Indicate the component followed by a short description
- Do not end the subject line with a period.
- Use the imperative mood in the subject line.
- Wrap the body at 72 characters.
- Use the body to explain what and why vs. how, using bullet points.
For example:
component: summarize changes in 50 char or less * More detailed explanatory text, if necessary. Formatted using bullet points, preferably `*`. Wrapped to 72 characters. * Explain the problem that this commit is solving. Focus on why you are making this change as opposed to how (the code explains that). Are there side effects or other unintuitive consequences of this change? Here's the place to explain them. * Data Migration Instructions: if your PR makes changes to the data model or needs an action when updating an existing instance, include migration instructions (e.g. needs item reindexing, needs update mapping). It is even better if you can also include an Alembic script directly in your PR. * Use words like "Adds", "Fixes" or "Breaks" in the listed bullets to help others understand what you did. * If your commit closes or addresses an issue in the same project, you can mention it in any of the bullets after the dot (closes #XXX). If it addresses an issue from another project, mention the full issue URL (Closes https://github.com/rero/rero-ils/issues/XXX). Co-authored-by: John Doe <[email protected]>
Git signature: The only signature we use is Co-authored-by
(see above)
to provide credit to co-authors. Previously we required a Signed-off-by
signature, however this is no longer required.