Codify in checklist form the steps to take while reviewing a new image

This is a starting point to try and put these check points into something somewhat more formal such that we're less likely to forget a step.

NEW-IMAGE-CHECKLIST.md

@@ -0,0 +1,10 @@
+# Checklist for Review
+
+- [ ] associated with or contacted upstream?
+- [ ] does it fit into one of the common categories? ("service", "language stack", "base distribution")
+- [ ] is it reasonably popular, or does it solve a particular use case well?
+- [ ] does a [documentation](https://github.com/docker-library/docs/blob/master/README.md) PR exist? (should be reviewed and merged at roughly the same time so that we don't have an empty image page on the Hub for very long)
+- [ ] dockerization review for best practices and cache gotchas/improvements (ala [the official review guidelines](https://github.com/docker-library/official-images/blob/master/README.md#review-guidelines))?
+- [ ] 2+ dockerization review?
+- [ ] existing official images have been considered as a base? (ie, if `foobar` needs Node.js, has `FROM node:...` instead of grabbing `node` via other means been considered?)
+- [ ] if `FROM scratch`, tarballs only exist in a single commit within the associated history?

README.md

@@ -27,6 +27,8 @@ Also, the Hub descriptions for these images are currently stored separately in t
 
 Because the official images are intended to be learning tools for those new to Docker as well as the base images for advanced users to build their production releases, we review each proposed `Dockerfile` to ensure that it meets a minimum standard for quality and maintainability. While some of that standard is hard to define (due to subjectivity), as much as possible is defined here, while also adhering to the "Best Practices" where appropriate.
 
+A checklist which may be used by the maintainers during review can be found in [`NEW-IMAGE-CHECKLIST.md`](NEW-IMAGE-CHECKLIST.md).
+
 #### Maintainership
 
 Version bumps and security fixes should be attended to in a timely manner.