On 2/5/15 4:08 PM, Zach the Mystic wrote:
On Thursday, 5 February 2015 at 23:35:04 UTC, Dicebot wrote:
No, you get it wrong. This is decided exclusively community voting.
Andrei or Walter can veto something that they don't want but their
explicit approval is not required.
I'm surprised. From my point of view, yours is a bad strategy. What
bothers me is how could a module just take Walter or Andrei completely
by surprise and still end up in the standard library? I honestly
wouldn't want that, and yet apparently it's possible. Now don't get me
wrong. I do think listening to the community is critical, and allowing a
new module because of overwhelming popular demand is also acceptable,
provided there's no reason to veto it.
D is a collaborative project and it's obvious that at some point control
and trust need to be distributed to foster faster growth and broader
participation.
Walter and I have been occasionally appalled by stuff that made it in
Phobos - as was this recent case with @trusted functions that can't be
trusted nonsense - but by and large the good overwhelms the not-so-good.
I trust close contributors who have historically done good work to
continue doing so, and we can delegate certain tasks to folks. As a
simple example I trust Martin and Rainer to do good work on the GC and
review each other's work.
But to me, that veto means a whole lot. It means that people can't know
what will be rejected or accepted unless told, and in the absence of
being told, the motivation to work on something may dry up. That's what
I'm trying to prevent by my strong insistence on the necessity of
leadership.
It is clear we have historically a less than stellar record of good
leadership. We plan to improve dramatically on that starting January -
of this year :o) - and there are a few good early signs that we hope
will develop into successful patterns.
There's no need to fear rejection. There's always code.dlang.org and as
I said: you can trust me to recognize great work when I see it. So
there's definitely no need to ask for permission.
One thing we'll try more of is being more decisive instead of letting
options linger forever. Sometimes we just say "we support this" or "we
don't support that" and our quest for the community is to understand
that "no" is sometimes necessary for focusing on the "yes".
The way I see it, the conversation about what is suitable for a standard
library should come first. Someone should propose something, get a
signal on prospects for inclusion, and then use that signal do determine
whether to keep developing the library for phobos or not. Without the
signal, how will they know whether to develop it for phobos or just for
their own 3rd-party use? How do you get a clear signal when the module
is only voted on at the *end* of the process?
Just use code.dlang.org. It's perfect either as a place for good work
and a stepping stone toward the standard library.
Andrei
