[Solr Wiki] Update of "HowToContribute" by SteveRowe

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Solr Wiki" for change notification.

The "HowToContribute" page has been changed by SteveRowe:
https://wiki.apache.org/solr/HowToContribute?action=diff&rev1=119&rev2=120

Comment:
Added auto Jira patch validation info to the 'Contributing your work' section.

  In order to create a patch, just type:
  
  {{{
- git format-patch origin/master > SOLR-NNNN.patch
+ git format-patch origin/master > SOLR-NNNNN.patch
  }}}
  
- This will report all modifications done on Solr sources on your local disk and save them into the ''SOLR-NNN.patch'' file.  Read the patch file.   Make sure it includes ONLY the modifications required to fix a single issue.
+ This will report all modifications done on Solr sources on your local disk and save them into the {{{SOLR-NNNNN.patch}}} file.  Read the patch file.   Make sure it includes ONLY the modifications required to fix a single issue.
  
- Note the ''SOLR-NNN.patch'' patch file name.  Please use this naming pattern when creating patches for uploading to JIRA.  Once you create a new JIRA issue, note its name and use that name when naming your patch file.  For example, if you are creating a patch for a JIRA issue named SOLR-123, then name your patch filename SOLR-123.patch.  If you are creating a new version of an existing patch, use the existing patch's file name.
+ Note the {{{SOLR-NNN.patch}}} patch file name.  Please use this naming pattern when creating patches for uploading to JIRA.  Once you create a new JIRA issue, note its name and use that name when naming your patch file.  For example, if you are creating a patch for a JIRA issue named SOLR-12345, then name your patch filename SOLR-12345.patch.  If you are creating a new version of an existing patch, use the existing patch's file name.
  
  Please do not:
  
@@ -228, +228 @@

   * try to provide a unit test that shows a bug was indeed fixed or the new functionality truly works
  
  == Contributing your work ==
- Finally, patches should be attached to a bug report in [[http://issues.apache.org/jira/browse/SOLR|Jira]].  If you are revising an existing patch, please re-use the exact same name as the previous attachment. JIRA will automatically "gray out" the old patch and clearly mark your newly uploaded patch file as the latest (it'll be the colored link). You'll see multiple copies of your patch if you've named them identically, and this is preferred as it preserves the history of the patch which can come in handy. Since the most recent one is the only one not gray, we always know which one to use.
+ Patches should be attached to a bug report in [[http://issues.apache.org/jira/browse/SOLR|Jira]].  If you are revising an existing patch, please re-use the exact same name as the previous attachment. JIRA will automatically "gray out" the old patch and clearly mark your newly uploaded patch file as the latest (it'll be the colored link). You'll see multiple copies of your patch if you've named them identically, and this is preferred as it preserves the history of the patch which can come in handy. Since the most recent one is the only one not gray, we always know which one to use.
+ 
+ To enable automatic validation of JIRA patches, switch the issue's status to "Patch Available" by clicking on the "Submit Patch" button near the top of the page.  This will enqueue an ASF Jenkins job [[https://builds.apache.org/job/PreCommit-SOLR-Build/|PreCommit-SOLR-Build]] to run various quality checks on the patch and post a validation report as a comment (by "Lucene/Solr QA") on the issue.  Expect a delay of 12 hours or so before the patch validation job actually runs.  Note that in order for a patch file to trigger validation, its name must conform to the naming rules outlined here: [[https://yetus.apache.org/documentation/in-progress/precommit-patchnames/]]
  
  Please be patient.  Committers are busy people too.  If no one responds to your patch after a few days, please make friendly reminders.  Please incorporate others suggestions into your patch if you think they're reasonable. Remember that even a patch that is not committed is useful to the community. Supply first patch as early as possible and updated patches as often as possible during your work. This helps the rest of the community and committers to start understanding, help shaping, commenting on etc. your work throughout the entire process. Supplying a patch does not necessarily mean that it is complete and ready to be committed, it might also just be a way of communicating your idea and progress.