2-round Phobos.std voting process

[growler]

I've been watching the module review voting take place and I 
think we could benefit from two rounds of voting to get into 
Phobos.std.

Ideally, Phobos.std should consist of battle-hardened modules 
hopefully with some real-world testing. This is where Phobos.etc, 
or the suggested dub.stdx, could help. The timeline could be 
something like this:

0.Module proposed for Phobos.etc/dub.stdx, round 1 voting begins

1.First round: Vote for Phobos.etc/dub.stdx
  * Focus on API quality and whether it is needed for 
Phobos.etc/dub.stdx
  * If the API is sound then it can be accepted into Phobos.etc.

2.In Phobos.etc
  * Module sits in Phobos.etc/dub.stdx for 12 months from the 
*last API change* to gain battle experience.

  * Improving the implementation, code quality and real-world 
testing takes place in Phobos.etc and is encouraged.

  * API changes are not acceptable. If the API needs to be changed 
the existing module stays in Phobos.etc and the new API comes in 
as a new module at step 0.

3.DMD release time
  * All Phobos.etc/dub.stdx modules with 12-month old APIs are 
considered for proposal into Phobos.std.

4.Second round: Vote for Phobos.std
  * Focuses on the code/implementation quality and whether enough 
real-world testing has occurred.

5.Accept into Phobos.std!

D has a small user-base so real-world testing will of course be 
scant. But if a module sits for 12-months in a high profile 
peer-reviewed and officially endorsed library/repository then 
people are more likely to use it.

Also these comments are not a rant aimed at the work people are 
doing. All the work done is very good and of high standards IMO. 
It is just about the process and is all my opinion of course :D

Cheers!