Issue Reporting & Template

In general, the proper format to report a GitHub Issue (e.g. bug report) on the Spring Data for Apache Geode (SDG) project should follow these guidelines:

1. Bug Description / Summary
2. Steps to Reproduce
3. Expected Outcome
4. Actual Outcome

Additionally, if you can provide any artifacts, including but not limited to: [application] configuration metadata, logs, (complete) stack traces, thread dumps, [mock] data, etc, that are relevant to the issue, especially analyzing, diagnosing or reproducing the issue, then this would be appreciated.

In addition, affected software versions (e.g. SDG version, version of Apache Geode) or any other 3rd-party (Java) libraries (and their versions) in play at the time the issue occurred are also essential to know when analyzing and debugging a problem. The best way to supply this information would be by providing a snippet of, or even the entire project Maven POM or Gradle build file.

Furthermore, Java version (i.e. JRE) is important as well. Perhaps, even the OS version, etc.

Ideally, if you can supply any tests that reproduce the issue, those are also highly appreciated and welcomed.

In conclusion...

Many problems vary greatly according to context (i.e. issues can be, and often are, environment/context-sensitive), how the software is used (i..e knowing the application Use Case (UC), requirements, SLAs and how the technology has been applied, is helpful), versions of the affected software, and so on, is all relevant in correctly understanding the problem.

Being able to reliably recreate the problem is everything when it comes to properly triaging the issue in a timely manner and arriving at the right conclusion along with the desired outcome for all affected participants.

You have our work (read, "testing") that we will make a best effort to make sure this issue will not happen again.

Feedback on this process is welcomed.