[Solr Wiki] Update of "HowToContribute" by HossMan

[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 following page has been changed by HossMan:
http://wiki.apache.org/solr/HowToContribute

The comment on the change is:
stuff in back of my mind about contributing beyond just coding

------------------------------------------------------------------------------
  = How to Contribute to Solr =
  
- This document identifies the ''optimal'' steps community member can take to submit a changes or additions to the Solr code base.  Please note that these are the "optimal" steps, and community members that don't have the time or resources to do everything outlined on this page should not be discouraged from submitting their ideas "as is" per "Yonik's Law of Patches" ...
+ "Contributing" to an Apache project is about more then just writing code -- it's about doing what you can to make the project better.  There are lots of ways to contribute....
+ 
+ [[TableOfContents]]
+ 
+ = Be Involved =
+ 
+ Contributors should join the [http://lucene.apache.org/solr/mailing_lists.html Solr mailing lists].  In particular:
+    * the user list (to help others)
+    * The commit list (to see changes as they are made) 
+    * The dev list (to join discussions of changes) 
+ 
+ = Review/Improve Existing Patches =
+ 
+ If there's a Jira issue with a patch you think is really good, and works well for you -- please add a comment saying so.   if you think the patch can be made 
+ 
+ = Write/Improve User Documentation =
+ 
+ Solr can always use more/better documentation targeted at end users, most of which is in this wiki where anyone can edit it.  If you see a gap in the Solr documentation, fill it in.  Even if you don't know exactly what do say, sk on the user list and you'll probably get a lot of great responses -- talking informally about how Solr works is something lots of people tend to have time for, but aggregating all of that info into concise cohesive documentation takes a little more work/patience.
+ 
+ If there is a patch in Jira that you think is really great, writing some "user guide" style docs about how it works (or is suppose to work) in the wiki is a great way to help the patch get committed:  It helps serve as a road map for what the "goal" of the issue is, what should be possible for users to do one the issue is resolved; it helps get people who may not understand the low level details get excited about the new functionality; and it can eventually evolve into the final documentation once the code is committed.  (just make sure to link to the issue so people who find your wiki page first know it's not included in Solr's main code line yet).
+ 
+ = Contributing Code (Features, Big Fixes, Tests, etc...) =
+ 
+ This section identifies the ''optimal'' steps community member can take to submit a changes or additions to the Solr code base.  This can be new features, bug fixes optimizations of existing features, or tests of existing code to prove it works as advertised (and to make it more robust against possible future changes).
+ 
+ Please note that these are the "optimal" steps, and community members that don't have the time or resources to do everything outlined on this below should not be discouraged from submitting their ideas "as is" per "Yonik's Law of Patches" ...
  
  {{{
  A half-baked patch in Jira, with no documentation, no tests 
@@ -10, +35 @@

  }}}
  
  Just because you may not have the time to write unit tests, or cleanup backwards compatibility issues, or add documentation, doesn't mean other people don't. Putting your patch out there allows other people to try it and possibly improve it.
- 
- [[TableOfContents]]
  
  == Getting the source code ==
  
@@ -28, +51 @@

  
  == Making Changes ==
  
- Before you start, you should send a message to the [http://lucene.apache.org/solr/mailing_lists.html Solr developer mailing list] (NOte: you have to subscribe before you can post), or file a bug in [http://issues.apache.org/jira/browse/SOLR Jira].  Describe your proposed changes and check that they fit in with what others are doing and have planned for the project.  Be patient, it may take folks a while to understand your requirements.
+ Before you start, you should send a message to the [http://lucene.apache.org/solr/mailing_lists.html Solr developer mailing list] (Note: you have to subscribe before you can post), or file a bug in [http://issues.apache.org/jira/browse/SOLR Jira].  Describe your proposed changes and check that they fit in with what others are doing and have planned for the project.  Be patient, it may take folks a while to understand your requirements.
  
  Modify the source code and add some (very) nice features using your favorite IDE.[[BR]]
  
@@ -103, +126 @@

  
  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 other's suggestions into into your patch if you think they're reasonable.  Finally, remember that even a patch that is not committed is useful to the community.
  
- == Stay involved ==
  
- Contributors should join the [http://lucene.apache.org/solr/mailing_lists.html Solr mailing lists].  In particular, the commit list (to see changes as they are made), the dev list (to join discussions of changes) and the user list (to help others).
+ = Review/Improve Existing Patches =
  
+ If there's a Jira issue that already has a patch you think is really good, and works well for you -- please add a comment saying so.   If there's room for improvement (more tests, better javadocs, etc...) then make the changes and attach it as well.  If a lot of people review a patch and give it a thumbs up, that's a good sign for committers when deciding if it's worth spending time on the patch -- and if other people have already put in effort to improve the docs/tests for a patch, that helps even more.
+ 
- == Helpful Resources ==
+ = Helpful Resources =
  
  The following resources may prove helpful when developing Solr contributions.  (These are not an endorsement of any specific development tools)