-
-
Notifications
You must be signed in to change notification settings - Fork 51
Community Guide
In our community, we follow our Code of Conduct and ask everybody who likes to participate to act accordingly.
- Mastodon: Follow us on Mastodon to receive recent news about go-mail
- go-mail discussion forum: Receive announcements and start discussions about go-mail.
- Github issues: If you have a bug to report or feature to request, please use GitHub issues. Please respect the rules specified in each repository's issue template.
- Discord: A place for go-mail devs and users to meet and chat in real time.
- Slack: In case you prefer Slack over Discord.
go-mail is an open-source, community-driven project. We welcome anyone to join us in contributing to the project. This guide is aimed at anyone wishing to get familiar with the project and the development processes.
We are always keen to add features to go-mail. The process for adding new features are as follows:
- Check the issue section on Github for available issues with the "TODO" or "help wanted" tag
- If no open "TODO"/"help wanted" issue is found or the feature you have in mind is not covered, please open a proposal issue for that specific feature and wait for the "OK" from the project maintainers
- Before developing, check that the issue includes the following information:
- The purpose of the enhancement
- What is out of scope for the enhancement
- If the issue does not include this information, feel free to request the information from the person who opened the issue. Sometimes placeholder issues are created and require more details
- Comment on the issue stating if you wish to develop the feature
- Clone the repository and create a branch with the format
feature/<issue_number>_<issue_title> - New features often require documentation so please ensure you have also added or updated the documentation as part of the changes
- Please make sure that your code has the required test coverage
- Once the feature is ready for testing, create a draft PR. Please ensure the PR description has the test scenarios and test cases listed with checkmarks, so that others can know what still needs to be tested
- Once all the testing is completed, please update the status of the PR from draft and leave a message
Important
Any PRs opened without a corresponding issue might get rejected.
The process for fixing bugs are as follows:
- Check the Github issues and select a bug to fix
- Before developing, check that the issue includes the following information:
- The scope of the issue including platforms affected
- The steps to reproduce. Sometimes bugs are opened that are not go-mail issues and the onus is on the reporter to prove that it is a go-mail issue with a minimal reproducible example
- If the issue does not include this information, feel free to request the information from the person who opened the issue
- Comment on the issue stating you wish to develop a fix
- Clone the repository and create a branch with the format
bugfix/<issue_number>_<issue_title> - Once the fix is ready for testing, create a draft PR. Please ensure the PR description has the test scenarios and test cases listed with checkmarks, so that others can know what still needs to be tested
- Once all the testing is completed, please update the status of the PR from draft and leave a message.
Note
There is nothing stopping you from opening a issue and working on it yourself, but please be aware that all bugfixes should be discussed as the approach may have unintended side effects.
Important
Any PRs opened without a corresponding issue might get rejected.
Testing is vitally important to ensure quality in the project. There are a couple of scenarios where testing can really help the project:
- Testing if a bug is reproducible on your local system
- Testing PRs to ensure that they work correctly
If you chose to test if someone's bug report is reproducible on your local system, then feel free to add a comment on the issue confirming this with the output of your test program.
To test PRs, choose a PR to test and check if the PR description has the testing scenarios listed. If not, please ask the person who opened the PR to provide that list. Once you have determined a valid test scenario, please report your findings on the PR.
If you ever need more clarity or help on testing, please ask a question in the Github forum or on Discord/Slack.
While we require proper GoDoc documenation comments in the code, this Wiki is meant as more in-depth documenation of features and the project itself.
Since documenattion is hard and the Wiki is still in an incomplete state, any contribution to this is greatly appreciated. Features without documentation are condidered "unfinished" to the project, it's as important as the code.
A great way to contribute to the project is to help others who are experiencing difficulty. This is normally reported as a issue or as a message on Discord/Slack. Even just clarifying the issue can really help out. Sometimes, when an issue is discussed and gets resolved, we create a guide out of it to help others who face the same issues.
Thanks to our wonderful friends at HelloTux we can offer great go-mail merchandising. All merch articles are embroidery to provide the best and most long-lasting quality possible.
If you want to support the open source community and represent your favourite Go mail library with some cool drip, check out our merch shop at: https://www.hellotux.com/go-mail.
Socials: go-mail on Mastodon | #go-mail on Discord | #go-mail on Slack