Skip to content

Latest commit

 

History

History
80 lines (62 loc) · 3.76 KB

CONTRIBUTING.adoc

File metadata and controls

80 lines (62 loc) · 3.76 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

At project launch, ServiceTalk has a light governance structure. The intention is for the community to evolve quickly and adopt additional processes as participation grows. Stay tuned, and stay engaged! Your feedback is welcome.

Members of the Apple ServiceTalk team are part of the initial core committers helping review individual contributions; you’ll see them commenting on your pull requests. Future committers to the open source project, and the process for adding individuals in this role will be formalized in the future.

Contributing

Opening a Pull Request

We love pull requests! For minor changes, feel free to open up a 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.

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

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].