diff --git a/docs/contributing.md b/docs/contributing.md deleted file mode 100644 index 62157aa..0000000 --- a/docs/contributing.md +++ /dev/null @@ -1,162 +0,0 @@ -# Contributing - -In order to be able to contribute, it is important that you understand -the project layout. -This project uses the *src layout*, which means that the package code is located -at `./src/py_masstranfer`. - -For my information, check the official documentation: -https://packaging.python.org/en/latest/discussions/src-layout-vs-flat-layout/ - -In addition, you should know that to build our package we use -[Poetry](https://python-poetry.org/), it's a Python package management tool that -simplifies the process of building and publishing Python packages. It allows us -to easily manage dependencies, virtual environments and package versions. Poetry -also includes features such as dependency resolution, lock files and publishing -to PyPI. Overall, Poetry streamlines the process of managing Python packages, -making it easier for us to create and share our code with others. - -Contributions are welcome, and they are greatly appreciated! Every little bit -helps, and credit will always be given. - -You can contribute in many ways: - -## Types of Contributions - -### Report Bugs - -Report bugs at /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. - -### Fix Bugs - -Look through the GitHub issues for bugs. Anything tagged with “bug” and -“help wanted” is open to whoever wants to implement it. - -### Implement Features - -Look through the GitHub issues for features. Anything tagged with -“enhancement” and “help wanted” is open to whoever wants to implement -it. - -### Write Documentation - -Transfer mass vizsolver could always use more documentation, -whether as part of the official Transfer mass vizsolver docs, -in docstrings, or even on the web in blog posts, articles, and such. - -### Submit Feedback - -The best way to send feedback is to file an issue at -/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 :) - -## Get Started! - -Ready to contribute? Here’s how to set up `py-masstranfer` for local development. - -1. Fork the `py-masstranfer` repo on GitHub. - -2. Clone your fork locally:: - - $ git clone git@github.com:your_name_here/py-masstranfer.git - -3. Install your local copy into a virtualenv. Assuming you have - virtualenvwrapper installed, this is how you set up your fork for - local development:: - - $ mkvirtualenv py-masstranfer - $ cd py-masstranfer/ - $ python setup.py develop - -4. Create a branch for local development:: - - $ git checkout -b name-of-your-bugfix-or-feature - - Now you can make your changes locally. - -5. When you’re done making changes, check that your changes pass flake8 - and the tests, including testing other Python versions with tox:: - - $ make lint - $ make test - - To get flake8 and tox, just pip install them into your virtualenv. - -6. Commit your changes and push your branch to GitHub:: - - $ git add . $ git commit -m “Your detailed description of your - changes.” $ git push origin name-of-your-bugfix-or-feature - -7. Submit a pull request through the GitHub website. - -## Pull Request Guidelines - -Before you submit a pull request, check that it meets these guidelines: - -1. The pull request should include tests. -2. If the pull request adds functionality, the docs should be updated. - Put your new functionality into a function with a docstring, and add - the feature to the list in README.rst. -3. The pull request should work for Python >= 3.8. - -## Tips - -To run a subset of tests:: - - - -## Release - -This project uses semantic-release in order to cut a new release -based on the commit-message. - -### Commit message format - -**semantic-release** uses the commit messages to determine the consumer -impact of changes in the codebase. Following formalized conventions for -commit messages, **semantic-release** automatically determines the next -[semantic version](https://semver.org) number, generates a changelog and -publishes the release. - -By default, **semantic-release** uses [Angular Commit Message -Conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-format). -The commit message format can be changed with the `preset` or `config` -options_ of the -[@semantic-release/commit-analyzer](https://github.com/semantic-release/commit-analyzer#options) -and -[@semantic-release/release-notes-generator](https://github.com/semantic-release/release-notes-generator#options) -plugins. - -Tools such as [commitizen](https://github.com/commitizen/cz-cli) or -[commitlint](https://github.com/conventional-changelog/commitlint) can -be used to help contributors and enforce valid commit messages. - -The table below shows which commit message gets you which release type -when `semantic-release` runs (using the default configuration): - -| Commit message | Release type | -|----------------------------------------------------------------|------------------| -| `fix(pencil): stop graphite breaking when pressure is applied` | Fix Release | -| `feat(pencil): add 'graphiteWidth' option` | Feature Release | -| `perf(pencil): remove graphiteWidth option` | Chore | -| `BREAKING CHANGE: The graphiteWidth option has been removed` | Breaking Release | - -source: - - -As this project uses the `squash and merge` strategy, ensure to apply -the commit message format to the PR's title.