First off, thank you for considering contributing to Express-SMTP-Mailer. It's people like you that make open-source software such a great library of resources!
Following these guidelines helps to communicate that you respect the time of the developer(s) managing and developing this open-source project. In return, I (we) will strive to reciprocate that respect in addressing your issues, assessing changes, and helping you finalize your pull requests.
Express-SMTP-Mailer is an open source project and it's great to receive contributions from the community -- you! There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be incorporated into the codebase itself.
Please, don't use the issue tracker for support questions! Instead check to see if other users have made similar inquiries in the Discussions section which might sometimes help with your issue. If your issue is more generalized, Stack Overflow is also worth considering. I (we) also will not accept breaking changes or code that doesn't follow the existing linting/styling.
Working on your first Pull Request? You can learn how from this free series, How to Contribute to an Open Source Project on GitHub.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first 😸
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's easier to merge.
- Create your own fork of the code.
- Make the changes in your fork.
- If you like the change and think the project could use it:
* Be sure you have followed the code style for the project.
- Send a pull request indicating your changes.
- Start small. Changes are the easiest form of contributions to incorporate.
As a rule of thumb, changes are obvious fixes if they do not introduce any new functionality or creative thinking. As long as the change does not affect functionality, some likely examples include the following:
- Spelling / grammar fixes
- Typo correction, white space and formatting changes
- Comment clean up
- Bug fixes that change default return values or error codes stored in constants
- Adding logging messages or debugging output
- Changes to 'metadata' files like Gemfile, .gitignore, build scripts, etc.
- Moving source files from one directory or package to another
Use the Bug Report Template on GitHub which describes the behavior you are observing, what environment you are using, and what you were expecting to happen instead.
If you find yourself wishing for a feature that doesn't exist in
express-smtp-mailer
, you are probably not alone. Use the Feature Request Template on GitHub which describes the feature you would like to see, why you need it, and how it should work.
I (we) look at Pull Requests on a regular basis in a weekly triage process that I (we) use to track order of importance. After feedback has been given I (we) expect responses within two weeks. After two weeks I (we) may close the pull request if it isn't showing any activity.
🔐🔐🔐
In order to determine whether you are dealing with a security issue, ask yourself these two questions:
- Can I access something that's not mine, or something I shouldn't have access to?
- Can I disable something for other people?
If the answer to either of those two questions is "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue, so if you're unsure, just email the author at [email protected]. 🔐🔐🔐
Here is the link to the full Security Policy.
- Create issues for any major changes and enhancements that you wish to make.
- Discuss things transparently and get community feedback.
- Keep feature versions as small as possible, preferably one new feature per version.
- Be welcoming to newcomers and encourage diverse new contributors from all backgrounds.
You can always chat with me (us) using in the Discussions area. All feedback, inquiries, and constructive criticism is welcome provided the conversation remains civil and free of derogatory or abusive verbage in accordance with the Code of Conduct
Thank you for your time and your contribution!!! 🎉🎉🎉