decred.org/dcrdex@v1.0.5/docs/wiki/Contribution-Guide.md (about)

     1  # Contribution Guide
     2  
     3  We welcome your contributions to dcrdex.
     4  
     5  Development is coordinated via [github issues](/../issues) and the
     6  [Matrix](https://matrix.org/)
     7  [DEX Development room](https://matrix.to/#/!EzTSRQITaqHuFBDFhM:decred.org?via=decred.org&via=matrix.org&via=zettaport.com).
     8  You can access the room at [chat.decred.org](https://chat.decred.org),
     9  [riot.im](https://riot.im), or with any other Matrix client.
    10  
    11  ## Contributing code
    12  
    13  1. Fork the repo.
    14  2. Create a branch for your work (`git checkout -b cool-stuff`).
    15  3. Code something great.
    16  4. Commit and push to your forked repo.
    17  5. Create a [pull request](https://github.com/decred/dcrdex/compare).
    18  
    19  ## Code Style (Go)
    20  
    21  - Wrap comments after 80 columns, treating tabs as being 4 spaces wide. Trailing code comments are exempt.
    22  - Try to keep code wrapped below 100 columns, but this is more of a guideline than a rule.
    23  - Document all exported symbols. Use full sentences and proper punctuation.
    24  - Justify the creation of exported types/variables/methods/functions. If it can be exported, it probably should be.
    25  - Do not use `make` to allocate 0-capacity slices (e.g. `make([]int, 0)`) unless you have a good reason. It is safe to append to a `nil` slice.
    26  - When declaring a variable with its zero value, just use `var` and not `:=`. For example, `var x int64` instead of `x := int64(0)`.
    27  - When defining `error` strings, avoid beginning with a capital letter unless it refers to an exported type or proper noun, and avoid ending with punctuation. There are exceptions, so this is not checked by a linter.
    28  
    29  ## Pull Requests (PRs)
    30  
    31  If your contribution is still in draft or a work-in-progress (WIP), create a **draft** pull request.
    32  Once your code is ready for review, click the links on the PR to make it ready for review.
    33  
    34  When pushing updates to reviewable PRs, especially in response to reviews,
    35  ensure there is an easy way to see just what was changed since your previous
    36  revisions. Either add commits, which will be squash before merge, or force push
    37  your squashed branch without changing the merge-base so that when we view the
    38  "force-pushed" diff provided by Github, it shows only what was changed in your
    39  PR. If the merge-base changes, the diff will be mixed up with whatever else was
    40  changed on master, making it more difficult to review. You may force push
    41  subsequently to rebase.
    42  
    43  ## Get paid
    44  
    45  If you are already a Decred contractor, you can charge for your development work
    46  on **dcrdex**. If you are not a Decred contractor but would like to be, you
    47  should first
    48  [familiarize yourself with the onboarding process](https://docs.decred.org/contributing/overview/).
    49  **dcrdex** is a great place to get started, but you would be expected to take on
    50  only smaller jobs until you are comfortable navigating the code and have shown
    51  the ability to communicate and follow through.