Community guidelines ==================== Welcome and thank you for your interest in the Strengths package. Please, be respectful to each other, and maintain a safe, healthy and pleasant work environment for everyone. While the project's repository is hosted on GitHub, please make sure to respect `GitHub's code of conduct `_. Specific gidelines for the project may be added or linked here in the future. Contributing ============ Contributing to Strengths does not necessarily requires writing code on your own. Actually, reporting bugs and issues is one of the most important and valuable things you can do as it will strengthen the already existing code and features. Constructive feedbacks and suggestions are of course welcome too. You can also suggest features that you would like to see implemented. Keep in mind that the contribution also concerns the documentation. There is a lot of room for improvement there, so if you find errors or if there are some points that you feel are not well explained/detailed enough, do not hesitate to tell us, as it would be a precious help ! Reporting issues / bugs ----------------------- We're sorry if you have met bugs, errors of other inconveniences while using Strengths. If you wish to report those, you can open a issue on the project's GitHub repository. We would like you to give use as much context as possible on what the problem is and where it occurs. This includes : * A minimal example to reproduce the bug/error. and if it seems necessary * Which version of Python, Numpy, Matplotlib and Strengths you are using (if this is not the latest version, you may want to check first if the issues have been fixed in more recent versions). * Which platform (ie. OS) you are using. Requesting/suggesting features ------------------------------ If you are interested in us adding specific features to Strengths, you can open an issue on the project's GitHub repository. Giving feedbacks ---------------- We would appreciate constrictive feedbacks to the projects. You can open issues to state your mind about the package. Contributing to the documentation --------------------------------- As for the source code, the documentation can contain errors and outdated information. Reporting those would he a great help for everyone dealing with the project. As for the source code, you can also request new documentation, or propose your own contributions with a pull request. Contributing to the source code ------------------------------- If you have made some nice changes to Strengths and would like to make it part of this package, you can submit it with a pull request so that we can review it. Change made to the pre-existing interface may not be included right away (or at all) if it breaks backward-compatibility (Though backward compatibility may be a bit more fragile for the early versions of the package). New features should come with documentation and tests. Code aimed to be exposed as part of the interface should contain docstrings that will serve to generate the documentation with Sphinx. Also, make sure to respect the naming style and the terminology used in the rest of the package. ie. for a function name : * DoSomething => X * do_something => O ie. for a class name : * something => X * SOMETHING => X * Something => O ie. to refer to a chemical species * chemical => X * molecule => X * species => O Also, beware of code licences. We use a permissive MIT license, so your contribution must not contain incompatible code nor code you are not allowed to use or share. If you use code from other compatible project, be sure to include necessary references/acknowledgements and licence texts. What's next ? ------------- Since the project is still new, and we are not used to manage open source projects yet, those guidelines may evolve/extend a lot.