Formal Review Process

[Jesse Phillips]

Please, don't get caught up in my failure to provide a clean 
representation of the API, the more reasoning for how we are 
doing things the better the documentation.

On Tuesday, 11 June 2013 at 17:33:59 UTC, Jonathan M Davis wrote:
> If you can't create a pull reuest from what you  have,
> then the API isn't ready.

I am already aware this is your opinion. I'm looking for the 
correlation of being able create a pull request and an API being 
ready.

> It needs to be laid out in a manner that we can see what the 
> actual API would be if it were merged into Phobos.

Exactly as it is present, the only problem I see is that several 
helper packages exist and their documentation is present. Look 
again at the package list: 
https://dl.dropboxusercontent.com/u/18386187/orange_docs/Serializer.html

Now collapse core, util, and xml. Please point out to me, what of 
that does not look ready for inclusion into Phobos?

Is it because "orange" is the top package and not std?

Is it because there are 7 modules and 2 packages?

Is it because the docs were generated with CandyDoc?

I realize at this point that having documentation for the 
supporting libraries was a mistake, I'm now looking for concrete 
examples of why this would have been an issue if they had been 
hidden to begin with, or is this purely a principled stance?

Another piece of information I'm interested in, is your adamant 
request for a pull request-able code for the internal code 
review. Meaning as a Phobos maintainer you can see how the 
supporting libraries are stored? Or are you concerned that the 
public API will need to change for a 3rd party library to fit 
into Phobos?