Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
71 lines (45 loc) · 3.4 KB

CONTRIBUTING.md

File metadata and controls

71 lines (45 loc) · 3.4 KB

Contributing

osfexport is an open-source project. Contributions to report bugs, suggest new features or improvements, ask questions, develop the code/documentation, and any other kind of contribution are more than welcome.

By contributing, you are agreeing that we may redistribute your work under this license.

Guidelines

The below are guidelines about how contributions should be made, and are not necessarily hard rules.

Reporting a Bug

For reporting bugs, create a new issue:

  • Describe what the bug is, what steps people can do to reproduce it, and what platform you were using osfexport on.
  • Add a bug label to the issue.

Suggesting a new Feature

Create a new issue:

  • Describe what the feature is, and why it would be useful to add to the project.
  • Add a enhancement label to the issue.

GitHub Flow

Contrbutions to code and documentation should follow the GitHub flow model in general. Key points are:

  • Feature branches should be branched off of develop or a release branch
  • All changes to be merged must have a Pull Request opened first.
  • Before submitting a pull request re-merge the source branch and resolve any merge conflicts
  • A branch should not be merged until it passes all checks and has been approved by one person.
    • Checks for linting quality and if tests pass automatically runs when pull requests are made and updated.
  • Do not merge develop if you are working off a release branch and vice versa
  • Use -'s for spaces not _'s
  • Hotfixes are to be branched off main
    • Hotfix PR should be names hotfix/brief-description
    • A hotfix for an issue involving figshare metadata when empty lists are returned would behotfix/figshare-metadata-empty
    • When hotfixes are merged a new branch will be created bumping the minor version ie hotfix/0.1.3 and the other PR will be merged into it

The naming convention for branches is: <issue-number>-<brief-issue-description>. For example, a branch for issue 5 Make tests run faster would be named 5-make-tests-run-faster.

Library Versioning

osfexport uses semantic versioning <major>.<minor>.<patch>

  • Patches are reserved for hotfixes and bugfixes only
  • Minor versions are for adding new functionality
  • Minor versions: any changes must be backwards compatible
  • Major versions can contain breaking changes

Pull Request Guidelines

All code must pass flake8 linting

  • Max line length is set 100 characters

Imports are should be ordered in pep8 style.

Keep commit histories as clean and simple as possible, with meaningful commit messages. The Conventional Commits style helps with this.

Add docstrings to explain expected inputs, outputs and errors for classes and functions. Add comments to explain why sections of code are structured like they are (and how they do it if that would be helpful.)

Add tests for new features or checking for bugs, to help verify the correctness of your changes.

Make a PR to resolve one issue only. Keep changes made to only those needed to resolve the issue. In your PR, add a link to what the PR addresses, and describe how the changes made address the issue.

Pull requests should not be merged unless all checks pass and have been approved by one human reviewer.
⚡