diff --git a/README.md b/README.md
index eaf5ac5..60d020e 100644
--- a/README.md
+++ b/README.md
@@ -4,14 +4,14 @@
 ### Status
 In Alpha.
 Everything should work, but the basic structure can still change.
-Main focus is on creating more test, better coverage and stability.
+Main focus is on creating more tests, better coverage and stability.
 
 
 ### Architecture
 ![Django Q schema](http://i.imgur.com/wTIeg2T.png) 
 
 ### Usage
-Schedule the asynchronous exectution of a function by calling `async` from within your Django project.
+Schedule the asynchronous execution of a function by calling `async` from within your Django project.
 
 ```python
 async(func,*args,hook=None,**kwargs)
@@ -31,8 +31,8 @@ You can monitor basic information about all the connected clusters by running  `
 ![qmonitor command](http://i.imgur.com/5cm7hdP.png) 
 
 ###Admin integration
-Django Q registers itself with the admin page to show failed and succesful tasks.
-From there task results can be read or deleted. If neccesary, failed tasks can be reintroduced to the queue.
+Django Q registers itself with the admin page to show failed and successful tasks.
+From there task results can be read or deleted. If necessary, failed tasks can be reintroduced to the queue.
 
 ### Signed Tasks
 Tasks are first pickled to Json and then signed using Django's own signing module before being sent to a Redis list. This ensures that task packages on the Redis server can only be excuted and read by clusters and django servers who share the same secret key. 
@@ -40,18 +40,18 @@ Tasks are first pickled to Json and then signed using Django's own signing modul
 Optionally, packages can be compressed before transport by setting `Q_COMPRESSED = True `
 
 ### Pusher
-The pusher process continously checks the Redis list for new task packages and pushes them on the Task Queue.
+The pusher process continuously checks the Redis list for new task packages and pushes them on the Task Queue.
 
 ### Worker
 A worker process checks the package signing, unpacks the task, executes it and saves the return value. Irrespective of the failure or success of any of these steps, the package is then pushed onto the Result Queue. 
 
 By default Django Q spawns a worker for each detected CPU on the host system.
-This can be overridden by setting `Q_WORKERS =  n`. With *n* being the numbe of desired worker processes.
+This can be overridden by setting `Q_WORKERS =  n`. With *n* being the number of desired worker processes.
 
 ### Monitor
-The result monitor checks the Result Queue for processed packages and saves both failed and succesful packages to the Django database.
+The result monitor checks the Result Queue for processed packages and saves both failed and successful packages to the Django database.
 
-By default only the last 100 succesful packages are kept in the database.
+By default only the last 100 successful packages are kept in the database.
 This can be increased or decreased at will by settings `Q_SAVE_LIMIT = n`. With *n* being the desired number of records. 
 Set `Q_SAVE_LIMIT = 0` to save all results to the database.
 Failed packages are always saved.
diff --git a/README.rst b/README.rst
index 7cbcbf9..beaa041 100644
--- a/README.rst
+++ b/README.rst
@@ -4,12 +4,9 @@ Django Q
 A multiprocessing task queue application for Django
 ---------------------------------------------------
 
-Status
-~~~~~~
-
-In Alpha and Python 3 only (for now). Everything should work, but the
-basic structure can still change. Main focus will be put on creating
-tests now.
+|image0| ### Status In Alpha. Everything should work, but the basic
+structure can still change. Main focus is on creating more tests, better
+coverage and stability.
 
 Architecture
 ~~~~~~~~~~~~
@@ -21,7 +18,7 @@ Architecture
 Usage
 ~~~~~
 
-Schedule the asynchronous exectution of a function by calling ``async``
+Schedule the asynchronous execution of a function by calling ``async``
 from within your Django project.
 
 .. code:: python
@@ -57,8 +54,8 @@ Admin integration
 ~~~~~~~~~~~~~~~~~
 
 Django Q registers itself with the admin page to show failed and
-succesful tasks. From there task results can be read or deleted. If
-neccesary, failed tasks can be reintroduced to the queue.
+successful tasks. From there task results can be read or deleted. If
+necessary, failed tasks can be reintroduced to the queue.
 
 Signed Tasks
 ~~~~~~~~~~~~
@@ -74,7 +71,7 @@ Optionally, packages can be compressed before transport by setting
 Pusher
 ~~~~~~
 
-The pusher process continously checks the Redis list for new task
+The pusher process continuously checks the Redis list for new task
 packages and pushes them on the Task Queue.
 
 Worker
@@ -86,15 +83,15 @@ any of these steps, the package is then pushed onto the Result Queue.
 
 By default Django Q spawns a worker for each detected CPU on the host
 system. This can be overridden by setting ``Q_WORKERS =  n``. With *n*
-being the numbe of desired worker processes.
+being the number of desired worker processes.
 
 Monitor
 ~~~~~~~
 
 The result monitor checks the Result Queue for processed packages and
-saves both failed and succesful packages to the Django database.
+saves both failed and successful packages to the Django database.
 
-By default only the last 100 succesful packages are kept in the
+By default only the last 100 successful packages are kept in the
 database. This can be increased or decreased at will by settings
 ``Q_SAVE_LIMIT = n``. With *n* being the desired number of records. Set
 ``Q_SAVE_LIMIT = 0`` to save all results to the database. Failed
@@ -119,3 +116,6 @@ Todo
 ~~~~
 
 I'll add to this README while I'm developing the various parts.
+
+.. |image0| image:: https://travis-ci.org/Koed00/django-q.svg?branch=master
+   :target: https://travis-ci.org/Koed00/django-q