[snowpatch] [PATCH 3/3] README.md: Overview of snowpatch philosophy

[Andrew Donnellan]

snowpatch is not unique when it comes to patches + CI. Add some
explanations of the overall design philosophy of snowpatch and why it's
better than alternatives for some projects.

Closes: #4 ("Document alternatives to snowpatch")
Signed-off-by: Andrew Donnellan <andrew.donnellan at au1.ibm.com>
---
 README.md | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/README.md b/README.md
index dff8dd64c8b9..f6a53e494438 100644
--- a/README.md
+++ b/README.md
@@ -17,6 +17,23 @@ At present, snowpatch supports
 [Patchwork](http://jk.ozlabs.org/projects/patchwork/) and
 [Jenkins](http://jenkins-ci.org).
 
+snowpatch is designed in line with Patchwork's philosophy of supplementing,
+rather than replacing, existing workflows. For projects which already use
+Patchwork as their core patch management tool, snowpatch does not impose any
+additional changes to the development workflow.
+
+snowpatch requires nothing more than a Patchwork account and Jenkins account
+with appropriate permissions and an API key. Many projects using patch-based
+workflows are highly decentralised, using Patchwork instances they do not
+administer, and build machines hidden behind corporate firewalls. As such,
+snowpatch is designed not to require administrator access or additional plugins
+for either Patchwork or Jenkins.
+
+snowpatch is deliberately minimalistic, which distinguishes it from tools like
+[Zuul](https://zuul-ci.org) which are more sophisticated and may be more
+appropriate for projects with a better ability to adapt their workflow around a
+comprehensive CI system.
+
 snowpatch is named in honour of
 [skiboot](https://github.com/open-power/skiboot), the project which inspired the
 creation of snowpatch.
-- 
2.11.0