CONTRIBUTING.adoc - pulsar-client-reactive - Git at Google

 = Contributing to Reactive client for Apache Pulsar

 :github: https://github.com/apache/pulsar-client-reactive

 Reactive client for Apache Pulsar is released under the Apache 2.0 license. If you would like to contribute something, or want to hack on the code this document should help you get started.


 == Using GitHub Issues
 We use GitHub issues to track bugs and enhancements.

 If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible.
 Ideally, that would include a small sample project that reproduces the problem.

 == Reporting Security Vulnerabilities
 If you think you have found a security vulnerability in Apache Pulsar or Reactive client for Apache Pulsar please *DO NOT* disclose it publicly until we've had a chance to fix it.
 Please don't report security vulnerabilities using GitHub issues, instead head over to https://github.com/apache/pulsar/security/policy and learn how to disclose them responsibly.


 == Code Conventions and Housekeeping
 None of these is essential for a pull request, but they will all help.  They can also be
 added after the original pull request but before a merge.

 * We use the https://github.com/spring-io/spring-javaformat/[Spring JavaFormat] project to apply code formatting conventions.
   If you use Eclipse and you follow the '`Importing into eclipse`' instructions below you should get project specific formatting automatically.
   You can also install the https://github.com/spring-io/spring-javaformat/#intellij-idea[Spring JavaFormat IntelliJ Plugin] or format the code from the Gradle build by running `./gradlew format`.
 // NYI: Note that if you have format violations in `buildSrc`, you can fix them by running `./gradlew -p buildSrc format` from the project root directory.
 * The build includes Checkstyle rules for many of our code conventions. Run `./gradlew checkstyleMain checkstyleTest` if you want to check your changes are compliant.
 * Make sure all new `.java` files have a Javadoc class comment, and preferably at least a paragraph on what the class is for.
 * Add the ASF license header comment to all new `.java` files (copy from existing files in the project).
 * Add some Javadocs.
 * A few unit tests would help a lot as well -- someone has to do it.
 * Verification tasks, including tests and Checkstyle, can be executed by running `./gradlew check` from the project root.

 * If no-one else is using your branch, please rebase it against the current main branch (or other target branch in the project).
 * When writing a commit message please follow https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[these conventions].


 == Working with the Code
 For information on editing, building, and testing the code, see the link:${github}/wiki/Working-with-the-Code[Working with the Code] page on the project wiki.
	= Contributing to Reactive client for Apache Pulsar

	:github: https://github.com/apache/pulsar-client-reactive

	Reactive client for Apache Pulsar is released under the Apache 2.0 license. If you would like to contribute something, or want to hack on the code this document should help you get started.


	== Using GitHub Issues
	We use GitHub issues to track bugs and enhancements.

	If you are reporting a bug, please help to speed up problem diagnosis by providing as much information as possible.
	Ideally, that would include a small sample project that reproduces the problem.

	== Reporting Security Vulnerabilities
	If you think you have found a security vulnerability in Apache Pulsar or Reactive client for Apache Pulsar please DO NOT disclose it publicly until we've had a chance to fix it.
	Please don't report security vulnerabilities using GitHub issues, instead head over to https://github.com/apache/pulsar/security/policy and learn how to disclose them responsibly.


	== Code Conventions and Housekeeping
	None of these is essential for a pull request, but they will all help. They can also be
	added after the original pull request but before a merge.

	* We use the https://github.com/spring-io/spring-javaformat/[Spring JavaFormat] project to apply code formatting conventions.
	If you use Eclipse and you follow the '`Importing into eclipse`' instructions below you should get project specific formatting automatically.
	You can also install the https://github.com/spring-io/spring-javaformat/#intellij-idea[Spring JavaFormat IntelliJ Plugin] or format the code from the Gradle build by running `./gradlew format`.
	// NYI: Note that if you have format violations in `buildSrc`, you can fix them by running `./gradlew -p buildSrc format` from the project root directory.
	* The build includes Checkstyle rules for many of our code conventions. Run `./gradlew checkstyleMain checkstyleTest` if you want to check your changes are compliant.
	* Make sure all new `.java` files have a Javadoc class comment, and preferably at least a paragraph on what the class is for.
	* Add the ASF license header comment to all new `.java` files (copy from existing files in the project).
	* Add some Javadocs.
	* A few unit tests would help a lot as well -- someone has to do it.
	* Verification tasks, including tests and Checkstyle, can be executed by running `./gradlew check` from the project root.

	* If no-one else is using your branch, please rebase it against the current main branch (or other target branch in the project).
	* When writing a commit message please follow https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html[these conventions].



	== Working with the Code
	For information on editing, building, and testing the code, see the link:${github}/wiki/Working-with-the-Code[Working with the Code] page on the project wiki.