<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, May 4, 2014 at 12:22 AM, Andrei Alexandrescu via Digitalmars-d <span dir="ltr"><<a href="mailto:digitalmars-d@puremagic.com" target="_blank">digitalmars-d@puremagic.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Mostly good points, but the bountysource program is an experiment by Facebook, not by myself. And (without me trying to speak on Facebook's behalf) it would be difficult to argue that Facebook doesn't understand FOSS or is out there to insult contributors. We're just experimenting with various angles.</blockquote>
<div><br></div><div>If the bounty system was such a great idea, then every FOSS project would be using it.  Now, hiring full-time engineers to work on a FOSS project, that's an entirely different issue.  Besides, if someone is trying to figure out how FOSS teams manage to become successful in regards to development and all the associated technical and social complexities, then all they have to do is study one of the million different FOSS projects out there.  Many well known FOSS contributors have actually documented their experience and knowledge of managing FOSS projects.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br></div>
The on/off switch may be a nice idea in the abstract but is hardly the perfect recipe to good language feature development; otherwise everybody would be using it, and there's not overwhelming evidence to that. (I do know it's been done a few times, such as the (in)famous "new scoping rule of the for statement" for C++ which has been introduced as an option by VC++.)<br>

<br></blockquote><div><br></div><div>No, it's nothing abstract, and it's very practical and useful.  Rust has such a thing, #![feature(X,Y,Z)].  So does Haskell, with {-# feature #-}.  Even Python has __future__, and many others.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I wonder how you've gotten the perception that one needs to be a member of the inner circle mafia to get things into D. Today's major contributors to D came from all over, without any preexisting relationship to anyone else, and their admission ticket has been getting work done. Could you please get into detail on how you view things? (I tried to look over your past posts to see a pattern of rejected contributions, but didn't find such.)<div class="">
<br>
<br></div></blockquote><div><br></div><div>I wasn't trying to imply that contributions are rejected if contributors are not members of a certain group.  I was just trying to say that it's more likely for a _new_ feature to make it into D/Phobos if they are proposed by members of the inner circle or someone representing a corporation, probably because they become more noticeable, or because they get lost in all the forum noise, I don't know.  I could be wrong, but that's just how I perceive it.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
<br></div>
Actually I'd love to get you started so I'd understand your angle better. I'm sure we can do a lot better. One good thing Phobos reviews have done since we initiated them has been to prevent bad artifacts to make it into the library. We'd love to make it better. From what I saw witnessing similar processes (C++, Boost, Python, Scala) - they all have some sense of awkward self-importance to them upon the first look. I think that's the way such things work.<div class="">
<br>
<br></div></blockquote><div> </div><div>Here is an idea:  include new features in DMD/Phobos as soon as they arrive, and make them part of the official binary release so that the average D user can try them out.  Make sure they are marked as unstable, and put a on/off switch on them (something like what Rust/Haskell have; not a compiler switch).  If the feature receives no implementation bug reports for X consecutive days AND no design bug reports for Y consecutive days, then the feature is marked stable and officially becomes part of DMD/Phobos.  The X and the Y can be decreased as D's number of users increases over the years.  The whole idea is very much like farming: you are planting seeds.  As the plants grow, some of them will not survive, others will be destroyed, and some of them will take years to grow.  In any case, you harvest the fruits when they are ready.</div>
<div><br></div><div> Here are good starting values for X and Y:</div><div>X = 90 days</div><div>Y = 180 days</div></div></div></div>