does it scale to have 1 person approve of all phobos additions?

[Timothee Cour]

https://wiki.dlang.org/Contributing_to_Phobos mentions:
> Smaller additions like individual functions can be merged directly after @andralex approves


The arguments for having all changes go through one person have been
presented here [1].

However this is how I see things:

* if phobos is supposed to be batteries included
(https://forum.dlang.org/post/mfrv29$t21$1@digitalmars.com), it should
be able to grow fast; looking at past changelogs, this has not been
the case, each release only comes with a handful additions to phobos
at most.

* let's look at the D survey answers to the question 'what went wrong'
while contributing code to dlang on github:
https://github.com/wilzbach/state-of-d-2018/blob/master/13c:%20What%20went%20wrong%3F
45 answers out of 69 mentioned the review process was too slow and
PR's lingering forever after all comments are addressed. A common
theme is PR lingers while waiting for approval from leadership [2]

* This creates a vicious cycle which diminishes number of contributors
since PR review is so inefficient; as a result a bug fix / useful
addition never gets merged.

* I'm not sure if there are many examples of large projects where
every addition/symbol overload has to be approved by a single person;
this would be more bearable if response time was fast; however as
noted in survey answers, response time is often in weeks/months,
sometimes years.

pinging by email also doesn't always work: here was the response I got:
> Thanks. This will need to wait - we're busy with DConf for the time being.
if one is unavailable, one should delegate


Given all this, my recommendation would be for PR's to be merged after
all checks have passed and it was approved by 2 committers.

---

[1] https://forum.dlang.org/post/ncp5g8$20hr$1@digitalmars.com
> I just asked for a stdlib addition to be pulled back at https://github.com/D-Programming-Language/phobos/pull/4025. Such decisions are difficult because the risk is them to be interpreted as stifling creativity. That is not the case. The only reason for all library additions to go through one person/small group is to preserve a cohesive vision and style. At the opposite end, nobody wants a library that's a mishmash of styles and approaches, even if that includes some of theirs. Please make sure I know of library additions. I've been on vacation and even when I'm not I can't monitor and review all library work - it would be a full-time job that wouldn't leave me time for anything else. Please just email me directly related pull requests. I always tend to my email.

[2] here are some illustrative answers:
* PR's linger forever after all comments have been addressed; not
enough committers create a bottleneck from andrei/walter (not enough
trust/delegation); style issues are a waste of time (we should use
tooling instead); negative bias towards 'small' improvements
* Andrei Alexandrescu had way too much influence in areas outside his
core competency, too many bad decisions made for
religious/philosphical reasons relying on the "sufficently powerful
compiler" fallacy and appeal to authority
* PRs have a tendency to grow stale, especially when waiting on a
response from Walter or Andrei.
* There is sometimes a tendency for PRs to languish - sometimes for
years, particularly if there's any disagreement or if it requires
input from Walter or Andrei. Obviously, that doesn't always happen,
but it's not entirely uncommon either.
* Community is very negative.  Leadership seems very unengaged.  There
is not enough delegation/trust.
* I'd say "The whole process was an uphill battle", but that's a huge
understatement. Endless "perfect is the enemy of good".  Endless
pushback and arguing on whether things should even be done at all
(especially from MartinNowak - nothing personal, and no offense, but
that one alone doubles the amount of arguing that needs done to get
anywhere, will object to seemingly anything, and frequently just leads
the debate in circles). And long periods with no response.
* Still no response to my pull request after fixing it 2 weeks after
the initial feedback (more than a few months of waiting now)
* It's very hard to get significant improvements to D's weakest areas
accepted, because of concerns about breaking changes and/or excessive
complexity of proposed solutions. As a result, broken stuff just stays
broken.
* Mixed experience. Sometimes too much of a "don't touch our project"
attitude. (advice: give the contributing developer some ownership of
the project. Yes that means making compromises on your own opinions)