Skip to content

Latest commit

 

History

History
98 lines (77 loc) · 4.83 KB

CONTRIBUTING.adoc

File metadata and controls

98 lines (77 loc) · 4.83 KB
Raw

Contributing to ServiceTalk

Welcome to the ServiceTalk community, and thank you for contributing! The following guide outlines the basics of how to get involved. Pull requests to update and expand this guide are welcome.

Before you get started

Community Guidelines

We want the ServiceTalk community to be as welcoming and inclusive as possible, and have adopted a Code of Conduct that we ask all community members to read and observe.

Project Licensing

By submitting a pull request, you represent that you have the right to license your contribution to Apple and the community, and agree by submitting the patch that your contributions are licensed under the Apache 2.0 license.

Governance and Decision-Making

See Governance for more details.

Contributing

Scope of the ServiceTalk Organization

For more information about which contributions are applicable for the ServiceTalk organization see Governance.

Opening a Pull Request

We love Pull Requests! For minor changes, like typos or small bug fixes, feel free to open up a Pull Request (PR) directly. For larger feature development and any changes that may require community discussion, we ask that you discuss your ideas on a GitHub issue prior to opening a PR, and then reference that issue within your PR comment. You can also check all existing issues or good first issue / help wanted labels for some known ideas.

All Pull Requests must be open from a fork by clicking a Fork button in the top-right corner of the GitHub page. For minor PRs made by editing files directly through GitHub UI the forking happens automatically.

CI will run tests against the PR and post the status back to GitHub.

Writing a Patch

A good ServiceTalk patch is:

  • Concise, and contains as few changes as needed to achieve the end result.

  • Tested, ensuring that any tests provided failed before the patch and pass after it.

  • Documented, adding API documentation as needed to cover new functions and properties.

  • Accompanied by a great commit message, using our Commit Message Template.

Checklist

Please use the following checklist before pushing your commits or issuing a pull request:

  • Did you rebase your pull request against the HEAD of the target branch and fix all conflicts?

  • Does your work build without any failure when you run ./gradlew build from shell?

  • Does your commit message or pull request description follow our Commit Message Template?

Commit Message Template

We require that your commit messages match our template. The easiest way to do that is to get git to help you by explicitly using the template. To do that, cd to the root of our repository and run:

git config commit.template .git.commit.template

Project Communication Requirements

For consistency and clarity reasons we use the following standards in all ServiceTalk communications:

  • Remember that you are communicating with an international audience; strive for simplicity and clarity in your writing with minimal jargon.

  • Modern American English spellings, grammar, and idioms should be used for all documentation, commit messages, and release notes.

  • Prefer only ISO 8601 / IETF RFC 3339 date and time formats.

  • Where necessary, prefer Metric (SI) units.

  • Prefer https URLs and URLs that do not redirect to a different URL.

Reporting Issues

Issues may be reported through GitHub issues.

Please be sure to include:

  • The ServiceTalk version

  • The OS version and the output of uname -a

  • Java version, output of java -version

  • Contextual information (e.g. what you were trying to achieve with ServiceTalk)

  • Simplest possible steps to reproduce

    • A pull request with a failing test case is preferred, but it’s fine to paste the test case into the issue description

  • Anything else that might be relevant in your opinion, such as network configuration

Security issues

To report a security issue, please DO NOT start by filing a public issue; instead send a private email to [email protected].