On Thursday, 16 June 2016 at 13:56:26 UTC, Steven Schveighoffer wrote:
> And there is a further problem -- Walter and Andrei are gatekeepers, but are stretched incredibly thin.

Having had some time to think about all it now, I believe this was my actual problem.

When I started working on this, I was new to the D project and, based on following the GitHub discussions and observing the voting and review process for `std.logger` and `std.ndslice`, I believed that the acceptance process for Phobos was somewhat democratic: the more people who approved of a design, the more likely it would be accepted (with, of course, substantially more weight placed on the opinions of the leadership, who at the time I identified more or less as, "those with merge rights").

Having seen the outcome of the recent auto-decoding discussion, and the way that this review effectively ended abruptly the moment that Andrei Alexandrescu decided that he didn't like my design for `checkedint` - despite a number of other people earlier speaking positively of it - I now perceive that the democratic aspects of the Phobos process are essentially advisory in nature, with little-to-no real authority attached to them.

I do not intend this as a criticism, as I am not a stickler for democracy. I do think this should be communicated clearly to future new contributors, though, to avoid confusion. (Keep in mind that I joined the project before the "all new Phobos symbols must be approved by Andrei" rule was announced.)

Anyway, I think I see things from Andrei's perspective now, and would like to apologize for taking offense, now that I understand his role better.

I will, however, be ending my participation in the D development process, as I am not personally interested in working in an environment where everything I do needs pre-approval from someone with his opinions and leadership style (this is not specifically about `checkedint`) - especially since he seems too busy to effectively manage more contributors using the current system, anyway.

I will continue to be available for follow-up on the work I have already done, and will try to finish at least some of my current pending pull requests. I wish D well, and may still post on the forums once in a while.

On 6/15/2016 8:56 PM, tsbockman wrote:
> Pull requests are routinely reviewed in an upside-down fashion:
>
> 1) Formatting
> 2) Typos
> 3) Names
> 4) Tests (and names again)
> 6) Docs (and names)
> 8) Design (and more about names)
> 9) Does this even belong in Phobos?

It's a consequence of starting to read a document cold, i.e. the first thing noticed is the formatting, then the typos, then the names, etc.

A deep understanding of the design comes much later, only after having thoroughly read it and hit all the speedbumps of typos, etc.

On Thursday, 16 June 2016 at 21:02:32 UTC, Walter Bright wrote:
> On 6/15/2016 8:56 PM, tsbockman wrote:
>> Pull requests are routinely reviewed in an upside-down fashion:
>>
>> 1) Formatting
>> 2) Typos
>> 3) Names
>> 4) Tests (and names again)
>> 6) Docs (and names)
>> 8) Design (and more about names)
>> 9) Does this even belong in Phobos?
>
> It's a consequence of starting to read a document cold, i.e. the first thing noticed is the formatting, then the typos, then the names, etc.
>
> A deep understanding of the design comes much later, only after having thoroughly read it and hit all the speedbumps of typos, etc.

Yes I understand - it's a very natural thing to do (and I have done it myself).

I think my suggestion fundamentally boils down to, "Try to communicate to submitters early on who needs to approve their change, and that they may delay addressing all the lesser issues until after their basic proposal has been (tentatively) approved."

My problem with `checkedint` was that I formed a wrong idea of whose approval I needed (interested Phobos devs collectively, versus Andrei specifically).

On 6/16/2016 6:56 AM, Steven Schveighoffer wrote:
> I understand your frustration. All I can say is, open source contributors have
> to have a thicker skin (and I'm not saying you don't). We are all human and have
> our faults, and any team in any context can have miscommunication, or
> misunderstandings. I can assure you it's not the plan to waste people's time or
> to cause frustration. Even with a mitigating plan in place, these can happen.
> Have a plan that you can control, with a viable path if the things you can't
> don't go your way.

+1

Also, if it isn't approved for Phobos, that doesn't necessarily mean the work is wasted. Dub is full of add on libraries, add it there. Approval from others is not necessary.

My own Sargon is for things I wrote that were not approved for Phobos for one reason or another:

https://www.digitalmars.com/sargon/halffloat.html

Work is wasted only when the author gives up on it.

On Thursday, 16 June 2016 at 21:52:16 UTC, Walter Bright wrote:
> https://www.digitalmars.com/sargon/halffloat.html

Your HTTPS cert seems to be broken

On 6/16/2016 2:11 PM, tsbockman wrote:
> My problem with `checkedint` was that I formed a wrong idea of whose approval I
> needed (interested Phobos devs collectively, versus Andrei specifically).

Andrei is in charge of the library and has my full support.

We've talked many times about raising the bar much higher on Phobos. It's a tough competitive environment for programming languages out there, and we should all expect the review process going forward for Phobos to be brutal.

On the other hand, getting an endorsement from Andrei for a design is something anyone should be proud of, and I suspect will be worth the blood, sweat and tears.

I know my own code has gotten a lot better from Andrei's professional criticism.

On Thursday, 16 June 2016 at 22:30:48 UTC, Walter Bright wrote:
> Andrei is in charge of the library and has my full support.
>
> We've talked many times about raising the bar much higher on Phobos. It's a tough competitive environment for programming languages out there, and we should all expect the review process going forward for Phobos to be brutal.
>
> On the other hand, getting an endorsement from Andrei for a design is something anyone should be proud of, and I suspect will be worth the blood, sweat and tears.
>
> I know my own code has gotten a lot better from Andrei's professional criticism.

There are many ways to go about "raising the bar"; making Andrei the sole arbiter of a design's quality will not necessarily accomplish this, but will make the need for constant communication with him a major bottleneck for development, regardless. It also risks making him into a single point of failure.

I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong.

On Thursday, 16 June 2016 at 23:27:06 UTC, tsbockman wrote:
> I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong.

I think maybe the C++ approach is better. If you want something into C++ std your best bet is to try to get it into Boost first.

On Friday, 17 June 2016 at 06:54:20 UTC, Ola Fosheim Grøstad wrote:
> On Thursday, 16 June 2016 at 23:27:06 UTC, tsbockman wrote:
>> I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong.
>
> I think maybe the C++ approach is better. If you want something into C++ std your best bet is to try to get it into Boost first.

std.experimental should probably be our boost.

On Friday, 17 June 2016 at 07:16:20 UTC, deadalnix wrote:
> On Friday, 17 June 2016 at 06:54:20 UTC, Ola Fosheim Grøstad wrote:
>> On Thursday, 16 June 2016 at 23:27:06 UTC, tsbockman wrote:
>>> I do not think this approach will scale in the long run, no matter who is given that role. Of course, I would be happy to be proven wrong.
>>
>> I think maybe the C++ approach is better. If you want something into C++ std your best bet is to try to get it into Boost first.
>
> std.experimental should probably be our boost.

It could be, but "experimental" sends signals of not being production ready. If it isn't ready for production it also won't be tested to the same extent.

Anyway, having something like Boost with a different custodian than Phobos, would allow people to vote with their feet. If a library is popular it should be a candidate.

C++ has "experimental" for unstable APIs:
http://en.cppreference.com/w/cpp/experimental/gcd
http://en.cppreference.com/w/cpp/experimental/to_array