principles/empathy.rst: relegate api registry idea to ticket #50

principles/empathy.rst

@@ -6,11 +6,10 @@ Developer empathy
 When it comes to APIs, developers are your users. The same principles of user-centred-design apply to the development and publication of APIs (simplicity, obviousness, fit-for-purpose etc).  Most of the other criteria in this guide are traceable to the principles of good design. Perhaps the most important criteria to be mindful of is *simplicity*: as with any other product, people simply won't use something if it is hard to use. 
 
 Hard-to-use APIs create bad public policy outcomes:
-- Potentially significant economic value will remain undiscovered or unrealised
-- Secondary markets that form around APIs (e.g. automated tax reporting software) will be less competitive, and therefore less efficient (API complexity creates barriers to market entry) 
+ * Potentially significant economic value will remain undiscovered or unrealised
+ * Secondary markets that form around APIs (e.g. automated tax reporting software) will be less competitive, and therefore less efficient (API complexity creates barriers to market entry) 
 
-To ensure dicoverability and accountability, all Government APIs will be published to a central service register (as described in Building and Publishing APIs secion [insert link]).  The service register will give developers a mechanism to provide feedback on APIs.  An API that is consistently rated as hard to use will be deemed defective and should be remediated.
 
 .. recommended::
 
-   Less than 20% of feedback rates the API as hard to use.
+   An API that is consistently rated as hard to use should be remediated. Ensure less than 20% of feedback rates the API as hard to use.