std.parallelism: VOTE IN THIS THREAD

[lurker]

Bruno Medeiros Wrote:

> On 19/04/2011 14:47, Russel Winder wrote:
> > On Tue, 2011-04-19 at 06:13 -0500, Caligo wrote:
> > [ . . . ]
> >> I would like to make a comment if that's okay.  If a person is not an
> >> expert on parallelism, library development, or we can't verify his or
> >> her background and such, I don't see why their vote should count.  I'm
> >> not voting because I'm just an ordinary D user, and I have no
> >> expertise in parallelism.  And since this a public vote, if would be
> >> great if people who are voting did not hide behind an alias, such as
> >> bearophile.
> >
> > I think there is an very interesting and important issue here.  There
> > are really four (or more/less) roles of people who might vote:
> >
> > 	Has detailed knowledge of implementation and usage.
> > 	Has some knowledge of implementation and/or usage.
> > 	Perhaps just using the API.
> > 	No actual interest.
> >
> > And then there are:
> >
> > 	Sock puppet aka shill
> > 	Troll
> >
> > but let's ignore them.
> >
> > Although the general belief is "one person, one vote", some decisions
> > are best influenced by considering the weighting to a vote provided by
> > annotating with role.
> >
> > Two cases perhaps highlight this:
> >
> > If a person using the library but having no knowledge of the
> > implementation finds a problematic API issue then this should count as
> > much as any view of people more knowledgeable about the internals.
> >
> > If a person without knowledge of the theory and practice votes yes where
> > the domain experts are able to argue there is a blocking problem, then
> > the person leading the vote should have the option of cancelling and
> > re-entering review even if there was a clear majority vote for.
> >
> > I think the issue here is not to be bound too rigidly by votes and
> > statistics, this is not after all politics, but instead to ensure that
> > everyone has the right sort of say about these things and that the
> > majority of people always feel the right decisions are getting made.
> >
> > Consider the system not being one of the review leader managing the
> > votes, but of the review leader having a single golden vote which then
> > has to be justified by argumentation.
> >
> >> P.S.
> >> I can't wait for std.parallelism to become part of Phobos.
> >
> > Me too.
> >
> 
> I generally agree with this perspective, being aware of this issue, and 
> not making the voting completely democratic (that's why I'm not voting 
> on this one). On the other hand, one would also hope that those with D's 
> best interest in mind will also be mindful of this, and not vote if they 
> feel they have insuficient knowledge to evaluate the proposal. In other 
> words, one would hope the community would self-regulate to avoid this 
> problem, and no formal additional rules should be needed. Let's see.
> 
> In any case it seems this won't matter for this proposal, everyone is 
> voting yes :) . But it's worthwhile to keep in mind for the future.

Yes, everyone is voting yes. And half of the voters haven't ever used parallelism or know anything about its library level design issues. This voting process seemed like a joke. I know this kind of voting is popular in other projects, but D community's infrastructure isn't ready for this. It just shows how UNagile and clumsy the design process is and merely a meat puppet theatre for hiding a dictatorship with uninformed "democracy". You could just add stuff until someone starts complaining and begin hardcore technical discussion when real problems arise.

Cheers,
sock puppet #2347