Skip to content

Latest commit

 

History

History
102 lines (68 loc) · 5.48 KB

CONTRIBUTING.md

File metadata and controls

102 lines (68 loc) · 5.48 KB

Contributing to Smart-Emailing

Bonjour 👋 If you looking to contribute something to Smart-Emailing then you're at the right place! We are so grateful for all volunteers like you for contributions. And we are so exciting to welcome your contributions! But first, please take a moment to read this document in order to make the contribution process effective for everyone. Following these guidelines will help to developers and you, for time managing. So, if you ready let's make Email-Dashboard better together!

Rules of the discussions

Before start to contributing to Smart-Emailing or any open source project please don't forget to follow these rules:

  1. Using welcoming and inclusive language in your comments or discussions,
  2. Always being respectful to differing viewpoints and experiences,
  3. Gracefully accepting constructive criticism,
  4. Focusing on what is best for the community and project,
  5. Showing empathy towards other community members,
  6. Keep the language to English,
  7. And loving Superman more than Batman!

Ways to contribute

Here we are! There are many ways you can contribute to Smart-Emailing. For example:

🛠 You can report bugs you find. Also you can also fix these bugs!
💂‍♂️ You can write unit tests for Smart-Emailing.
🌐 You can translate Smart-Emailing's UI, our README and CONTRIBUTING contents into other languages or help to keep those translations up to date.
📝 You can write guide articles about usage of Smart-Emailing and help to keep it up to date.
💻 You can implement a new feature to Smart-Emailing!
📫 You can create new email templates for community.
🛠 You can help people on the issue tracker.

Getting Smart-Emailing

  1. Fork a copy of our repo
  2. Create your feature branch (git checkout -b my-new-feature)
  3. Commit your changes (git commit -am 'Add some feature')
  4. Push to the branch (git push origin my-new-feature)
  5. Create new Pull Request

Before start to contibuting don't forget, one PR per feature/fix unless you follow standard-version commit guidelines.

Issues and labels

The issue tracker is the preferred channel for bug reports, features requests and submitting pull requests. Our issue tracker utilizes several labels to help organize and identify issues. Here's what they represent:

Labels Description
bug Something isn't working!
duplicate This issue or pull request already exists!
enhancement New feature or request
help wanted Extra attention is needed!
wontfix This will not be worked on!
invalid This doesn't seem right!
question Further information is requested!

So, when you want to start contributing on this issue labels please don't forget rules of the discussions. Also when working on any issue on Github, it's a good practice to make branches that are specific to the issue you're currently working on. For instance, if you're working on an issue with a name like "NAME OF ISSUE #1234", from the master branch run the following code: git checkout -b Issue#1234. In doing so, you'll be making a branch that specifically identifies the issue at hand, and moves you right into it with the checkout flag. This keeps your main (master) repository clean and your personal workflow cruft out of sight when making a pull request.

After you've forked and cloned our repo, you can find issues to work on by heading over to our issues list.

Bug reports & fix

A bug is a curse for code! That's why good bug reports are extremely helpful for every project, so thanks! You can follow this guidelines for bug reports:

🔸 Validate and lint your code.

🔸 Use the GitHub issue search.

🔸 Check if the issue has been fixed.

And please try to be as detailed as possible in your report.

Feature requests

Good pull requests—patches, improvements, new features—are a fantastic help! That's why feature, improvements requests are welcome. But before opening a feature request, please take a moment to find out whether your idea fits with the scope and aims of the project. It's up to you to make a strong case to convince the project's developers of the merits of this feature. So, you can provide as much detail and context as possible.

But how to make changes if you're a newbie? Here is it!

First, start out on master. You can check this by using git status. Before making your changes use git pull so that you can be sure you are working on the latest version of master.

$ git pull

Then use git branch to create a new branch for doing your work. Make sure to name it something that describes your changes.

$ git branch branchName

Even though you've now created a new branch, you aren't "on" that branch yet. Switch from Master to your new branch by using git checkout

$ git checkout branchName

Then make your changes directly by editing the files. Once you're finished making changes, use git commit -m to confirm them and describe what you changed.

$ git commit fileName -m "description of my changes"

When prompted for the message, write a description of what you did. After that push the changes to Github using git push --set-upstream. That's it. Easy peasy right?