Skip to content

Latest commit

 

History

History
92 lines (67 loc) · 4.72 KB

CONTRIBUTING.md

File metadata and controls

92 lines (67 loc) · 4.72 KB
Raw

Contributing to studio-go-runner

studio-go-runner is an open source project.

It originated within Sentient Technologies, maintained by Cognizant Evolutionary AI team, and is now open for others to use. We hope that it offers value to those who engage with the project. 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 studio-go-runner 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 studio-go-runner source files are distributed under the permissive Apache License found in the LICENSE file.

All submissions, require review. We 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 docs/ directory. For any relatively small change - like fixing a typo or rewording something - the easiest way to contribute is directly on Github, using their web code editor.

Maintainer's Guide

studio-go-runner has subsystem maintainers; this guide is intended for them in performing their work as a maintainer.

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.