I would once again exhort everyone making these kinds of comment to actually read the code, and to comment on Jira. Preferably with a justification by reference to the code for how or why it would improve the patch.
As far as a design document is concerned, it’s very unclear what is being requested. We already had plans, as Jordan knows, to produce a wiki page for posterity, and a blog post closer to release. However, I have never heard of this as a requirement for review, or for commit. We have so far taken two members of the community through the patch over video chat, and would be more than happy to do the same for others. So far nobody has had any difficulty getting to grips with its structure. If the project wants to modify its normal process for putting a patch together, this is a whole different can of worms, and I am strongly -1. I’m not sure what precedent we’re trying to set imposing arbitrary constraints pre-commit for work that has already met the project’s inclusion criteria. > On 12 Apr 2019, at 18:58, Pavel Yaskevich <pove...@gmail.com> wrote: > > I haven't actually looked at the code