Welcome to the contributor's guide for Dups open source software. If this document is open purposely by you, then you are interested in contributing to Dups, and that's really amazing! The developer welcomes all contributions ranging from use-cases, documentation, code, patches, bug reports, feature requests, etc. Contributions are not restricted to programmers only, therefore, you do not need to be a programmer to share your views about the project. Feel free to post suggestions, bugs & crashes, comments on a code in the project, or just anything that isn't as smooth as it should be as an issue on Github. If you're feeling adventurous, you're more than welcome to fork Dups repository and submit pull requests either to implement a new feature, fix a bug, or clean up the code.
If you wish to make contributions with respect to feature requests, please check the issue tracker to ascertain if the feature hasn't already been requested before by another user. If the feature has already been requested, but it is a closed issue that hasn't been marked as "wontfix", feel free to reopen the issue or create yours. To request a new feature you should open an issue.
In order to help the developer understand the feature request;
- Title of the issue should be explicit, giving insight into the content of the issue.
- The area of the project where your feature would be applied or implemented should be properly stated. Add screenshots of mockup if possible.
- It would be great if a detailed use case is included in your request.
When submitting a feature request, please make a single issue for each feature request (i.e. don't submit an issue that contains a list of features). Such issues are hard to keep track of and often get lost.
Do you have ideas of some new cool functionalities, a bug fix or other code you wish to contribute? This is the perfect section to guide you on that path.
When submitting code it is preferred to ensure the code quality is up to par (or better) than the existing one and unit-test don't fail.
Wherever possible please include tests, especially if your change implements or impacts a library routine. Even the slightest change can have a ripple effect of chaos.
For code contributions that will lead to huge operational changes, please first discuss the changes you wish to make via issue, email, or any other method before making a change.
Did you encounter an error which ultimately led to a crash while using Dups? Let the developer know about it by creating a new issue.
Filing a great bug report helps the developer pinpoint the cause of the bug and effectively work on a fix.
Before filing a bug report,
-
Ensure you're running the latest version of the software
-
Confirm if it's actually a bug and not an error caused by a plugin on your system. Test with other systems to verify
-
If the same issue persists after testing on other devices then it is indeed a bug.
-
Check the issue tracker if the bug hasn't been reported by other users. If it has been reported before it is likely to be in opened issues. Also, check closed issues too.
The most important aspect of a bug report is the details. The more concise the details, the easier it'll be for the developer or someone else to tackle the bug.
- Title of the issue should give the developer insight about what the report is all about.
- A brief explanation of the behavior you expected the software to perform.
- The actual behavior of the software when you experienced the bug.
- Steps to reproduce the bug coupled with screenshots and videos if possible.
- Test environment which is details of the Device, Operating system, Software version.
This is the creation of vital documents which a necessary for a software. Documentation also deals with written content creation. If you are copywriter this contribution category is for you.
For better implementation, ensure to create the document with markdown text styling.
Rename the file with respect to content and add .md at the end so markdown is effective.
Send a pull request after the document is created.
Here's a detailed content on how to Create a pull request
Simply put, the way to create a Pull request is first to;
- Fork the repository of the project which in this case is Dups
- Commit modifications and changes to your fork
- Send a pull request to the original repository you forked your repository from in step 1
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
Examples of behavior that contributes to creating a positive environment include:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Gracefully accepting constructive criticism
- Focusing on what is best for the community
- Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
- The use of sexualized language or imagery and unwelcome sexual attention or advances
- Trolling, insulting/derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or electronic address, without explicit permission
- Other conduct which could reasonably be considered inappropriate in a professional setting
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [email protected]. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
This Code of Conduct is adapted from the Contributor Covenant, version 1.4, available at http://contributor-covenant.org/version/1/4
Thank You for reading this far and investing in making Dups better. All contributions to this project is hugely appreciated