Skip to content

Latest commit

 

History

History
92 lines (67 loc) · 4.55 KB

CONTRIBUTING.md

File metadata and controls

92 lines (67 loc) · 4.55 KB

Contributing to duat

duat is an open source project licensed under the MIT license.

This was started in January of 2018 and has been a weekend project ever since. We appreciate your help!

Filing issues

Please check the existing issues to see if your feedback has already been reported, or your question has been answered.

When filing an issue, make sure to answer these five questions:

  1. What version of duat are you using??
  2. What command line parameters and environment variables did you use?
  3. What did you expect to see?
  4. What did you see instead?

Contributing code

Let us know if you are interested in working on an issue by leaving a comment on the issue in GitHub. This helps avoid multiple people unknowingly working on the same issue.

The help wanted label highlights issues that are well-suited for folks to jump in on. The good first issue label further identifies issues that are particularly well-sized for newcomers.

Unless otherwise noted, the duat source files are distributed under the permissive MIT license found in the LICENSE file.

All submissions, require review. Please use GitHub pull requests for this purpose. Consult GitHub Help for more information on using pull requests.

Contributing to the Documentation

All the docs reside in the README.md/ file. For any relatively small change - like fixing a typo or rewording something - the easiest way to contribute is directly on Github, using the github browser based code editor.

Maintainer's Guide

duat encourages maintainers; this guide is intended for them in performing their work.

General guidelines

  • Be kind, respectful, and inclusive.
  • The lines of responsibility between maintainership areas can be fuzzy. Get to know your fellow maintainers - it's important to work with them when an issue falls in this grey area.
  • Being a maintainer doesn't mean you're always right. Admitting when you've made a mistake keeps the code flowing, the environment health, and the respect level up.
  • It's fine if you need to step back from maintainership responsibilities - just, please, don't fade away! Let other maintainers know what's going on.

Pull Requests

  • Try to make, and encourage, smaller pull requests.
  • No is temporary. Yes is forever.
  • Long-running feature branches should generally be avoided. Discuss it with maintainers first.
  • Checklist for merging PRs:
    • Does the PR pass.
    • Are there tests to cover new or changed behavior? Prefer reliable tests > no tests > flaky tests.
    • Does the first post in the PR contain "Fixes #..." text for any issues it resolves?
    • Are any necessary follow-up issues already posted, prior to merging?
    • Does this change entail the updating of any docs?
      • For docs kept in the repo, e.g. FAQ.md, docs changes must be submitted as part of the same PR.