On 12/9/10 1:02 AM, Don Clugston wrote:
> On 9 December 2010 01:16, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>> I don't really understand the stiff opposition to this. This is not the time and the place to criticize the past and present of our process, but instead to take steps to improve it. Part of improving the process, now that fixing bugs is a major focus, is to figure out a good ranking function for bugs. And I believe that increasing the number of votes per user would contribute to that. Could we please push this through? Let's make it happen.
>
>
> Let me explain the stiff opposition.
>
> This change DESTROYS THE EXISTING STATISTICS.
> When you make a radical change like this, you have to wait for at a
> least a year or so before the statistics are meaningful again.
> It took a couple of years to get them to the level they are at now. Seriously.
> As one of the very few people who actually *uses* the vote statistics,
> to determine which bugs to fix,  I'm quite annoyed about this.

OK. Since I don't feel strongly about this and you do, I withdraw my suggestion. Brad, could you please change the parameters back?

> You also made this statement on the newsgroup:
>> Right now the process of choosing which bug to fix next is unstructured.
>
> I think this indicates a misconception.
> Over the last six months, nearly 90% of fixed bugs were patches. I
> think it's entirely appropriate that bugs with correct patches get
> high priority.
> And since they are community-driven, there's not  much control over
> which bugs they are.
>
> Half the patches are mine. I follow a definite priority in choosing
> which bugs to patch.
> 1.  Wrong-code regression
> 2.  ICE regression
> 3.  wrong code bugs marked 'blocker' or 'critical'
> 4. Compiler segfault
> 5. Missing line number
> 6. ICE or wrong code, non-obscure situation
> 7. Regression, non-obscure (most recently introduced get highest priority)
> 8. ICE or wrong code, more obscure situation
>
> Bugs with votes jump a couple of places up the list. There *ought* to be categories below those I've listed, where votes and age would play a big role,  but there have just been too many bugs in the top priority categories.
>
> I also patch a few bugs which aren't on that list, mostly when they're very easy, or when I hit them myself. I also do CTFE bugs, because I feel I've taken ownership of that part of the compiler.
>
> Note that people don't tend to vote for ICE and wrong-code bugs, because you don't notice them until after they've wasted days of your life.

Great. I wasn't aware of this, and it's reasonable to assume that people hanging out on the NG aren't either. Would be great to paste this in a response when the topic of bug fixing planning comes about.

Thanks,

Andrei

----- Original Message ----
> From: Don Clugston <dclugston at googlemail.com>
> 
> On 9 December 2010 14:47, Steve Schveighoffer <schveiguy at yahoo.com> wrote:
> > Can we have a published list  somewhere of the most voted bugs?  There used
>to be
> > the monthly "most  requested features" of D, which was horrifically out of
>date,
> > but it  reminded us every month that it was there.  A monthly post to the NG
>of
> >  the top 10 or top 20 most voted bugs would help keep people focused on the
>votes
> > IMO.
> 
> Who do you mean by "people"? Do you mean  "Walter"?

No, everyone.  All the people on the NG would see that votes matter (at least to make bugs move up the list), so they would be more likely to vote for bugs. Also note that many bugs are not dmd's fault, so everyone who fixes bugs on phobos can also pay attention to the list.

The fact is, I have no idea what the most voted-for bugs are.  And I'm not inclined to go to bugzilla to look for that list, because I'm a passive observer of it (even as someone who votes and who fixes bugs in Phobos!).  Having a published list that I can easily glance at in my daily reading of the NG would go a long way to bring awareness to the voting system.

Also, for instance, if I found a bug that I'm responsible for fixing jumped up to #5 on the list, then I'd probably make a better effort to fix that bug as soon as I can, whereas now, I keep saying "I really gotta fix those bugs sometime".  Nagging works, as annoying as it is.

> > In effect, posting to the NG is like a squeaky wheel  calling for grease.
> 
> Yes. But where the hell is the grease? It's not  actually created by the squeaking, unfortunately.

huh?  The grease is the cure for the squeaking, not created by squeaking.  What I mean is that when it's made public what the community considers important, it can help influence where "grease" (i.e. the development team's effort) is applied.

> The problem is that  there are 70 bugs/month fixed, but >150 bugs
>reported/month.

I hope this changes over time.  The fact that Walter is working on pretty much one thing (getting 64-bit support working) doesn't help.

IMO actually, we should really be focusing on getting the design for Phobos done before we address many of these bugs.  I admit I have very little time to fix bugs in D, which I think is a problem for many here.

> (incidentally  35/month come from  bearophile).

But many of bearophile's bugs are not bugs, they are either attempting to change the design or to add some new feature.

-Steve

Severity isn't always appropriate though.  Forward referencing bugs aren't terribly severe but they can block the development of some projects.  I still like the idea of having only 10 votes though.

On Dec 8, 2010, at 1:10 PM, Steve Schveighoffer wrote:

> Bugs have a severity field.  I'd say use that.
> 
> -Steve
> 
> From: David Simcha <dsimcha at gmail.com>
> To: Discuss the phobos library for D <phobos at puremagic.com>
> Sent: Wed, December 8, 2010 4:04:34 PM
> Subject: Re: [phobos] Upping the number of bugzilla votes from 10 to 100
> 
> If we want a more analog system, I'd say give every user 100 votes and allow more than one to be used on a single bug.  This way, bugs that are a huge PITA can can be given a lot of votes and ones that are a little annoying can be given a few, instead of each user having to make an all-or-nothing decision.
> 
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos

