Skip to content

Commit 19b4947

Browse files
HarryHeightstadly
authored andcommitted
adds Contributing.md
huge thanks to @HarryHeights
1 parent def4291 commit 19b4947

File tree

1 file changed

+125
-0
lines changed

1 file changed

+125
-0
lines changed

Contributing.md

+125
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,125 @@
1+
# Contributing Guide for Dups
2+
3+
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!
4+
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.
5+
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.
6+
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. <hr>
7+
8+
### Submitting Feature Requests
9+
10+
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.
11+
To request a new feature you should [open an issue](https://github.com/linuxwhatelse/dups/issues/new).
12+
13+
In order to help the developer understand the feature request;
14+
- Title of the issue should be explicit, giving insight into the content of the issue.
15+
- The area of the project where your feature would be applied or implemented should be properly stated. Add screenshots of mockup if possible.
16+
- It would be great if a detailed use case is included in your request.
17+
18+
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. <hr>
19+
20+
## Code Contribtuion
21+
22+
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.
23+
24+
### Code Quality
25+
26+
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.
27+
28+
### Tests
29+
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.
30+
31+
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. <hr>
32+
33+
## Bug & Crash Reports
34+
35+
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.
36+
37+
Filing a great bug report helps the developer pinpoint the cause of the bug and effectively work on a fix.
38+
39+
### Steps on how to file a great bug report.
40+
41+
Before filing a bug report,
42+
- Ensure you're running the latest version of the software
43+
- Confirm if it's actually a bug and not an error caused by a plugin on your system. Test with other systems to verify
44+
- If the same issue persists after testing on other devices then it is indeed a bug. <hr>
45+
46+
- 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](https://github.com/linuxwhatelse/dups/issues). Also, check closed issues too.
47+
48+
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.
49+
50+
- Title of the issue should give the developer insight about what the report is all about.
51+
- A brief explanation of the behavior you expected the software to perform.
52+
- The actual behavior of the software when you experienced the bug.
53+
- Steps to reproduce the bug coupled with screenshots and videos if possible.
54+
- Test environment which is details of the Device, Operating system, Software version.
55+
56+
## Documentation
57+
58+
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.
59+
For better implementation, ensure to create the document with markdown text styling.
60+
Rename the file with respect to content and add ```.md``` at the end so markdown is effective.
61+
Send a pull request after the document is created.
62+
63+
## Creating a pull request
64+
65+
Here's a detailed content on how to [Create a pull request](https://help.github.com/articles/creating-a-pull-request)
66+
67+
Simply put, the way to create a Pull request is first to;
68+
69+
1. Fork the repository of the project which in this case is [Dups](https://github.com/linuxwhatelse/dups)
70+
2. Commit modifications and changes to your fork
71+
3. Send a [pull request](https://help.github.com/articles/creating-a-pull-request) to the original repository you forked your repository from in step 1
72+
73+
74+
# Contributor Covenant Code of Conduct
75+
76+
## Our Pledge
77+
78+
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.
79+
80+
## Our Standards
81+
82+
Examples of behavior that contributes to creating a positive environment include:
83+
84+
* Using welcoming and inclusive language
85+
* Being respectful of differing viewpoints and experiences
86+
* Gracefully accepting constructive criticism
87+
* Focusing on what is best for the community
88+
* Showing empathy towards other community members
89+
90+
Examples of unacceptable behavior by participants include:
91+
92+
* The use of sexualized language or imagery and unwelcome sexual attention or advances
93+
* Trolling, insulting/derogatory comments, and personal or political attacks
94+
* Public or private harassment
95+
* Publishing others' private information, such as a physical or electronic address, without explicit permission
96+
* Other conduct which could reasonably be considered inappropriate in a professional setting
97+
98+
## Our Responsibilities
99+
100+
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.
101+
102+
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. <hr>
103+
104+
## Scope
105+
106+
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. <hr>
107+
108+
## Enforcement
109+
110+
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.
111+
112+
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.
113+
<hr>
114+
115+
## Attribution
116+
117+
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
118+
119+
[homepage]: http://contributor-covenant.org
120+
[version]: http://contributor-covenant.org/version/1/4/
121+
<hr>
122+
123+
Thank You for reading this far and investing in making Dups better. All contributions to this project is hugely appreciated
124+
125+

0 commit comments

Comments
 (0)