16 write a contribution guide

CONTRIBUTING.md

@@ -0,0 +1,71 @@
+# 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](https://github.com/CenterForOpenScience/osf-project-exporter?tab=Apache-2.0-1-ov-file).
+
+## 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](https://docs.github.com/en/get-started/using-github/github-flow) 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](https://peps.python.org/pep-0008/)
+
+- 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](https://www.conventionalcommits.org/en/v1.0.0/) 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.