Add an og:image meta tag

[rails.git] / README.md

diff --git a/README.md b/README.md
index edad66cc0c712f718d9e5d422233edbd936dfa24..f22e30011b2e7dcfde54aeba76f2e20dfe2820bb 100644 (file)
--- a/README.md
+++ b/README.md
@@ -17,7 +17,8 @@ There are some non-Rails services which the site includes, for
 example; tiles, geocoding, GPX file loading. There are also some
 utilities which provide other services on the OpenStreetMap site,
 or improve its function, but are not integrated with the Rails 
-port, for example; Osmosis, CGImap.
+port, for example; [Osmosis,](http://wiki.openstreetmap.org/wiki/Osmosis) 
+[CGImap.](https://github.com/zerebubuth/openstreetmap-cgimap)
 
 # License
 
@@ -41,7 +42,10 @@ will be a better place to start.
 Anybody hacking on the code is welcome to join the
 [rails-dev](http://lists.openstreetmap.org/listinfo/rails-dev) mailing
 list where other people hacking on the code hang out and will be happy
-to help with any problems you may encounter.
+to help with any problems you may encounter. If you are looking for a
+project to help out with, please take a look at the list of 
+[Top Ten Tasks](http://wiki.openstreetmap.org/wiki/Top_Ten_Tasks) that
+EWG maintains on the wiki.
 
 There are also weekly IRC meetings, at 1800 GMT on Mondays in #osm-ewg on
 the OFTC network where questions can be asked and ideas discussed. For more 
@@ -60,7 +64,7 @@ helpful as a reference.
 ## Coding style
 
 When writing code it is generally a good idea to try and match your
-formatting to hat of any existing code in the same file, or to other
+formatting to that of any existing code in the same file, or to other
 similar files if you are writing new code. Consistency of layout is
 far more important that the layout itself as it makes reading code
 much easier.
@@ -104,7 +108,7 @@ and why it should be the way it is.
 When you submit patches, the project maintainer has to read them and
 understand them. This is difficult enough at the best of times, and
 misunderstanding patches can lead to them being more difficult to
-merge. To help wit this, when submitting you should:
+merge. To help with this, when submitting you should:
 
 * Split up large patches into smaller units of functionality.
 * Keep your commit messages relevant to the changes in each individual