Voting/Scoring and final decision discussion

[Jesse Phillips]

On Thursday, 10 October 2013 at 11:57:37 UTC, Dicebot wrote:
> On Thursday, 10 October 2013 at 03:14:30 UTC, Jesse Phillips 
> wrote:
>> Dicebot, consider what information may help make your 
>> decision. Would yes votes including positive feedback help (it 
>> is easier to side with those providing an argument)?
>
> Yes, that will help. If anyone who has voted "Yes" will comment 
> in this topic with more detailed explanation, it will be taken 
> into consideration.

I think the question is, do you think there is positive feedback
which you think would be able to sway your choice? Since boost
mixes the review/vote they list these items:


1. What is your evaluation of the design?
2. What is your evaluation of the implementation?
3. What is your evaluation of the documentation?
4. What is your evaluation of the potential usefulness of the
library?
5. Did you try to use the library? With what compiler? Did you
have any problems?
6. How much effort did you put into your evaluation? A glance? A
quick reading? In-depth study?
7. Are you knowledgeable about the problem domain?

Of which I think 5-7 may be good for inclusion with voting. 1-3
get covered with the review and condition, 4 is somewhat handled
by people stepping up to vote.

> Right now I am more leaning towards declining the module 
> adoption, mostly because "No" vote amount is rather high among 
> Phobos developers, which is a really bad sign.
>
> It is pretty clear though that this voting has shown certain 
> weak spot in out adoption process for more controversial 
> proposals. Once person (review manager) simply should not have 
> that much decision power in such situation.

In my opinion it must be one person, reaching out for help is
perfectly reasonable. It was clear to me this wasn't going to be
an easy choice. Which is why I started this to give you an idea
of how you should be evaluating these votes. I've certainly been
on either side, here some things I've been thinking about.

* Clearly the library function is desired
* The library is well constructed with decent performance
* Performance improvements may be needed, but I couldn't see
reason this would change the API
* There are some changes which could be made to the
implementation and API which several D members feel would make
the library more "D" like

With the first three points I was thinking passing the library
was the "correct" choice. I do prefer the tk!"<<" style, but it
didn't seem a large enough issue (others didn't like it).

However Andrei and Walter's call out to take advantage of D's
strengths to do things other languages couldn't dream of has
pushed me toward the other side. Don't get me wrong I think
Andrei's suggestion could support the API. And do talk with Brian
to see if he feels he should look at changing the implementation.

Yes, the suggestion of a major implementation change during
voting was unfortunate, but the goal is to get good idiomatic D
libraries and I wouldn't want anyone to feel they can't introduce
information during the vote just because they couldn't review or
didn't have the idea until the voting actually started.

Anyway, that is probably my $5 worth.