Remove table from diary edit and refactor using new form styles

[rails.git] / README.md

diff --git a/README.md b/README.md
index edad66cc0c712f718d9e5d422233edbd936dfa24..c59f9f0efb7057654b91039ca776a8826fb4dd54 100644 (file)
--- a/README.md
+++ b/README.md
@@ -41,7 +41,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
 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 
 
 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 +63,7 @@ helpful as a reference.
 ## Coding style
 
 When writing code it is generally a good idea to try and match your
 ## 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.
 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 +107,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
 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
 
 * Split up large patches into smaller units of functionality.
 * Keep your commit messages relevant to the changes in each individual