Merge pull request #300 from publiccodenet/release-0.1.4

Release 0.1.4

AUTHORS.md

@@ -9,6 +9,7 @@
 * Boris van Hoytema
 * Mirjam van Tiel
 * Eric Herman
+* Jan Ainali
 
 Amsterdam University of Applied Sciences (AUAS), Faculty of Digital Media and Creative Industries, Lectorate of Play & Civic Media
 
@@ -39,3 +40,5 @@ Individual contributors
 * Bert Spaan
 * David Barberi
 * Paul Keller
+* Sky Bristol
+* Marcus Klaas de Vries

CHANGELOG.md

@@ -1,5 +1,14 @@
 # Version history
 
+## Version 0.1.4
+
+November 27th 2019: 🧹 the fifth draft consists mostly of additional minor fixes.
+
+* Linked License.md file.
+* Add Sky Bristol, Marcus Klaas de Vries, and Jan Ainali to authors.
+* Made punctuation more consistent, especially for bullet lists.
+* Made some minor changes to text for clarity.
+
 ## Version 0.1.3
 
 October 8th 2019: 🍂 the fourth draft only patches and fixes minor things for the autumn cleaning

CONTRIBUTING.md

@@ -4,7 +4,7 @@
 
 We understand that a standard like this can only be set in collaboration with as many public technologists, policy makers and interested folk as possible. Thus we appreciate your input, enjoy feedback and welcome improvements to this project and are very open to collaboration.
 
-We love issues and pull requests from everyone. If you're not comfortable with Github, you can email use your feedback at <info@publiccode.net>.
+We love issues and pull requests from everyone. If you're not comfortable with GitHub, you can email use your feedback at <info@publiccode.net>.
 
 ## Problems, suggestions and questions in issues
 
@@ -49,4 +49,3 @@ In fact, feel free to open a PR to add your name to the [`AUTHORS`](AUTHORS.md)
 ---
 
 For more information on how to use and contribute to this project, please read the [`README`](README.md).
-)

README.md

@@ -1,6 +1,6 @@
 # Standard for Public Code
 
