The following is a set of guidelines for contributing to edflow. These are mostly guidelines, not rules. Use your best judgment on when to apply them and always be nice to each other ❤️.
In your docstring write
.. code-block:: <language>, when showing examples.This comment is right here, because everyone seems to be doing it wrong.
This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to [email protected].
If the documentation cannot help you, feel free to contact one of the contributors.
Before you do anything, we advise you to read the documentation, it's really not that long and helps a lot.
First of all we are very happy if you are even considering to contribute. As the developer base and the user base are not that big (some say they are the same people) we welcome everyone who sees the benefits of edflow for their work.
When you are creating a bug report, please include as many details as possible. Fill out the required template, the information it asks for helps us resolve issues faster. All bugs are tracked as github issues.
Always remember to be decisive when issuing bugs:
- Use a clear and descriptive title for the issue to identify the problem.
- Describe the exact steps which reproduce the problem in as many details as possible.
- Provide specific examples to demonstrate the steps. This can be code snippets or a link to the whole project folder.
- Describe the behaviour you observed
- Explain which behavior you expected to see instead and why.
- Include details about your configuration and environment. Sometimes the devil is not in the detail but in the environment
As edflow is still work in progress, there is much to add in features, documentation etc. Feel free to propose enhancements that seem interesting/functional to you. But be patient! It might take a while to implement them. All enhancement suggestions are tracked as github issues.
As for bugs please be precise in your suggestions:
- Use a clear and descriptive title for the issue to identify the suggestion.
- Provide a step-by-step description of the suggested enhancement in as many details as possible.
- Provide specific examples to demonstrate the steps. This always supports your case as this makes it easier to understand.
- If you want to change existing features, describe the current behavior and explain which behavior you expected to see instead and why.
- Explain why this enhancement would be useful if this is not already clear from the example.
The first step is always the hardest. None of us is Linus Torvalds. This is the first open project for most of us so don't feel intimidated, we are learning, too. At least try to follow the guidelines.
Please follow these steps when contributing:
- Add notable changes to the CHANGELOG.md.
- Follow the styleguides.
- After you submit your pull request, verify that all tests are passing.
This makes working together easier for all of us.
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Reference issues and pull requests liberally after the first line
- When only changing documentation, include
[ci skip]in the commit title - Consider starting the commit message with an applicable emoji:
- 🎨
:art:when improving the format/structure of the code - 🐎
:racehorse:when improving performance - 📝
:memo:when writing docs - 🐛
:bug:when fixing a bug - 🔥
:fire:when removing code or files - 💚
:green_heart:when fixing tests - ✅
:white_check_mark:when adding tests - 🎉
:tada:when adding features
- 🎨
- Use sphinx.
- Use reStructuredText.
Just remember to use black (This is necessary to pass the tests).
Yours truly, Mimo tillbich ❤️