Guidelines for writing good forum posts

Meta
1

The Gradle Forums are the primary support channel for the Gradle community. Users and developers of Gradle regularly monitor the forums, donating their time to solve problems and answer questions. To help everyone get the most out of the forums, here are some tips and guidelines for good posts that will increase the chance of someone taking the time to help with your question or problem and get to a resolution faster.

This is a living document. If you have suggestions for additions of modification to this content, please leave a reply or comment below.

Be polite and put some effort in

Posts that are written politely are much more likely to get responses. People are also less likely to take the time to respond to posts where the poster has not put the time in to write a good post.

It’s also polite to use correct spelling and grammar (if you can, English is not everybody’s first language) as it makes reading the post easier.

Use meaningful, specific subject lines

This is the first bit of information that is visible by other users when receiving email notifications and browsing the forums. Try to include enough information to summarise the post accurately yet succinctly. The subject line should be clear enough about the topic to grab the attention of people who may know the answer.

The following are examples of bad subjects:

  • Should this work?
  • Problem with plugin X
  • How can I do this

  • X broken

None of theses subjects convey what they are about. Here are some good examples:

  • I am getting a java.lang.ClassCastException on an imported Ant build when upgrading to milestone6.
  • Is there any way to override an extension property from gradle.properties?
  • How can I use uploadArchives without the Java plugin?

Include code samples, context, be clear and concise

  • Try to minimise the code to the smallest possible sample that illustrates the problem
  • Use code formatting features for improved readability

Provide environment info

You should always provide the Gradle version that you are using. Gradle is evolving continuously and internals can change across releases. It might be best if you simply include the output of ‘gradle -v’ which also includes other important environmental factors like OS (particularly if you are on Windows) or the Java Version.

1 Like
3

Wouldn’t it be useful if this note described the best way to include code samples, and other formatting tricks? I seem to remember seeing somewhere that you have to wrap code samples with “```” (three backticks), but I can’t confirm that. I tried that, but it appeared to remove leading spaces, which wasn’t helpful.

1 Like
4

interested am read your content