-![version 0.1.3](https://img.shields.io/badge/version-0.1.3-red.svg)
+![version 0.1.4](https://img.shields.io/badge/version-0.1.4-red.svg)
 
 Request for contributions
 
@@ -12,7 +12,7 @@ The standard lives at [standard.publiccode.net](https://standard.publiccode.net/
 
 ## Help improve this standard
 
-We are looking for people like you to [contribute](CONTRIBUTING.md) to this project by suggesting improvements and helping develop it. 😊 Get started by reading our [contributors guide](CONTRIBUTING.md). Since it is such a core document we will accept contribution when they add significant value. We've described how we govern the standard in the [governance statement](GOVERNANCE.md).
+We are looking for people like you to [contribute](CONTRIBUTING.md) to this project by suggesting improvements and helping develop it. 😊 Get started by reading our [contributors guide](CONTRIBUTING.md). Since it is such a core document we will accept contributions when they add significant value. We've described how we govern the standard in the [governance statement](GOVERNANCE.md).
 
 Please note that this project is released with a [contributor code of conduct](CODE_OF_CONDUCT.md). By participating in this project you agree to abide by its terms. Please be lovely to all other community members.
 
@@ -46,9 +46,8 @@ weasyprint http://localhost:4000/print.html standard.pdf
     - [ ] Inside pages PDF
 4. Create GitHub release with the release notes and version number
 
-## license
+## License
 
 © [The authors and contributors](AUTHORS.md)
 
-licensed under the CC-0, including all illustrations and documentation. This means anyone can do anything with it. If you contribute you also grant these rights to others.
-You can read more about how to help in the [contributing guide](CONTRIBUTING.md)
+The standard is [licensed](LICENSE.md) under CC 0, which also applies to all illustrations and the documentation. This means anyone can do anything with it. If you contribute you also grant these rights to others. You can read more about how to help in the [contributing guide](CONTRIBUTING.md)

_config.yml

@@ -1,5 +1,5 @@
 title: Standard for Public Code
-version: 0.1.3
+version: 0.1.4
 
 remote_theme: publiccodenet/jekyll-theme
 include:

criteria/advertise-maturity.md

@@ -5,14 +5,14 @@ order: 14
 
 ## Requirements
 
-* A codebase MUST be versioned
-* A codebase that is ready to use MUST only depend on other codebases that are also ready to use
+* A codebase MUST be versioned.
+* A codebase that is ready to use MUST only depend on other codebases that are also ready to use.
 * A codebase that is not yet ready to use MUST have one of these labels:
-    * prototype - to test the look and feel, and to internally prove the concept of the technical possibilities
-    * alpha - to do guided tests with a limited set of users
-    * beta - to open up testing to a larger section of the general public, for example to test if the codebase works at scale
-    * pre-release version - code that is ready to be released but hasn't received formal approval yet
-* A codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`
+    * prototype - to test the look and feel, and to internally prove the concept of the technical possibilities,
+    * alpha - to do guided tests with a limited set of users,
+    * beta - to open up testing to a larger section of the general public, for example to test if the codebase works at scale,
+    * pre-release version - code that is ready to be released but hasn't received formal approval yet.
+* A codebase SHOULD contain a log of changes from version to version, for example in the `CHANGELOG`.
 
 ## Why this is important
 
@@ -24,26 +24,26 @@ Clearly signalling a codebase's maturity helps others to decide whether to reuse
 
 ## How to test
 
-* The codebase has a strategy for versioning which is documented
-* It is clear where to get the newest version
-* The codebase doesn't depend on any codebases marked with a less mature status
+* The codebase has a strategy for versioning which is documented.
+* It is clear where to get the newest version.
+* The codebase doesn't depend on any codebases marked with a less mature status.
 
 ## Policy makers: what you need to do
 
-* When developing policy, understand that any code developed needs to be tested and improved before it can be put into service
-* Consider versioning policy changes, especially when they trigger new versions of the source code
+* When developing policy, understand that any code developed needs to be tested and improved before it can be put into service.
+* Consider versioning policy changes, especially when they trigger new versions of the source code.
 
 ## Management: what you need to do
 
 * Make sure that services only rely on codebases of equal or greater maturity than the service. For example, don't use a beta codebase in a production service or a prototype codebase in a beta service.
 
 ## Developers and designers: what you need to do
 
-* Add a prominent header to every interface that indicates the maturity level of the code
-* Version all releases
+* Add a prominent header to every interface that indicates the maturity level of the code.
+* Version all releases.
 
 ## Further reading
 
-* [Service Design and Delivery Process](https://guides.service.gov.au/topics/service-design-delivery-process/) by the Australian Digital Transformation Agency
-* [Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-delivery) by the UK Government Digital Service
-* [What are the Discovery, Alpha, Beta and Live stages in developing a service? [Video 0'0"59]](https://www.youtube.com/watch?v=_cyI7DMhgYc) by the UK Government Digital Service
+* [Service Design and Delivery Process](https://guides.service.gov.au/topics/service-design-delivery-process/) by the Australian Digital Transformation Agency.
+* [Service Manual on Agile Delivery](https://www.gov.uk/service-manual/agile-delivery) by the UK Government Digital Service.
+* [What are the Discovery, Alpha, Beta and Live stages in developing a service? [Video 0'0"59]](https://www.youtube.com/watch?v=_cyI7DMhgYc) by the UK Government Digital Service.

criteria/bundle-policy-and-code.md

@@ -6,45 +6,45 @@ order: 2
 
 ## Requirements
 
-* A codebase MUST include the policy that the source code is based on
-* A codebase MUST include all source code that the policy is based on
-* All policy and source code that the codebase is based on MUST be documented, reusable and portable
-* Policy SHOULD be provided in machine readable and unambiguous formats
-* Continuous integration tests SHOULD validate that the source code and the policy are executed coherently
+* A codebase MUST include the policy that the source code is based on.
+* A codebase MUST include all source code that the policy is based on.
+* All policy and source code that the codebase is based on MUST be documented, reusable and portable.
+* Policy SHOULD be provided in machine readable and unambiguous formats.
+* Continuous integration tests SHOULD validate that the source code and the policy are executed coherently.
 
 ## Why this is important
 
 This makes sure access is guaranteed to both the source code and the policy documents to facilitate effective reuse of a codebase.
 
 ## What this does not do
 
-* Guarantee that a codebase will reflect the bundled policy
-* Make sure packages comply with the local technical infrastructure or legal framework of a given public organization
+* Guarantee that a codebase will reflect the bundled policy.
+* Make sure packages comply with the local technical infrastructure or legal framework of a given public organization.
 
 ## How to test
 
-* Policy is provided in machine readable and unambiguous formats
-* Continuous integration tests validate that the source code and policy are executed coherently
+* Policy is provided in machine readable and unambiguous formats.
+* Continuous integration tests validate that the source code and policy are executed coherently.
 
 ## Policy makers: what you need to do
 
-* Collaborate with developers and designers to ensure there is no mismatch between policy code and source code
-* Document policy in formats that are unambiguous and machine readable such as [Business Process Model and Notation](http://www.bpmn.org/), [Decision Model and Notation](https://www.omg.org/dmn/) and [Case Management Model Notation](https://www.omg.org/cmmn/)
-* Track policy with [the same version control](version-control-and-history.md) and documentation used to track source code
-* Check in regularly to understand how the non-policy code in the codebase has changed and whether it still matches the intentions of the policy
+* Collaborate with developers and designers to ensure there is no mismatch between policy code and source code.
+* Document policy in formats that are unambiguous and machine readable such as [Business Process Model and Notation](http://www.bpmn.org/), [Decision Model and Notation](https://www.omg.org/dmn/) and [Case Management Model Notation](https://www.omg.org/cmmn/).
+* Track policy with [the same version control](version-control-and-history.md) and documentation used to track source code.
+* Check in regularly to understand how the non-policy code in the codebase has changed and whether it still matches the intentions of the policy.
 
 ## Management: what you need to do
 
-* Keep policy makers, developers and designers involved and connected throughout the whole development process
-* Make sure policy makers, developers and designers are working to the same objectives
+* Keep policy makers, developers and designers involved and connected throughout the whole development process.
+* Make sure policy makers, developers and designers are working to the same objectives.
 
 ## Developers and designers: what you need to do
 
-* Become familiar with and be able to use the process modelling notation that the policy makers in your organization use
-* Work together with policy makers to ensure there is no mismatch between policy code and source code
-* Give feedback on how to make policy documentation more clear
+* Become familiar with and be able to use the process modelling notation that the policy makers in your organization use.
+* Work together with policy makers to ensure there is no mismatch between policy code and source code.
+* Give feedback on how to make policy documentation more clear.
 
 ## Further reading
 
-* [Free online tools for building BPMN, CMMN and DMN diagrams at bmpn.io](https://bpmn.io/) by Camunda
-* [BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by Trisotech
+* [Free online tools for building BPMN, CMMN and DMN diagrams at bmpn.io](https://bpmn.io/) by Camunda.
+* [BPMN Quick Guide](https://www.bpmnquickguide.com/view-bpmn-quick-guide/) by Trisotech.