Skip to content

Latest commit

 

History

History
74 lines (52 loc) · 3.6 KB

CONTRIBUTING.md

File metadata and controls

74 lines (52 loc) · 3.6 KB
Raw

How to contribute

First off, thanks for taking the time to contribute, it is encouraging! 🎉🙌

We want to make it as easy as possible to contribute changes that help the Elixir XDR library to grow and thrive. There are a few guidelines that we ask contributors to follow so that we can merge your changes quickly.

Getting started

  • Make sure you have a GitHub account.
  • Create a GitHub issue for your contribution, assuming one does not already exist.
    • Clearly describe the issue including steps to reproduce if it is a bug.
  • Fork the repository on GitHub.
  • Try to keep your local repository in a "rebased" state.
  • Set the project up.
    • Install any Elixir version above 1.7.
    • Compile dependencies: mix deps.get.
    • Run tests: mix test.

Finding things to work on

The first place to start is always looking over the current GitHub issues for the project you are interested in contributing to. Issues marked with good first issue or help wanted are usually pretty self-contained and a good place to get started.

If you see any issues that are assigned to a particular person or have the work in progress label, that means someone is currently working on that issue this issue in the next week or two.

Of course, feel free to create a new issue if you think something needs to be added or fixed.

Making changes

  • Create a topic branch from where you want to base your work.
    • This is usually the master branch.
    • Please avoid working directly on the master branch.
  • Make sure you have added the necessary tests for your changes and make sure all tests pass.
  • Make sure your code is properly formatted by running mix format.

Submitting changes

  • All content, comments, pull requests and other contributions must comply with the Code of Conduct.
  • Push your changes to a topic branch in your fork of the repository.
  • Submit a pull request.
    • Include a descriptive commit message.
    • Changes contributed via pull request should focus on a single issue at a time.
    • Rebase your local changes against the master branch. Resolve any conflicts that arise.

At this point, you're waiting on us. We like to at least comment on pull requests within three business days (typically, one business day). We may suggest some changes, improvements or alternatives.

Stale issues

To ensure that our issue tracker remains organized and relevant, we have implemented a policy for handling Stale issues. Please review the following guidelines:

  1. Marking as Stale: Issues will be automatically marked as Stale after 60 days of inactivity.
  2. Closing Stale Issues: After an issue has been marked as Stale, a comment will be posted on the issue indicating that it will be closed if there is no further activity or information provided within a specified period.

Thank you for helping us maintain a clean and efficient issue tracker!

Additional resources

Acknowledgements

This document is inspired by: