www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Bountysource: Facebook offers additional funding for D issues

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Hello,


Following a good recent history with bounty work on D-related projects 
(especially GDC and LDC, congratulations!), Facebook is offering more 
funds to spend on useful D-related issues. The one way to increase 
investment in the area is to show that the current investment does 
improve things.

The sweet spot seems to be $250 per issue.

This is one place where discussing and voting would be very sensible. 
Please reply to this and/or vote on D issues on http://d.puremagic.com.

One idea I have is to place bounties on curating our large bug database. 
For example, I'm considering something like "Close N dlang issues, get 
$250!" which may mean actually little or no coding. Of course the choice 
of N is also important (= 10? 15?).

Please chime in!


Thanks,

Andrei
Mar 13 2014
next sibling parent reply "Andrej Mitrovic" <andrej.mitrovich gmail.com> writes:
On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu 
wrote:

 For example, I'm considering something like "Close N dlang 
 issues, get $250!"


Oh my. *stares at bearophile's long list of duplicate bug 
reports* :P
Mar 13 2014
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 13 Mar 2014 16:03:54 -0400, Andrej Mitrovic  
<andrej.mitrovich gmail.com> wrote:


 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 For example, I'm considering something like "Close N dlang issues, get  
 $250!"


 Oh my. *stares at bearophile's long list of duplicate bug reports* :P


I don't think he means close as invalid or duplicate :)

-Steve
Mar 13 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 1:09 PM, Steven Schveighoffer wrote:

 On Thu, 13 Mar 2014 16:03:54 -0400, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:


 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 For example, I'm considering something like "Close N dlang issues,
 get $250!"


 Oh my. *stares at bearophile's long list of duplicate bug reports* :P


 I don't think he means close as invalid or duplicate :)


Good distinction. I guess close as FIXED would be the only possibility. 
But I also think closing duplicates and invalids is valuable.

Andrei
Mar 13 2014
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 13 Mar 2014 16:10:54 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail erdani.org> wrote:


 On 3/13/14, 1:09 PM, Steven Schveighoffer wrote:

 On Thu, 13 Mar 2014 16:03:54 -0400, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:


 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 For example, I'm considering something like "Close N dlang issues,
 get $250!"


 Oh my. *stares at bearophile's long list of duplicate bug reports* :P


 I don't think he means close as invalid or duplicate :)


 Good distinction. I guess close as FIXED would be the only possibility.  
 But I also think closing duplicates and invalids is valuable.


Maybe 2 orders of magnitude less important.

$2.50 for each N closed duplicates ;)

-Steve
Mar 13 2014
prev sibling next sibling parent "monarch_dodra" <monarchdodra gmail.com> writes:
On Thursday, 13 March 2014 at 20:10:34 UTC, Andrei Alexandrescu 
wrote:

 Good distinction. I guess close as FIXED would be the only 
 possibility. But I also think closing duplicates and invalids 
 is valuable.


Indeed, closing as duplicate, invalid, or worksforme is still 
very useful, and very ungrateful work.

I think giving a bounty on that too should also be rewarded, if 
at all possible.
Mar 13 2014
prev sibling parent "Chris Williams" <yoreanon-chrisw yahoo.co.jp> writes:
On Thursday, 13 March 2014 at 20:10:34 UTC, Andrei Alexandrescu 
wrote:

 On 3/13/14, 1:09 PM, Steven Schveighoffer wrote:

 On Thu, 13 Mar 2014 16:03:54 -0400, Andrej Mitrovic
 <andrej.mitrovich gmail.com> wrote:


 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei 
 Alexandrescu wrote:

 For example, I'm considering something like "Close N dlang 
 issues,
 get $250!"


 Oh my. *stares at bearophile's long list of duplicate bug 
 reports* :P


 I don't think he means close as invalid or duplicate :)


 Good distinction. I guess close as FIXED would be the only 
 possibility. But I also think closing duplicates and invalids 
 is valuable.

 Andrei


If there's any reasonable guesstimate about the relative ratios, 
like on average for every 5 FIXED, there's 3 DUPE, and 7 INVALID, 
then you could structure the offer with that assumption. $250 for 
15 closed of which at least 5 are FIXED.
Mar 13 2014
prev sibling parent Brad Roberts <braddr puremagic.com> writes:
On 3/13/14, 1:09 PM, Steven Schveighoffer wrote:

 On Thu, 13 Mar 2014 16:03:54 -0400, Andrej Mitrovic
<andrej.mitrovich gmail.com> wrote:


 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 For example, I'm considering something like "Close N dlang issues, get $250!"


 Oh my. *stares at bearophile's long list of duplicate bug reports* :P


 I don't think he means close as invalid or duplicate :)

 -Steve


Actually, I'd consider that a fine use case.  Reducing the number of bug
reports is valuable.  The 
only _invalid_ closure mode would be just out-right closing a swath of bugs
without evaluating the 
validity of the closure.
Mar 13 2014
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu 
wrote:

 One idea I have is to place bounties on curating our large bug 
 database.


Would be nice if something could be done about the site's 
responsiveness. Page load times of about 10 seconds, and 
occasionally going as high as minutes, can get frustrating. 
Lately I've resorted to parsing DFeed's digitalmars.D.bugs cache 
and dumping the database to my filesystem.

Can this be improved somehow? If it's about cycles, the server 
hosting the forum and wiki is still mostly idle.
Mar 13 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 2:25 PM, Vladimir Panteleev wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 One idea I have is to place bounties on curating our large bug database.


 Would be nice if something could be done about the site's
 responsiveness. Page load times of about 10 seconds, and occasionally
 going as high as minutes, can get frustrating. Lately I've resorted to
 parsing DFeed's digitalmars.D.bugs cache and dumping the database to my
 filesystem.

 Can this be improved somehow? If it's about cycles, the server hosting
 the forum and wiki is still mostly idle.


Wrote our webmaster. Incidentally he beefed up our resources 
considerably recently.

Andrei
Mar 13 2014
parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Thursday, 13 March 2014 at 21:34:48 UTC, Andrei Alexandrescu 
wrote:

 On 3/13/14, 2:25 PM, Vladimir Panteleev wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei 
 Alexandrescu wrote:

 One idea I have is to place bounties on curating our large 
 bug database.


 Would be nice if something could be done about the site's
 responsiveness. Page load times of about 10 seconds, and 
 occasionally
 going as high as minutes, can get frustrating. Lately I've 
 resorted to
 parsing DFeed's digitalmars.D.bugs cache and dumping the 
 database to my
 filesystem.

 Can this be improved somehow? If it's about cycles, the server 
 hosting
 the forum and wiki is still mostly idle.


 Wrote our webmaster. Incidentally he beefed up our resources 
 considerably recently.


Jan? I thought Brad (Pure Magic) hosted Bugzilla?

Speaking of which, how about bugs.dlang.org? Should be a painless 
migration with a proper redirect.
Mar 13 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 2:43 PM, Vladimir Panteleev wrote:

 On Thursday, 13 March 2014 at 21:34:48 UTC, Andrei Alexandrescu wrote:

 On 3/13/14, 2:25 PM, Vladimir Panteleev wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 One idea I have is to place bounties on curating our large bug
 database.


 Would be nice if something could be done about the site's
 responsiveness. Page load times of about 10 seconds, and occasionally
 going as high as minutes, can get frustrating. Lately I've resorted to
 parsing DFeed's digitalmars.D.bugs cache and dumping the database to my
 filesystem.

 Can this be improved somehow? If it's about cycles, the server hosting
 the forum and wiki is still mostly idle.


 Wrote our webmaster. Incidentally he beefed up our resources
 considerably recently.


 Jan? I thought Brad (Pure Magic) hosted Bugzilla?

 Speaking of which, how about bugs.dlang.org? Should be a painless
 migration with a proper redirect.


We have http://issues.dlang.org which Brad needs to get to. I pinged him 
for the fourth time just now.

Andrei
Mar 13 2014
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/13/2014 08:52 PM, Andrei Alexandrescu wrote:

 Following a good recent history with bounty work on D-related projects
 (especially GDC and LDC, congratulations!), Facebook is offering more
 funds to spend on useful D-related issues. The one way to increase
 investment in the area is to show that the current investment does
 improve things.

 The sweet spot seems to be $250 per issue.

 This is one place where discussing and voting would be very sensible.
 Please reply to this and/or vote on D issues on http://d.puremagic.com.


What about fixing compile-time reflection?

There is the notorious case

static if(!is(typeof(e))) enum f = true;
static if(!is(typeof(f))) enum e = true;

and many like it. Sometimes, compilation of the same program where 
source files are passed on the command line in a different order 
influences the behaviour of the produced executable.
Mar 13 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 13 March 2014 at 22:37:32 UTC, Timon Gehr wrote:

 On 03/13/2014 08:52 PM, Andrei Alexandrescu wrote:

 Following a good recent history with bounty work on D-related 
 projects
 (especially GDC and LDC, congratulations!), Facebook is 
 offering more
 funds to spend on useful D-related issues. The one way to 
 increase
 investment in the area is to show that the current investment 
 does
 improve things.

 The sweet spot seems to be $250 per issue.

 This is one place where discussing and voting would be very 
 sensible.
 Please reply to this and/or vote on D issues on 
 http://d.puremagic.com.


 What about fixing compile-time reflection?

 There is the notorious case

 static if(!is(typeof(e))) enum f = true;
 static if(!is(typeof(f))) enum e = true;

 and many like it. Sometimes, compilation of the same program 
 where source files are passed on the command line in a 
 different order influences the behaviour of the produced 
 executable.


http://wiki.dlang.org/DIP31
Mar 13 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2014 02:14 AM, deadalnix wrote:

 What about fixing compile-time reflection?

 There is the notorious case

 static if(!is(typeof(e))) enum f = true;
 static if(!is(typeof(f))) enum e = true;

 and many like it. Sometimes, compilation of the same program where
 source files are passed on the command line in a different order
 influences the behaviour of the produced executable.


 http://wiki.dlang.org/DIP31


"   3. A construct that may introduce unknown symbols.

The obvious feature of priority 2 is mixin, ..."

I think the explanation accidentally uses 0-based indexing.

"Any attempt to resolve a symbol will create a poison at the 
corresponding entry. ... Construct of priority 2 are evaluated in order 
of appearance in the source."

Order of appearance in the source is not well-defined. There can be 
circular imports. In any case, strategies dependent on declaration order 
at all do not result in predictable/flexible enough semantics in my 
opinion. One would need to reduce in parallel until analysis is 
completely stalled on lookups of unpoisoned symbols. Then one poisons 
all the stalled lookups in the topmost strongly connected component of 
the lookup-dependency-graph at once.

Eg. the following simple cases are easily seen to be completely 
unambiguous by this strategy:

// ----

static if(foo){ mixin("enum bar=true;"); }
mixin("enum foo=true;");

// ----

mixin(qux);
static if(foo.length){
     mixin("enum bar=true;");
     mixin(baz);
}
mixin("enum foo=baz;");
mixin("enum baz=`enum qux=q{enum fun=3;};`;");

static assert(fun==3);

The compiler should be able to resolve this.

Unfortunately this is not yet sufficient, eg. the following 
reasonably-looking case is not shown to be unambiguous by this strategy 
alone.

enum x = "enum xx = q{int y = 0;};";

struct SS{
     mixin(xx);
     mixin(x); // error, xx poisoned
}
Mar 14 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 March 2014 at 12:26:18 UTC, Timon Gehr wrote:

 "   3. A construct that may introduce unknown symbols.

 The obvious feature of priority 2 is mixin, ..."

 I think the explanation accidentally uses 0-based indexing.


You are right. I'm updating the DIP to make it 1 indexed.


 "Any attempt to resolve a symbol will create a poison at the 
 corresponding entry. ... Construct of priority 2 are evaluated 
 in order of appearance in the source."

 Order of appearance in the source is not well-defined. There 
 can be circular imports. In any case, strategies dependent on 
 declaration order at all do not result in predictable/flexible 
 enough semantics in my opinion. One would need to reduce in 
 parallel until analysis is completely stalled on lookups of 
 unpoisoned symbols. Then one poisons all the stalled lookups in 
 the topmost strongly connected component of the 
 lookup-dependency-graph at once.


Order of inclusion only matter for symbol in socpe when compile 
time construct are present. They may introduce random symbols, it 
do not seems possible to make them independent of order in the 
source code in a paradox free manner. I have no proof of this, 
and I'd be happy to be proven wrong.

You are also right, they is an hole in the proposal when it comes 
to loop in module inclusion. I still think the proposal is a huge 
improvement over the current situation.


 Eg. the following simple cases are easily seen to be completely 
 unambiguous by this strategy:

 // ----

 static if(foo){ mixin("enum bar=true;"); }
 mixin("enum foo=true;");

 // ----

 mixin(qux);
 static if(foo.length){
     mixin("enum bar=true;");
     mixin(baz);
 }
 mixin("enum foo=baz;");
 mixin("enum baz=`enum qux=q{enum fun=3;};`;");

 static assert(fun==3);

 The compiler should be able to resolve this.


I'm not sure what you think should happen as per my proposal 
here. Both module fail at the very first conditional :
static if(foo){ mixin("enum bar=true;"); } // priority 3, 
evaluate in order, foo doesn't exists. Error.
mixin(qux); // Same here, qux do not exists, error.


 Unfortunately this is not yet sufficient, eg. the following 
 reasonably-looking case is not shown to be unambiguous by this 
 strategy alone.

 enum x = "enum xx = q{int y = 0;};";

 struct SS{
     mixin(xx);
     mixin(x); // error, xx poisoned
 }


mixin are priority 2. mixin(xx) is processed first and is an 
error. If an xx string is defined somewhere (for instance in a 
imported module not present in the sample code) then mixin(x) 
becomes indeed an error, as it override the symbol xx, which 
would change the semantic of the previous mixin.
Mar 14 2014
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 03/14/2014 11:50 PM, deadalnix wrote:

 ...

 "Any attempt to resolve a symbol will create a poison at the
 corresponding entry. ... Construct of priority 2 are evaluated in
 order of appearance in the source."

 Order of appearance in the source is not well-defined. There can be
 circular imports. In any case, strategies dependent on declaration
 order at all do not result in predictable/flexible enough semantics in
 my opinion. One would need to reduce in parallel until analysis is
 completely stalled on lookups of unpoisoned symbols. Then one poisons
 all the stalled lookups in the topmost strongly connected component of
 the lookup-dependency-graph at once.


 Order of inclusion only matter for symbol in socpe when compile time
 construct are present. They may introduce random symbols, it do not
 seems possible to make them independent of order in the source code in a
 paradox free manner. I have no proof of this, and I'd be happy to be
 proven wrong.
 ...


It can be done. (What I described above works strictly better than the 
DIP afaics.)


 You are also right, they is an hole in the proposal when it comes to
 loop in module inclusion. I still think the proposal is a huge
 improvement over the current situation.


 Eg. the following simple cases are easily seen to be completely
 unambiguous by this strategy:

 ...


 I'm not sure what you think should happen as per my proposal here.


I think per your proposal, those would fail, but I think they should be 
valid, as they can be processed and proven unambiguous by a reasonably 
simple and quite general order-independent strategy.


 Both
 module fail at the very first conditional :
 static if(foo){ mixin("enum bar=true;"); } // priority 3, evaluate in
 order, foo doesn't exists. Error.
 mixin(qux); // Same here, qux do not exists, error.


 Unfortunately this is not yet sufficient, eg. the following
 reasonably-looking case is not shown to be unambiguous by this
 strategy alone.

 enum x = "enum xx = q{int y = 0;};";

 struct SS{
     mixin(xx);
     mixin(x); // error, xx poisoned
 }


 mixin are priority 2. mixin(xx) is processed first and is an error. If
 an xx string is defined somewhere (for instance in a imported module not
 present in the sample code) then mixin(x) becomes indeed an error, as it
 override the symbol xx, which would change the semantic of the previous
 mixin.


Yup.
Mar 14 2014
parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 March 2014 at 23:25:47 UTC, Timon Gehr wrote:

 On 03/14/2014 11:50 PM, deadalnix wrote:

 ...

 "Any attempt to resolve a symbol will create a poison at the
 corresponding entry. ... Construct of priority 2 are 
 evaluated in
 order of appearance in the source."

 Order of appearance in the source is not well-defined. There 
 can be
 circular imports. In any case, strategies dependent on 
 declaration
 order at all do not result in predictable/flexible enough 
 semantics in
 my opinion. One would need to reduce in parallel until 
 analysis is
 completely stalled on lookups of unpoisoned symbols. Then one 
 poisons
 all the stalled lookups in the topmost strongly connected 
 component of
 the lookup-dependency-graph at once.


 Order of inclusion only matter for symbol in socpe when 
 compile time
 construct are present. They may introduce random symbols, it 
 do not
 seems possible to make them independent of order in the source 
 code in a
 paradox free manner. I have no proof of this, and I'd be happy 
 to be
 proven wrong.
 ...


 It can be done. (What I described above works strictly better 
 than the DIP afaics.)


It is difficult to judge, you didn't provided many details. I
don't see how your proposal could work without having significant
risk of heavy backtracking. Can you precise what you have in mind
?
Mar 14 2014
prev sibling parent reply "Mike" <none none.com> writes:
On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu 
wrote:

 This is one place where discussing and voting would be very 
 sensible. Please reply to this and/or vote on D issues on 
 http://d.puremagic.com.


BTW Andrei,

According to Brad, if you want to increase users' vote quota or 
allow users to assign more than one vote per issue to better 
inform BountySource, it's up to you to do it.

I'm sorry.  More trivial distractions that could easily delegated 
if the right person had authority.

Mike
Mar 13 2014
parent reply "Mike" <none none.com> writes:
On Thursday, 13 March 2014 at 23:25:19 UTC, Mike wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu 
 wrote:

 This is one place where discussing and voting would be very 
 sensible. Please reply to this and/or vote on D issues on 
 http://d.puremagic.com.


 BTW Andrei,

 According to Brad, if you want to increase users' vote quota or 
 allow users to assign more than one vote per issue to better 
 inform BountySource, it's up to you to do it.

 I'm sorry.  More trivial distractions that could easily 
 delegated if the right person had authority.

 Mike


Forgot the link:
http://d.puremagic.com/issues/show_bug.cgi?id=12259
Mar 13 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 4:26 PM, Mike wrote:

 On Thursday, 13 March 2014 at 23:25:19 UTC, Mike wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 This is one place where discussing and voting would be very sensible.
 Please reply to this and/or vote on D issues on http://d.puremagic.com.


 BTW Andrei,

 According to Brad, if you want to increase users' vote quota or allow
 users to assign more than one vote per issue to better inform
 BountySource, it's up to you to do it.

 I'm sorry.  More trivial distractions that could easily delegated if
 the right person had authority.

 Mike


 Forgot the link:
 http://d.puremagic.com/issues/show_bug.cgi?id=12259


Fantastic. I raised the number of votes per user to 20.

Andrei
Mar 13 2014
next sibling parent reply "Mike" <none none.com> writes:
On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu 
wrote:

 Fantastic. I raised the number of votes per user to 20.

 Andrei


What about multiple votes per issue, so users can quantify the 
importance of an issue relative to others?
Mar 13 2014
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 5:51 PM, Mike wrote:

 On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu wrote:

 Fantastic. I raised the number of votes per user to 20.

 Andrei


 What about multiple votes per issue, so users can quantify the
 importance of an issue relative to others?


I'd be okay with allowing a user to manage voting budget as they find 
fit. What do others think?

Andrei
Mar 13 2014
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Friday, 14 March 2014 at 01:03:32 UTC, Andrei Alexandrescu
wrote:

 On 3/13/14, 5:51 PM, Mike wrote:

 On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu 
 wrote:

 Fantastic. I raised the number of votes per user to 20.

 Andrei


 What about multiple votes per issue, so users can quantify the
 importance of an issue relative to others?


 I'd be okay with allowing a user to manage voting budget as 
 they find fit. What do others think?

 Andrei


Limited voting is good. You have to prioritize.
Mar 13 2014
next sibling parent "Mike" <none none.com> writes:
On Friday, 14 March 2014 at 01:15:54 UTC, deadalnix wrote:


 Limited voting is good. You have to prioritize.


The proposal is not to take away the limitation.  It to allow 
users to spend more of their limited budget on a single issue to 
quantify its importance.
Mar 13 2014
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 6:15 PM, deadalnix wrote:

 On Friday, 14 March 2014 at 01:03:32 UTC, Andrei Alexandrescu
 wrote:

 On 3/13/14, 5:51 PM, Mike wrote:

 On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu wrote:

 Fantastic. I raised the number of votes per user to 20.

 Andrei


 What about multiple votes per issue, so users can quantify the
 importance of an issue relative to others?


 I'd be okay with allowing a user to manage voting budget as they find
 fit. What do others think?

 Andrei


 Limited voting is good. You have to prioritize.


There's two: (a) votes per user, currently 20; (b) votes per user per 
issue, currently 1.

Andrei
Mar 13 2014
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Friday, 14 March 2014 at 00:51:30 UTC, Mike wrote:

 On Friday, 14 March 2014 at 00:46:09 UTC, Andrei Alexandrescu 
 wrote:

 Fantastic. I raised the number of votes per user to 20.

 Andrei


 What about multiple votes per issue, so users can quantify the 
 importance of an issue relative to others?


Multiple votes per issue, combined with limited votes for person, 
leads to a bias where a newcomer will dump all their votes on one 
issue they find/create, whereas regulars will have a much more 
diluted effect on any single issue.
Mar 14 2014
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 13, 2014 at 05:46:29PM -0700, Andrei Alexandrescu wrote:
[...]

 Fantastic. I raised the number of votes per user to 20.


[...]

Only 20? :-(  I was hoping to vote on all AA bugs...


T

-- 
"A one-question geek test. If you get the joke, you're a geek: Seen on a
California license plate on a VW Beetle: 'FEATURE'..." -- Joshua D.
Wachs - Natural Intelligence, Inc.
Mar 13 2014
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/13/14, 6:04 PM, H. S. Teoh wrote:

 On Thu, Mar 13, 2014 at 05:46:29PM -0700, Andrei Alexandrescu wrote:
 [...]

 Fantastic. I raised the number of votes per user to 20.


 [...]

 Only 20? :-(  I was hoping to vote on all AA bugs...


Don has protested in the past that too many votes blunt the statistics 
collected. I didn't agree with his argument, but he might have been up 
to something.

What would be a reasonable number?


Andrei
Mar 13 2014
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Thu, Mar 13, 2014 at 06:20:38PM -0700, Andrei Alexandrescu wrote:

 On 3/13/14, 6:04 PM, H. S. Teoh wrote:

On Thu, Mar 13, 2014 at 05:46:29PM -0700, Andrei Alexandrescu wrote:
[...]

Fantastic. I raised the number of votes per user to 20.


[...]

Only 20? :-(  I was hoping to vote on all AA bugs...


 
 Don has protested in the past that too many votes blunt the
 statistics collected. I didn't agree with his argument, but he might
 have been up to something.
 
 What would be a reasonable number?


[...]

Hmm. Originally I would've said unlimited, but thinking about it again,
I think he does have a point that having only a limited number forces
you to consider more carefully which bugs are important to you. Maybe 50
would be a good upper limit? Past that point, it starts losing its
meaning, since I doubt if many people have even read more than 50 bug
reports on bugzilla.


T

-- 
Which is worse: ignorance or apathy? Who knows? Who cares? -- Erich Schubert
Mar 13 2014
prev sibling parent reply Brad Roberts <braddr puremagic.com> writes:
On 3/13/14, 4:26 PM, Mike wrote:

 On Thursday, 13 March 2014 at 23:25:19 UTC, Mike wrote:

 On Thursday, 13 March 2014 at 19:52:05 UTC, Andrei Alexandrescu wrote:

 This is one place where discussing and voting would be very sensible. Please
reply to this and/or
 vote on D issues on http://d.puremagic.com.


 BTW Andrei,

 According to Brad, if you want to increase users' vote quota or allow users to
assign more than
 one vote per issue to better inform BountySource, it's up to you to do it.

 I'm sorry.  More trivial distractions that could easily delegated if the right
person had authority.

 Mike


 Forgot the link:
 http://d.puremagic.com/issues/show_bug.cgi?id=12259


The main reason I didn't make any changes is there was no decided on policy for
what to change it 
to.  I was fine with the 10 votes 1 per bug setting (and was a part of the long
ago discussion that 
lead to that value).  A nebulous 'change it please' is a pointless bug report
and I don't own the 
policy.
Mar 13 2014
parent "Mike" <none none.com> writes:
On Friday, 14 March 2014 at 01:01:12 UTC, Brad Roberts wrote:


 The main reason I didn't make any changes is there was no 
 decided on policy for what to change it to.  I was fine with 
 the 10 votes 1 per bug setting (and was a part of the long ago 
 discussion that lead to that value).  A nebulous 'change it 
 please' is a pointless bug report and I don't own the policy.


I'm sorry, I didn't mean that the way it probably sounded.  I 
provided justification for the change, so it wasn't nebulous.

I was only hoping to highlight the fact that the current policy 
owners have stated they would prefer to not have to worry about 
these trivial matters, yet haven't delegated authority and 
ownership of such policy so they don't have to.
Mar 13 2014