xref: /trunk/ns_server/deps/meck/CONTRIBUTING.md (revision 4d2b5681)
1*4d2b5681Sdave-finlay# Contributing to Meck
3*4d2b5681Sdave-finlay:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
5*4d2b5681Sdave-finlayThe following is a set of guidelines for contributing to Meck. These are just
6*4d2b5681Sdave-finlayguidelines, not rules, use your best judgment and feel free to propose changes
7*4d2b5681Sdave-finlayto this document in a pull request.
9*4d2b5681Sdave-finlay## What should I know before I get started?
11*4d2b5681Sdave-finlay### Code of Conduct
13*4d2b5681Sdave-finlayThis project adheres to the Contributor Covenant
14*4d2b5681Sdave-finlay[code of conduct](CODE_OF_CONDUCT.md). By participating, you are expected to
15*4d2b5681Sdave-finlayuphold this code. Please report unacceptable behavior to
16*4d2b5681Sdave-finlay[meck at alind dot io].
18*4d2b5681Sdave-finlay## How Can I Contribute?
20*4d2b5681Sdave-finlayYou can:
22*4d2b5681Sdave-finlay* Submit an issue (see [Reporting Bugs](#reporting-bugs))
23*4d2b5681Sdave-finlay* Suggest an enhancement (see [Suggesting Enhancements](#suggesting-enhancements))
24*4d2b5681Sdave-finlay* Submit a pull request (see [Pull Requests](#pull-requests))
26*4d2b5681Sdave-finlay### Your First Contribution
28*4d2b5681Sdave-finlayIf you want to contribute with documentation, wiki pages, examples, code or
29*4d2b5681Sdave-finlaytests and are unsure of how to start, just open an issue to start a discussion.
30*4d2b5681Sdave-finlayIt could be a proposal, a question for support or further direction or any
31*4d2b5681Sdave-finlayother feedback you might have.
33*4d2b5681Sdave-finlay### Reporting Bugs
35*4d2b5681Sdave-finlaySubmitting a good bug report will help identifying, debugging and solving an
38*4d2b5681Sdave-finlayPlease check first if any similar issues have already been reported. If so,
39*4d2b5681Sdave-finlayadd to the discussion by commenting on one of those instead.
41*4d2b5681Sdave-finlayWhen you're ready to submit a bug report you can use the
42*4d2b5681Sdave-finlay[bug report template](.github/ISSUE_TEMPLATE.md) defined in the project (it's
43*4d2b5681Sdave-finlayautomatically used whenever you create a new issue on GitHub). Make sure to
44*4d2b5681Sdave-finlayfill in which versions you are using and instructions of how to reproduce the
47*4d2b5681Sdave-finlay### Suggesting Enhancements
49*4d2b5681Sdave-finlaySuggesting enhancements doesn't have to be as structured as a bug report, but
50*4d2b5681Sdave-finlayshould still contain the motivation for the enhancement, an example use case
51*4d2b5681Sdave-finlayand some reasoning why this enhancement should go into Meck itself (reasons it
52*4d2b5681Sdave-finlayshould not might include that it works as an external library, that it is more
53*4d2b5681Sdave-finlaytest framework related than mocking related etc.)
55*4d2b5681Sdave-finlay### Pull Requests
57*4d2b5681Sdave-finlayPull requests really appreciated. To increase the chance of getting your code
58*4d2b5681Sdave-finlaymerged, make sure the pull request is small and well structured. You should
59*4d2b5681Sdave-finlayprepare your pull request to try to meet the following guidelines where it
60*4d2b5681Sdave-finlaymakes sense:
62*4d2b5681Sdave-finlay1. Squash all changes into one commit. If you have many independent changes,
63*4d2b5681Sdave-finlay   submit each in its own pull request.
64*4d2b5681Sdave-finlay2. Document any external API functions changed or added via EDoc.
65*4d2b5681Sdave-finlay3. Run the existing tests to make sure you didn't break anything.
66*4d2b5681Sdave-finlay3. Add working tests that illustrate and cover the changes, or detects an issue
67*4d2b5681Sdave-finlay   to be fixed. A good example is to create a failing test case that exposes the issue you are trying to fix, before fixing it.
68*4d2b5681Sdave-finlay4. Make sure the code and commit follow the [style guides](#styleguides).
69*4d2b5681Sdave-finlay5. (Optional) Add type specifications and run Dialyzer where it makes sense.
71*4d2b5681Sdave-finlay## Styleguides
73*4d2b5681Sdave-finlay### Commit Messages
75*4d2b5681Sdave-finlayCommit messages should be limited to 50 characters without a period on the
76*4d2b5681Sdave-finlaysubject line and be written in imperative mood.
78*4d2b5681Sdave-finlayLonger explanations should be in the body, two lines below the message, wrapped at 72 characters.
80*4d2b5681Sdave-finlaySee [How to Write a Git Commit Message](http://chris.beams.io/posts/git-commit/).
82*4d2b5681Sdave-finlay### Code
84*4d2b5681Sdave-finlay* Lines should be no longer than 80 characters. This is isn't some arbitrary
85*4d2b5681Sdave-finlay  length based on nostalgia, it's just a choice of fitting limit if you want to have several files open at once next to each other on a modern wide screen
86*4d2b5681Sdave-finlay  monitor.
87*4d2b5681Sdave-finlay* Functions should be exported one by one in their own export statement. This
88*4d2b5681Sdave-finlay  is so that one export can easily be rearranged or removed without messing
89*4d2b5681Sdave-finlay  with commas and Erlang attributes.
91*4d2b5681Sdave-finlayIf you are unsure, try to find some similar code already in the repository and
92*4d2b5681Sdave-finlaymimic that. Otherwise just submit the pull request to get some stylistic
93*4d2b5681Sdave-finlayfeedback if necessary.