Skip to content

Latest commit

 

History

History
79 lines (54 loc) · 4.92 KB

CONTRIBUTING.md

File metadata and controls

79 lines (54 loc) · 4.92 KB
Raw

Welcome to MerokuDAO contributing guide

We love your input! It’s people like you that make it a reality for users in our community. We want to make contributing to this project as easy and transparent as possible, whether it's:

  • Reporting a bug
  • Discussing the current state of the code
  • Submitting a fix
  • Proposing new features
  • Becoming a maintainer

Read our Code of Conduct to keep our community approachable and respectable.

We Develop with Github

We use github to host code, to track issues and feature requests, as well as accept pull requests. In this guide you will get an overview of the contribution workflow from opening an issue, creating a PR, reviewing, and merging the PR.

Issues

Create a new issue

If you spot a problem with the docs, search if an issue already exists. If a related issue doesn't exist, you can open a new issue using a relevant issue form.

Great Bug Reports tend to have:

  • A quick summary and/or background
  • Steps to reproduce
    • Be specific!
    • Give sample code if you can. My stackoverflow question includes sample code that anyone with a base R setup can run to reproduce what I was seeing
  • What you expected would happen
  • What actually happens
  • Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)

People love thorough bug reports. I'm not even kidding.

Solve an issue

Scan through our existing issues to find one that interests you. You can narrow down the search using labels as filters. See Labels for more information. As a general rule, we don’t assign issues to anyone. If you find an issue to work on, you are welcome to open a PR with a fix.

Pull Requests

In general, PRs should:

  • Only fix/add the functionality in question OR address wide-spread whitespace/style issues, not both.
  • Add unit or integration tests for fixed or changed functionality (if a test suite already exists).
  • Address a single concern in the least number of changed lines as possible.
  • Include documentation in the repo or on our docs site.
  • Be accompanied by a complete Pull Request template (loaded automatically when a PR is created).

Make Changes

  1. Fork the repo and create your branch from main.
  2. If you've added code that should be tested, add tests.
  3. Ensure the test suite passes.
  4. Make sure your code lints.
  5. Commit your update. Commit the changes once you are happy with them. See Atom's contributing guide to know how to use emoji for commit messages.. Once your changes are ready, don't forget to self-review to speed up the review process:zap:.
  6. Open that PR. Don't forget to link PR to issue if you are solving one.
  • Enable the checkbox to allow maintainer edits so the branch can be updated for a merge.
  • Once you submit your PR, a contributor will review your proposal. We may ask questions or request for additional information.
  • We may ask for changes to be made before a PR can be merged, either using suggested changes or pull request comments. You can apply suggested changes directly through the UI. You can make any other changes in your fork, then commit them to your branch.
  • As you update your PR and apply changes, mark each conversation as resolved.
  • If you run into any merge issues, checkout this git tutorial to help you resolve merge conflicts and other issues.
  1. Congratulations 🎉🎉 The Meroku DAO team thanks you ✨.

Discussions

We use Discussions to brainstorm on ideas. Visit Discussions