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 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
prev sibling next sibling parent "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
prev sibling 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 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 "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 next 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 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 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 "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
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
next sibling 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 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
prev sibling next sibling parent "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
prev sibling 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 next 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 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 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 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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling parent 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling next sibling 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
prev sibling 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 next sibling 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 "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