Hopefully action Graham's concerns about process.

README.rst

@@ -31,18 +31,65 @@ PEP process on python-ideas@python.org. This incrementally more public
 approach is intended to mitigate against burnout that has negatively
 affected previous WSGI overhaul approaches.
 
+Overall Process
+===============
+
+There are three broad phases planned (though as with all design work, it
+won't be strictly dileneated). That is, folk are encouraged to experiment
+with 
+
+Phase 1 - requirements
+++++++++++++++++++++++
+
+Gathering requirements. These will come from our needs, the needs of
+interop with other PEP's and of course the needs of the underlying
+HTTP/1.x,HTTP/2 and Websocket protocols. I'm allowing 3 months for this to
+ensure that we've had plenty of time for developers from Django, uWSGI and
+so on and so forth to participate. At the end of the 3 months (mid January)
+we'll stop iterating on requirements unless security or feasibility are
+involved. That is, security requirements and 'this *cannot* work'
+requirements can always be added. If and only if we've had broad input from
+the Python web community then we may finalise things earlier.
+
+Phase 2 - design
+++++++++++++++++
+
+Here we experiment with different ways of meeting the requirements from
+Phase 1. Again, we're allowing 3 months for experimentation and design work
+to take place. This needs to include proof of concept implementations that
+work in mod_wsgi, uWSGI, gunicorn etc. In mid-April, we'll pick a final
+design from the set of experiments that have taken place.
+
+Phase 3 - PEP
++++++++++++++
+
+Here we translate the final design into a PEP and enter it into the PEP
+process. This will be as fast or slow as the PEP process runs.
+
+
 Participating
 =============
 
 While we know things that are broken about WSGI, we probably don't know them
 all, so telling us about design issues or capabilities you want to see as
 issues in this respository is useful.
 
-Courteous feedback on the draft PEP as it comes together is welcomed at any
-point :). Pull requests that update it to fix issues etc are even better.
+Specifically, please open issues at
+https://github.com/python-web-sig/wsgi-ng/issues for things you want to see
+in the new protocol. Whether thats 'WSGI makes me cry because X' or 'I want
+to be able to write middleware that proxies to a remote server over zeromq'
+- all issues are welcome.
+
+Secondly, we need to experiment to find a good protocol that meets all our
+requirements. You can add experiments as pull requests against this
+repository. Experiments can be prose (e.g. a draft specification) or code
+(e.g. a test implementation of a draft specification).
 
-Writing code to implement / extend the draft we come up with is even better
-of course!
+There is *a* draft spec based on PEP-3333 in the repository already - it is
+not special or privileged - we may end up with a totally new spec rather
+than that iterated one. That said please do also submit PRs to change it in
+light of requirements or issues that need resolving. This repository is a
+community resource where we can build consensus and working code together.
 
 Current status
 ==============