Add good and bad examples of badge implementations

spec/SPECIFICATION.md

@@ -9,6 +9,17 @@ This document specifies the visual design of Shields badges.
 - **concise**: one descriptive word on the left (the key), one piece of data on the right (the value)
 - **hyperlinked**: badges can link to a third-party website providing more information, either related to the metadata provided by the badge or about the project the badge was used for (e.g. an open source library) 
 
+### Example
+
+#### Bad
+![bad example](https://img.shields.io/badge/MySuperSaaSisSoAwesome.com-1.1.1-orange.svg)
+
+The key is shamelessly promoting the service provider instead of giving context to the value. If service providers want to promote themselves, they can simply encourage people to link back to them and let folks who are curious click on the button for more information.
+
+#### Good
+![bad example](https://img.shields.io/badge/version-1.1.1-green.svg)
+The key clearly explains what the value stands for (the version of the software provided). The platform or service hosting the version of the software is only relevant to people who decide to click on an eventual link added to the badge itself but the value stands on its own with the metadata value it provides to viewers.
+
 ## Aesthetics
 The design of our badges has been carefully considered to provide sufficient padding between the container badge and the text within. Badges should never have a fixed width. The letter spacing (or kerning) is deliberate and focused on clarity, so is the use of the Open Sans font face. Contrary to widely available web-safe alternative sans-serif fonts like Arial (a sloppy Helvetica ripoff) and Verdana (a sloppy Futura ripoff), OpenSans remains highly legible at very small sizes which is why it was chosen.