minor spelling, grammar, formatting cleanups

doc/index.rst

@@ -4,30 +4,30 @@ Introducing Autocrypt: E-Mail Encryption for Everyone
 **If users ask how they can secure their e-mail the answer
 should be as simple as: use an Autocrypt-enabled mail app!**
 
-**Why improve e-mail?** E-Mail has been declared dead many times but 
+**Why improve e-mail?** E-Mail has been declared dead many times but
 refuses to die. It remains the largest open federated identity and
 messaging eco-system, anchors the web, mobiles and continues to relay
 sensitive information between people and organisations. It has
-problems but do you prefer the proprietary, easy-to-track mobile phone 
+problems but do you prefer the proprietary, easy-to-track mobile phone
 number system to become the single source of digital identification?
 
 **Why a new approach to e-mail encryption?**  Encrypted e-mail has been
 around for decades, but has failed to see wide adoption outside of
 specialist communities, in large part because of difficulties with user
-experience and certification models.  Autocrypt first aims to provide 
-convenient encryption that is neither perfect nor as secure as 
+experience and certification models.  Autocrypt first aims to provide
+convenient encryption that is neither perfect nor as secure as
 traditional e-mail encryption, but is convenient enough for
-much wider adoption.  
+much wider adoption.
 
 The social Autocrypt approach
 ------------------------------
 
-The Autocrypt project is driven by a diverse group of mail app developers, 
+The Autocrypt project is driven by a diverse group of mail app developers,
 hackers and researchers who are willing to take fresh approaches, learn from
 past mistakes, and collectively aim to increase the overall encryption
 of e-mail in the net.  The group effort was born and named "Autocrypt"
-on December 17th 2016 by ~20 people during a 5-day meeting at the 
-OnionSpace in Berlin. It's a dynamic, fun process which is open to 
+on December 17th 2016 by ~20 people during a 5-day meeting at the
+OnionSpace in Berlin. It's a dynamic, fun process which is open to
 new people, influences and contributions.  See :doc:`contact channels
 and upcoming events <contact>` on how you may talk with us and who
 "we" are currently.
@@ -38,14 +38,14 @@ The technical Autocrypt approach
 
 Autocrypt uses regular e-mail messages between people to piggyback
 necessary information to allow encrypting subsequent messages; it
-adds a new "Autocrypt" e-mail header for transfering keys and 
-driving encryption behaviour. By default, key management is not visible 
+adds a new ``Autocrypt`` e-mail header for transfering public keys and
+driving encryption behaviour. By default, key management is not visible
 to users. See :doc:`features` for more technical and UI cornerstones.
 
 We are following this approach step-by-step using different "Levels"
 of implementation compliance.  Driven by usability concerns, we are
 refining and implementing :doc:`Level 0 <level0>` in several mail apps
-during spring 2017.  If you are interested to help please :doc:`join our
+during Spring 2017.  If you are interested to help please :doc:`join our
 channels and look at where we meet next <contact>`.
 
 See :doc:`contents` for an index of all docs and discussion results so far.

doc/level0.rst

@@ -6,15 +6,17 @@ to be Autocrypt-capable at Level 0.  The design of Level 0 is driven by
 usability concerns and by the realities of incremental deployment.  A user
 may use both Autocrypt-enabled mail apps and traditional plain ones
 and we'd like to avoid annoyances like unexpected unreadable mails
-while already supporting to turn on encryption explicitely.
+while supporting users who want to explicitly turn on encryption.
 
-In other words, Level 0 does not support multi-device configurations which is
-rather intended and discussed as part of Level 1.  We want to keep Level 0
-minimal enough that it's easy for developers to adopt it and we can
-start to drive efforts from real-life experiences as soon as possible.
+For ease of implementation and deployment, Level 0 does not support
+multi-device configurations.  We intend to `support the multi-device
+use case (and other features) as part of Level 1<nextsteps>`_.  We
+want to keep Level 0 minimal enough that it's easy for developers to
+adopt it and we can start to drive efforts from real-life experiences
+as soon as possible.
 
-Throughout this document, we refer to a mail apps or Mail User Agents (MUA)
-as though it was only capable of controlling a single e-mail account.  A
+Throughout this document, we refer to a mail app or Mail User Agent (MUA)
+as though it was only capable of controlling a single e-mail account.  An
 MUA that is capable of connecting to multiple e-mail accounts should
 have a separate Autocrypt state for each e-mail account it has access
 to.