On Dec 9, 2010, at 5:47 AM, Steve Schveighoffer wrote:
> 
> I don't think the voting system will reflect the exact pain levels of the person.  People exaggerate.  For example, those surveys where you have 1-5, 1 = not likely at all, and 5 = definitely, people often circle all 5s or all 1s because they want to drag the curve in a certain direction.

Funny, I almost never circle 1 or 5 for those because it's rare that I'll have such strong feelings about the topic.

On 12/9/10 9:21 AM, Sean Kelly wrote:
> On Dec 9, 2010, at 5:47 AM, Steve Schveighoffer wrote:
>>
>> I don't think the voting system will reflect the exact pain levels of the person.  People exaggerate.  For example, those surveys where you have 1-5, 1 = not likely at all, and 5 = definitely, people often circle all 5s or all 1s because they want to drag the curve in a certain direction.
>
> Funny, I almost never circle 1 or 5 for those because it's rare that I'll have such strong feelings about the topic.

Heh, same here. I do have strong opinions, but whenever I see such a survey, I'm thinking: "Could I be even more pissed about that? Guess so". So I tend to circle 2 and 4 :o).

Andrei

On 12/9/2010 7:58 AM, Andrei Alexandrescu wrote:
> On 12/9/10 1:02 AM, Don Clugston wrote:
>> On 9 December 2010 01:16, Andrei Alexandrescu<andrei at erdani.com>  wrote:
>>> I don't really understand the stiff opposition to this. This is not the time and the place to criticize the past and present of our process, but instead to take steps to improve it. Part of improving the process, now that fixing bugs is a major focus, is to figure out a good ranking function for bugs. And I believe that increasing the number of votes per user would contribute to that. Could we please push this through? Let's make it happen.
>>
>>
>> Let me explain the stiff opposition.
>>
>> This change DESTROYS THE EXISTING STATISTICS.
>> When you make a radical change like this, you have to wait for at a
>> least a year or so before the statistics are meaningful again.
>> It took a couple of years to get them to the level they are at now. Seriously.
>> As one of the very few people who actually *uses* the vote statistics,
>> to determine which bugs to fix,  I'm quite annoyed about this.
> 
> OK. Since I don't feel strongly about this and you do, I withdraw my suggestion. Brad, could you please change the parameters back?
> 

Changed back.  There were a few people that had their votes adjusted due to lowering the limits:

    nyphbl8d at gmail.com
    robert at octarineparrot.com
    zan77137 at nifty.com
    aldacron at gmail.com
    simen.kjaras at gmail.com

I have no idea how bugzilla mangled your votes, so each of you should go look and fix up as desired.

Later,
Brad

Brad Roberts <braddr at puremagic.com> wrote:

> Changed back.  There were a few people that had their votes adjusted due
> to
> lowering the limits:
>
>     nyphbl8d at gmail.com
>     robert at octarineparrot.com
>     zan77137 at nifty.com
>     aldacron at gmail.com
>     simen.kjaras at gmail.com
>
> I have no idea how bugzilla mangled your votes, so each of you should go
> look
> and fix up as desired.

Unless the number of voted-on issues changed, the votes should be for the same issues that they were before, just the number of them is changed.

-- 
Simen

On Thu, 9 Dec 2010, Simen Kjaeraas wrote:

> Brad Roberts <braddr at puremagic.com> wrote:
> 
> > Changed back.  There were a few people that had their votes adjusted due to lowering the limits:
> > 
> >    nyphbl8d at gmail.com
> >    robert at octarineparrot.com
> >    zan77137 at nifty.com
> >    aldacron at gmail.com
> >    simen.kjaras at gmail.com
> > 
> > I have no idea how bugzilla mangled your votes, so each of you should go
> > look
> > and fix up as desired.
> 
> Unless the number of voted-on issues changed, the votes should be for the same issues that they were before, just the number of them is changed.
> 
> -- 
> Simen

It was some of both.. people with too many votes, and more than one vote per bug, though just a small number of each.  I just didn't want the 5 above to look at their votes and be confused about the changes.  It might not be what they want them to be any more.

Later,
Brad

Don does have something similar publicly available.

http://www.prowiki.org/wiki4d/wiki.cgi?LanguageDevel#Roadmap

And once again I wish to thank Don for his attempts to keep this page up to date. I don't know how many others actually find it useful.

On Thu, Dec 9, 2010 at 7:58 AM, Andrei Alexandrescu <andrei at erdani.com> wrote:
> On 12/9/10 1:02 AM, Don Clugston wrote:
>>
>> Half the patches are mine. I follow a definite priority in choosing
>> which bugs to patch.
>> 1. ?Wrong-code regression
>> 2. ?ICE regression
>> 3. ?wrong code bugs marked 'blocker' or 'critical'
>> 4. Compiler segfault
>> 5. Missing line number
>> 6. ICE or wrong code, non-obscure situation
>> 7. Regression, non-obscure (most recently introduced get highest priority)
>> 8. ICE or wrong code, more obscure situation
>>
>
> Great. I wasn't aware of this, and it's reasonable to assume that people hanging out on the NG aren't either. Would be great to paste this in a response when the topic of bug fixing planning comes about.


-- 
Liberty means responsibility. That is why most men dread it. ? - George Bernard Shaw