Adding learning section

Author: Tim Davies

docs/components/index.md

@@ -1396,3 +1396,45 @@ A mechanism for having optional new codelists, schema and documentation added to
 #### Related Components
 
 #### Related Patterns
+
+```eval_rst
+.. _component-dashboard:
+```
+
+### Dashboard (data publication statistics)
+
+#### Summary
+
+A single location for accessing reports on the number of publishers, status of current publication, validation errors, coverage of key fields, use of extensions and other key facts.
+
+#### Description
+
+A dashboard helps to answer questions like:
+
+* Who is publishing using the standard?
+* How many publishers are using version 1.0 or 1.1?
+* How many publishers are using this specific field?
+* What values are used in this specific field?
+* Which codelists are publishers using?
+* Which are the most common validation errors?
+* If we deprecate a particular field, which publishers will be affected?
+
+#### Examples
+
+* The [IATI Dashboard](http://dashboard.iatistandard.org/) fetches changed data on a nightly basis (based on data in the IATI registry) and builds a collection of statistical reports, as well as maintaining historical data to show change over time. 
+
+#### Prioritisation Factors
+
+#### Deprioritisation Factors
+
+#### Related Components
+
+```eval_rst
+
+* :ref:`component-registry-of-datasets`
+
+```
+
+#### Related Patterns
+
+

docs/development/documentation.md

@@ -1,5 +1,19 @@
 # Documentation
 
+Documentation is a vital part of any standard. In general, policy related open data standards need both:
+
+* **Technical reference documentation**
+
+and
+
+* **Supporting documentation** 
+
+These need to be approached differently, as the patterns below outline. 
+
+## Sphinx for documentation
+
+We make use of Sphinx to build documentation. The [sphinx-base](https://github.com/OpenDataServices/sphinx-base) project is generally used as the starting point for this. 
+
 ```eval_rst
 .. todo::
 
@@ -12,7 +26,6 @@
 
 ```
 
-
 ## Documentation patterns
 
 ```eval_rst

docs/development/licensing.md

@@ -1 +1,46 @@
-# Learning
+# Monitoring & learning
+
+It is important to monitor the adoption and use of standards: particularly those with a policy goal. Through monitoring, and reflecting on adoption, there are opportunities to identify ways to improve the standard, it's documentation and associated tools, and to develop interventions that create a thriving ecosystem of publishers and users around a standard.
+
+There are many different aspects to monitoring and learning:
+
+* **Pipeline and publishers** - tracking how many organisations have expressed interest in the standard, started adopting it, or successfully published.
+
+* **Validation** - tracking how much of the data produced is valid against the standards schema, or against additional rulesets, and identifying common interoperability issues.
+
+* **Coverage** - tracking the relative levels of use for particular fields, data elements and codelists, as well as looking at the use of extensions or additional fields in standards that support this.
+
+* **Quality and usability** - tracking whether data is clear, accurate and usable, and being put into use.
+
+* **Community** - tracking the size and levels of activity in the community around the standard, identifying whether or not a market is emerging around it, and looking at the range of contributors to standard development. 
+
+## Components
+
+The following components are often used as part of a monitoring strategy.
+
+```eval_rst
+
+* :ref:`component-online-validator`
+* :ref:`component-dashboard`
+* :ref:`component-registry-of-datasets`
+
+.. todo::
+
+```
+
+## Patterns
+
+The following approaches can form part of a monitoring strategy:
+
+* **Quality frameworks** - that can judge the 'level' of publication, and incentivise publishers to improve their data. 
+* **Setting targets** - for the number of publishers, valid data, or number of community contributions. Measuring against targets can help keep engagement and implementations on track.
+* **Individual publisher feedback reports** - offering an opportunity for regular deep-dive engagement with publishers.
+* **Tool certification** - either self-certified, or with external certification - as a means to engage tool developers, check and learn from the way data is being used. 
+
+```eval_rst
+
+.. todo::
+
+    Create patterns for each of the monitoring and learning elements
+
+```

docs/learning/index.md

@@ -1,34 +1,33 @@
 # Policy design patterns
 
-This is a list of potential 'design patterns' for Policy Related Open Data Standards. 
+This page will contain a list of potential patterns related to policy design.
 
-## Drivers
+```eval_rst
+..  todo:: 
+ 
+    ## Drivers
 
-* Translating principles into practical action
-* Focus on data usability
-* Meeting multiple user needs: aligning stakeholders
-* Building ecosystem
-* Enabling co-ordination and collaboration
+    * Translating principles into practical action
+    * Focus on data usability
+    * Meeting multiple user needs: aligning stakeholders
+    * Building ecosystem
+    * Enabling co-ordination and collaboration
 
-What problem is this addressing?
+    What problem is this addressing?
 
-What implications does this have for standards design? 
+    What implications does this have for standards design? 
 
-What implications for organizational strategy? 
+    What implications for organizational strategy? 
 
-## Methods
+    ## Methods
 
-* Monolithic standard
-* Modular standard
-* Rankings
-* Technical levels
-* Use-cases
-* Central registry
-* Central identifiers 
-* Implementation profiles
-
-
-## Discussion to foster
-
-What's the implication of these different choices? 
+    * Monolithic standard
+    * Modular standard
+    * Rankings
+    * Technical levels
+    * Use-cases
+    * Central registry
+    * Central identifiers 
+    * Implementation profiles
 
+```