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

[Meta]

On Wednesday, 21 March 2018 at 21:25:55 UTC, Andrei Alexandrescu 
wrote:
> On 03/20/2018 06:56 PM, Meta wrote:
>> Does it make sense? In my opinion, no, but according to Andrei 
>> be has tried being less hands-on before and it resulted in 
>> measurably worse quality code in Phobos; thus, he 
>> re-established himself as the gatekeeper. I agree that it 
>> doesn't scale and think that at this point, it's probably 
>> actively hurting Phobos because a lot of good work sits for so 
>> long and eventually becomes abandoned.
>> 
>> On the other hand, it could become much worse for Phobos if he 
>> was entirely hands off and delegated its shepherding to a 
>> larger group of core contributors. A balance has to be struck 
>> somewhere... Maybe a hypothetical group like this needs to be 
>> trained by Andrei such that he can trust them to properly 
>> guide Phobos' development, and will only come to him with the 
>> really big, important stuff.
>
> Thanks for this comment (which is eerily accurate), and thanks 
> Timothee for raising the matter.
>
> It is an ongoing burden to be the decider on new API additions 
> to Phobos; indeed I have taken this responsibility because I 
> have attempted to relinquish it in the past, with negative 
> results. It is definitely not something that I prefer or enjoy, 
> and am permanently on the lookout for people with similar 
> design sensibilities to share the burden with. The door is 
> open, if not kicked off its hinges. Please take note!
>
> That said, the question of scalability is a bit misplaced. API 
> additions to Phobos are rare and long-lasting; it is entirely 
> appropriate to let them ripe a little. In contrast, various 
> improvements to Phobos - over 100 of them - only need good 
> reviews, and are obviously bottlenecked by our general lack of 
> reviewers. That's our real bottleneck. It seems appropriate to 
> ask the question why we'd ask for acceleration of API additions 
> without improving response for other work.
>
> I just reviewed https://github.com/dlang/phobos/pull/6178. As 
> I'd expected, it's good work - which is exactly the matter. 
> Good work in a submission means most review work. It's not bad 
> work, which can be easily rejected. And it's not brilliant 
> work, which can be easily accepted. The PR has bugs and quality 
> issues that any reviewer could find and provide feedback on. 
> It's not in the state where it's bottlenecked by just a stamp 
> of approval.
>
> Naming is a matter I wanted to defer having a debate on. We 
> should call the facility staticArray to prevent an imaginary 
> conversation like this:
>
> Q: "So I have a range here, how do I get an array from it?"
>
> A: "Easy, just append .array to it and you're done."
>
> Q. "Cool! Now I need a static array. Wait! Don't tell me, don't 
> tell me... staticArray is what I should look for!"
>
> A: "Um, no, sorry. That's called asStatic."
>
> Besides, [1,2].asStatic may be guessed right by a reader, but 
> myrange.asStatic!2 most likely not.
>
>
> Thanks,
>
> Andrei

Thanks. I stewed on this for a few days, and now it's 3 AM and I 
wrote a long reply but deleted it. I agree with most of what you 
you've said, and am progressively agreeing less with what I said. 
Mostly, I'm just frustrated and don't really have any good 
solutions but the PR queue keeps growing. I'll go review 
something.