Contributing to Socket Address
Socket Address welcomes contributions from everyone. Here are the guidelines if you’re thinking of helping out.
Where to Start
Contributions to Socket Address should be made in the form of GitHub pull requests. Each PR will be reviewed by a core contributor (someone with permission to approve patches) and either merged, or given feedback for changes that would be required.
The project uses the GitHub issue tracker to organize all known bugs, feature requests, community questions, etc. Some issues are easier than others, and we try to apply the Effort: Low label to those issues.
If you’d like to work on an issue, please leave a comment so we can assign the issue to you. This is to prevent duplicated efforts from contributors on the same issue. We’re glad to mentor contributors as well, so if you’d like some guidance or clarification, just ask!
Development
Socket Address follows the “Fork & Pull” model of development, so once you have installed Elixir, you should fork this repository and then create a local clone of your fork.
You can then download the application dependencies and run the tests via the following commands:
$ mix deps.get
$ mix test
…add the --trace
option to the test command to run with detailed reporting.
To explore the project in Elixir’s interactive shell, run the following command:
$ iex -S mix
Reporting Issues
Follow these steps for filing useful bug reports:
- Figure out how to reproduce the bug.
- Make sure your software is up-to-date to see whether the bug has already been fixed.
- Check if the bug has already been reported in the issue tracker.
- Finally, open a new issue and provide detailed information regarding the bug and your environment.
Your report should minimally include:
- the precise steps to reproduce the bug
- the expected results and actual results
- the versions of software you’re running
If you have multiple issues, please file separate bug reports.
Issue Labels
Here is the full list of labels that Socket Address uses and what they stand for:
Tag | Description |
---|---|
Effort: Low | An issue that should require a relatively low amount of effort to resolve. A great choice for a new contributor looking to get their feet wet! |
Effort: High | An issue that will take a decent amount of work, but is likely to have a bigger impact on the project. |
Priority: Low | An issue that would be nice to resolve at some point, but is not critical. |
Priority: High | An issue that should be resolved as quickly as possible. |
Type: Bug | An issue describing unexpected or malicious behavior. |
Type: Enhancement | An issue containing a feature request or a suggestion for improvement. |
Type: Question | An issue that needs answering but does not require code changes. |
~ Duplicate | An issue that was closed because it was a duplicate of another previously-reported issue. |
~ Invalid | An issue that was closed because it could not be reproduced. |
~ Won’t Fix | An issue that was closed because the proposed change was not in line with the goals of the project. |
Conventions
Git Workflow
Please do not rewrite history (rebase/amend/etc.) once you’ve filed a pull request. At that point, the code on your branch should be considered public, and rewriting history will inhibit collaboration. Read the Branches section of Git DMZ Flow if you want a more detailed explanation.
Coding Style
Socket Address tries to follow the current conventions use by the Elixir community at large. Most style choices should be easy enough to pick up from looking at the code, but there are a couple of good style guides out there that you can use as a reference (each with slightly differing advice):
- https://github.com/lexmag/elixir-style-guide
- https://github.com/levionessa/elixir_style_guide
- https://github.com/rrrene/elixir-style-guide
…that said, don’t get too hung up on style. If there’s a major style issue with your code, we’ll suggest some fixes to make before approving your pull request. If there’s a minor style issue, it’s likely that we’ll merge your code as-is and someone might clean it up later.
We do include an .editorconfig file in order to facilitate basic formating consistency. See the EditorConfig website for details and to check if your preferred text editor is supported.