You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-commits@lucene.apache.org by Apache Wiki <wi...@apache.org> on 2008/05/23 20:05:51 UTC

[Solr Wiki] Trivial Update of "HowToContribute" by MikeKlaas

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 MikeKlaas:
http://wiki.apache.org/solr/HowToContribute

The comment on the change is:
spelling

------------------------------------------------------------------------------
  
  = 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.
+ 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, ask 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).
  
@@ -92, +92 @@

  svn add src/.../MyNewClass.java
  }}}
  
- Subversions "add" command only modifies your local copy, so it doess not require commit permissions.  By using "svn add", your entire comtribution can be included in a single patch file, without needing to submit a seperate set of "new" files.
+ Subversions "add" command only modifies your local copy, so it does not require commit permissions.  By using "svn add", your entire contribution can be included in a single patch file, without needing to submit a separate set of "new" files.
  
  Edit the ''CHANGES.txt'' file, adding a description of your change, including the bug number it fixes.
  
@@ -121, +121 @@

  
  == 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, pelase re-use the exact same name as the previous attachment, Jira will "grey out" the older versions so it's clear which version is the newest.
+ 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 "grey out" the older versions so it's clear which version is the newest.
  
  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.