[gentoo-dev] Bug voting

[gentoo-dev] Bug voting

[Dylan Carlson]

Greetings,

Stuart touched on this a month ago (see: Tools to help QA, 6/25/04) and I 
didn't see any arguments for, or against it.  

My thoughts (I'm in favor of bug voting):

1.  Without bug voting, there's no way to determine what bugs are most 
important to the public (or at least to the people using Bugzilla, which 
is really *our* public, in a working sense).

2.  Turning on voting is a trivial change to our system to give people a 
way to promote bugs, and that in turn (ideally) shapes our priorities on 
which ones get addressed first.

I'm assuming there was some reason voting was turned off (since IIRC it's 
on by default).  If so I'm just curious what that reason is.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

On Tue, 27 Jul 2004 12:54:49 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| 1.  Without bug voting, there's no way to determine what bugs are most
| important to the public (or at least to the people using Bugzilla,
| which is really *our* public, in a working sense).

Well, given that most of our users don't seem to be able to get the
priority field straight ("Waah! There's a tiny typo in an einfo
statement! BLOCKER!"), I'd be kind of sceptical about an easily rigged
popularity contest. I suspect we'd just end up seeing thousands of votes
for "add more pictures to bootsplash" and "add this horribly broken
kernel patch to g-d-s"...

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Chris Bainbridge]

On Tuesday 27 July 2004 18:04, Ciaran McCreesh wrote:
> On Tue, 27 Jul 2004 12:54:49 -0400 Dylan Carlson <absinthe@gentoo.org>
>
> wrote:
> | 1.  Without bug voting, there's no way to determine what bugs are most
> | important to the public (or at least to the people using Bugzilla,
> | which is really *our* public, in a working sense).
>
> Well, given that most of our users don't seem to be able to get the
> priority field straight ("Waah! There's a tiny typo in an einfo
> statement! BLOCKER!"), 

Insulting the users; constructive!

> I'd be kind of sceptical about an easily rigged 
> popularity contest. I suspect we'd just end up seeing thousands of votes
> for "add more pictures to bootsplash" and "add this horribly broken
> kernel patch to g-d-s"...

Funny, this doesn't seem to be a problem for kde 
(http://bugs.kde.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=critical&bug_severity=grave&bug_severity=major&bug_severity=crash&bug_severity=normal&bug_severity=minor&votes=21&order=bugs.votes)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 1:04 pm, Ciaran McCreesh wrote:
> Well, given that most of our users don't seem to be able to get the
> priority field straight ("Waah! There's a tiny typo in an einfo
> statement! BLOCKER!"), I'd be kind of sceptical about an easily rigged
> popularity contest. I suspect we'd just end up seeing thousands of votes
> for "add more pictures to bootsplash" and "add this horribly broken
> kernel patch to g-d-s"...

That's a grim assessment.  In any case, it doesn't matter how someone 
spends their votes.  If many people spend votes for bootsplash, and 
bootsplash enhancements end up being a priority, then I would hope we 
would respond by incorporating them with the same priority as our own 
personal wishlists.

In any case, a bug has been created.
http://bugs.gentoo.org/show_bug.cgi?id=58568

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Peter Johanson]

[-- Attachment #1: Type: text/plain, Size: 1760 bytes --]

On Tue, Jul 27, 2004 at 01:27:29PM -0400, Dylan Carlson wrote:
> On Tuesday 27 July 2004 1:04 pm, Ciaran McCreesh wrote:
> > Well, given that most of our users don't seem to be able to get the
> > priority field straight ("Waah! There's a tiny typo in an einfo
> > statement! BLOCKER!"), I'd be kind of sceptical about an easily rigged
> > popularity contest. I suspect we'd just end up seeing thousands of votes
> > for "add more pictures to bootsplash" and "add this horribly broken
> > kernel patch to g-d-s"...
> 
> That's a grim assessment.  In any case, it doesn't matter how someone 
> spends their votes.  If many people spend votes for bootsplash, and 
> bootsplash enhancements end up being a priority, then I would hope we 
> would respond by incorporating them with the same priority as our own 
> personal wishlists.

I think the point (once you learn to decode ciaranm's acidic comments)
is that this voting may result in a group of overly zealous users
skewing things away from realistic priorities. We might see a bug about
reiser4 support in g-d-s  get pumped up to the top of the list, where a
bug about fixing a major but subtle flaw in base-layout might not get
any attention. (just an example (one that ciaranm will i'm sure enjoy))

None the less, i think enabling it warrants consideration.

-pete

> 
> In any case, a bug has been created.
> http://bugs.gentoo.org/show_bug.cgi?id=58568
> 
> Cheers,
> Dylan Carlson [absinthe@gentoo.org]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> 
> --
> gentoo-dev@gentoo.org mailing list
> 

-- 
Peter Johanson
<latexer@gentoo.org>

Key ID = 0x6EFA3917
Key fingerprint = A90A 2518 57B1 9D20 9B71  A2FF 8649 439B 6EFA 3917

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Olivier Crete]

On Tue, 2004-07-27 at 13:39 -0400, Peter Johanson wrote:
> On Tue, Jul 27, 2004 at 01:27:29PM -0400, Dylan Carlson wrote:
> > On Tuesday 27 July 2004 1:04 pm, Ciaran McCreesh wrote:
> > > Well, given that most of our users don't seem to be able to get the
> > > priority field straight ("Waah! There's a tiny typo in an einfo
> > > statement! BLOCKER!"), I'd be kind of sceptical about an easily rigged
> > > popularity contest. I suspect we'd just end up seeing thousands of votes
> > > for "add more pictures to bootsplash" and "add this horribly broken
> > > kernel patch to g-d-s"...
> > 
> > That's a grim assessment.  In any case, it doesn't matter how someone 
> > spends their votes.  If many people spend votes for bootsplash, and 
> > bootsplash enhancements end up being a priority, then I would hope we 
> > would respond by incorporating them with the same priority as our own 
> > personal wishlists.
> 
> I think the point (once you learn to decode ciaranm's acidic comments)
> is that this voting may result in a group of overly zealous users
> skewing things away from realistic priorities. We might see a bug about
> reiser4 support in g-d-s  get pumped up to the top of the list, where a
> bug about fixing a major but subtle flaw in base-layout might not get
> any attention. (just an example (one that ciaranm will i'm sure enjoy))
> 
> None the less, i think enabling it warrants consideration.

And since those votes are completely non-binding.. we are completely
free to ignore them if we believe they are wrong. It might still give
many devs who dont spend their time in #gentoo or the forums a more
direct idea of what users really care about.


-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Chris Gianelloni]

[-- Attachment #1: Type: text/plain, Size: 1739 bytes --]

On Tue, 2004-07-27 at 13:54, Olivier Crete wrote:
> > I think the point (once you learn to decode ciaranm's acidic comments)
> > is that this voting may result in a group of overly zealous users
> > skewing things away from realistic priorities. We might see a bug about
> > reiser4 support in g-d-s  get pumped up to the top of the list, where a
> > bug about fixing a major but subtle flaw in base-layout might not get
> > any attention. (just an example (one that ciaranm will i'm sure enjoy))
> > 
> > None the less, i think enabling it warrants consideration.
> 
> And since those votes are completely non-binding.. we are completely
> free to ignore them if we believe they are wrong. It might still give
> many devs who dont spend their time in #gentoo or the forums a more
> direct idea of what users really care about.

I tend to agree.  As long as there is no policy *forcing* us to follow
the results of the voting, I see no harm in it.  After all, it will be
easy enough for me to ignore the "add love-sources as default on the
livecd" votes... *grin*

What we will see is voting on lots of feature enhancements, which is
good, as it will give us a clue on what our users want from us.  What we
won't see is much voting on bugs that are actual bugs.  At least, not on
the ones we can actually fix.  When I spend time working on Gentoo, any
enhancements *always* take back seat to actual bugs, and always will no
matter how high they get "voted" simply because we should solve the
problems with things we're already supporting, before adding more
potential problems to the mix.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

Chris Gianelloni wrote:

> What we will see is voting on lots of feature enhancements, which is
> good, as it will give us a clue on what our users want from us.  What we
> won't see is much voting on bugs that are actual bugs.  At least, not on
> the ones we can actually fix.  When I spend time working on Gentoo, any
> enhancements *always* take back seat to actual bugs, and always will no
> matter how high they get "voted" simply because we should solve the
> problems with things we're already supporting, before adding more
> potential problems to the mix.

I should note that infrastructure is working on a survey system so we can get
more feedback from our users on features/etc. Not sure how this can be tied to
this bug voting thread, but I thought I'd at least let this be known. Its still
being worked on atm, but its in the works for the long run at least.

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] Bug voting

[Jason Rhinelander]

Peter Johanson wrote:
> On Tue, Jul 27, 2004 at 01:27:29PM -0400, Dylan Carlson wrote:
> 
>>On Tuesday 27 July 2004 1:04 pm, Ciaran McCreesh wrote:
>>
>>>Well, given that most of our users don't seem to be able to get the
>>>priority field straight ("Waah! There's a tiny typo in an einfo
>>>statement! BLOCKER!"), I'd be kind of sceptical about an easily rigged
>>>popularity contest. I suspect we'd just end up seeing thousands of votes
>>>for "add more pictures to bootsplash" and "add this horribly broken
>>>kernel patch to g-d-s"...
>>
>>That's a grim assessment.  In any case, it doesn't matter how someone 
>>spends their votes.  If many people spend votes for bootsplash, and 
>>bootsplash enhancements end up being a priority, then I would hope we 
>>would respond by incorporating them with the same priority as our own 
>>personal wishlists.
> 
> 
> I think the point (once you learn to decode ciaranm's acidic comments)
> is that this voting may result in a group of overly zealous users
> skewing things away from realistic priorities. We might see a bug about
> reiser4 support in g-d-s  get pumped up to the top of the list, where a
> bug about fixing a major but subtle flaw in base-layout might not get
> any attention. (just an example (one that ciaranm will i'm sure enjoy))
> 

Is that really a problem though?  Just because more people voted for A 
than B doesn't mean that the dev who chooses between the two has to do A 
- it simply provides a mode of input as to how many users want the 
feature.  When a dev knows that B is probably more important, he really 
isn't going to care that A got more votes - the voting only becomes a 
determining factor when similar ideas are considered.

On the other hand, there may well be many people who feel that votes == 
importance, and I think it ought to be made clear that this simply isn't 
the case - votes would serve as a way for people to say "me too" without 
actually cluttering up the bug report by typing "me too" into the 
comment box.

-- Jason Rhinelander
-- Gossamer Threads, Inc.

> None the less, i think enabling it warrants consideration.
> 
> -pete

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Duncan]

Jason Rhinelander posted <41069808.7040405@gossamer-threads.com>,
excerpted below,  on Tue, 27 Jul 2004 10:59:36 -0700:

> [V]otes would serve as a way for people to say "me too" without 
> actually cluttering up the bug report by typing "me too" into the 
> comment box.

IMO this is perhaps the important point.   The guidelines specifically say
/not/ to "me too" a bug, but sometimes it's tempting.  If there was a way
to vote for it instead, that would solve that problem.

In addition, I'm not sure if the vote is rigged this way by default, but
one could set it up such that it would notify on the first and second
vote, then not again until the fifth, then the tenth, etc.  In addition,
the vote reports, being automated and entirely predictable content, could
easily be filtered by devs not wishing to get them at all.  That of course
assumes that votes would be set to globally notify at all.

Gentoo's going to be rather different, but I came from Mandrake, where
each regular cooker tester/user got ten votes to spend as they wished each
month on bugzilla.  That kept the fakes down quite a bit, because one had
to actually participate in the process in ordered to get the ten vote
privilege.  One could still in theory participate under a bunch of names,
but that takes time.  A user could spend all ten votes on one thing if
they wanted, or spread them out to ten things.  I don't know if lower
level participants got say two votes, or if actual rpm contributors got
say 20, or not, but it could have been done.

Now some thinking in print..  As I said, Gentoo's different.  Perhaps
restrict general users to two votes a month.  Preventing ballot stuffing
might be problematic, as there's no way to limit registered nyms. 
However, regular reliable reporters and those contributing fixes might get
10 or 20 votes to use each month, an interesting recognition mechanism
short of dev-hood or the like.  If stuffing appears to be getting out of
hand, but not /entirely/ so, maybe up that to 50 or a hundred votes for
the reliable reporters and patch contributors, and while there'd be some
obvious vote inflation, equally obviously, they could effectively shout
down all but extreme stuffing.  One might also consider giving the legit
"super-voters" negative votes, costing the same vote points, but
subtracting votes, where abuse might be suspected.  A super-voter wouldn't
have to answer /why/ they voted something up or down, but abuse could be
curbed by revoking super-voter status, yanking vote points.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Tue, 27 Jul 2004 13:27:29 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Tuesday 27 July 2004 1:04 pm, Ciaran McCreesh wrote:
| > Well, given that most of our users don't seem to be able to get the
| > priority field straight ("Waah! There's a tiny typo in an einfo
| > statement! BLOCKER!"), I'd be kind of sceptical about an easily
| > rigged popularity contest. I suspect we'd just end up seeing
| > thousands of votes for "add more pictures to bootsplash" and "add
| > this horribly broken kernel patch to g-d-s"...
| 
| That's a grim assessment.  In any case, it doesn't matter how someone 
| spends their votes.  If many people spend votes for bootsplash, and 
| bootsplash enhancements end up being a priority, then I would hope we 
| would respond by incorporating them with the same priority as our own 
| personal wishlists.

Except that the voting will not be indicative of what our user base
actually wants. Instead, it will indicate the whim of a vocal minority
of Off The Wall posters and zealots from that IRC channel I'm not
allowed to talk about. Most of our users don't condone join-flooding
other distributions' channels on IRC. Most of our users give at least a
vague hoot about having a stable kernel and filesystem. Most of our
users would rather that their ebuilds compiled, even if it meant missing
out on the occasional x.x.x.1 release from upstream. However, most of
those users won't be voting.

We already have a good indication of how many people care about a bug --
the length of the Cc: list usually works pretty well.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 2:07 pm, Ciaran McCreesh wrote:
> Except that the voting will not be indicative of what our user base
> actually wants. Instead, it will indicate the whim of a vocal minority
> of Off The Wall posters and zealots from that IRC channel I'm not
> allowed to talk about. Most of our users don't condone join-flooding
> other distributions' channels on IRC. Most of our users give at least a
> vague hoot about having a stable kernel and filesystem. Most of our
> users would rather that their ebuilds compiled, even if it meant missing
> out on the occasional x.x.x.1 release from upstream. However, most of
> those users won't be voting.

Those are assumptions, nothing more.

> We already have a good indication of how many people care about a bug --
> the length of the Cc: list usually works pretty well.

Really?  So you think that if we started measuring the CC lists that it 
wouldn't somehow be tainted by the "vocal minority" that would otherwise 
be voting?  Your logic is totally flawed.

A person could easily CC: themselves on 1,000+ open bugs.   However, you 
are only allocated a certain number of votes, therefore a person has to 
exercise economy about what things matter to them most.

I frankly don't understand why you're so outspoken on this issue.  You can 
ignore votes if that's what you choose to do.  This is not a policy change 
proposal, this is an enhancement request for Bugzilla.  

It's optional for the users to use it, it's optional for us to make 
decisions based on it.  But in cases when it is used, it can be helpful to 
determine what bugs are causing the people most pain, or what enhancements 
are most desired.

Also please read: http://www.unixguide.net/freebsd/faq/16.19.shtml

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]

On Tue, 27 Jul 2004 14:18:55 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Tuesday 27 July 2004 2:07 pm, Ciaran McCreesh wrote:
| > Except that the voting will not be indicative of what our user base
| > actually wants. Instead, it will indicate the whim of a vocal
| > minority of Off The Wall posters and zealots from that IRC channel
| > I'm not allowed to talk about. Most of our users don't condone
| > join-flooding other distributions' channels on IRC. Most of our
| > users give at least a vague hoot about having a stable kernel and
| > filesystem. Most of our users would rather that their ebuilds
| > compiled, even if it meant missing out on the occasional x.x.x.1
| > release from upstream. However, most of those users won't be voting.
| 
| Those are assumptions, nothing more.

Those are assumptions based upon a very large amount of evidence
obtained from the forums, the -user mailing list and IRC. Like it or
not, we *do* have a small number of users who *do* going around
trolling, spamming and generally making a nuisance of themselves. You
really think that the aa-G aa-E thing is indicative of our user base?

| > We already have a good indication of how many people care about a
| > bug -- the length of the Cc: list usually works pretty well.
| 
| Really?  So you think that if we started measuring the CC lists that
| it wouldn't somehow be tainted by the "vocal minority" that would
| otherwise be voting?  Your logic is totally flawed.

No, I'm saying it's an indicator which already exists if someone wants
to find out how popular their bug might be, nothing more. However, Cc:
list spamming is pretty pointless, whereas vote spamming could be
construed to mean something.

| I frankly don't understand why you're so outspoken on this issue.  You
| can ignore votes if that's what you choose to do.  This is not a
| policy change proposal, this is an enhancement request for Bugzilla.  

1) Because it will lead to "this bug has over a hundred votes, why is
it being ignored?" posts.

2) Because it is yet another field in bugzilla. We already have far too
many clicky boxes for most people.

3) Because it will lead to vote spamming. Search the Off The Wall forum
for "portage ignorance" for a good example of why this won't work.

| Also please read: http://www.unixguide.net/freebsd/faq/16.19.shtml

Posting irrelevant links does not make an argument.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 2:45 pm, Ciaran McCreesh wrote:

> Those are assumptions based upon a very large amount of evidence

So you admit that they are assumptions, based on anecdotal evidence.

> No, I'm saying it's an indicator which already exists if someone wants
> to find out how popular their bug might be, nothing more. However, Cc:
> list spamming is pretty pointless, whereas vote spamming could be
> construed to mean something.

Funny, that's the idea.  It's not spamming if you have a finite amount of 
votes.  People can spend them any way they choose.  If you spend your 
votes on enhancement requests to app-misc/hello-kitty, that's your choice.

What ultimately matters is the sum of all user votes.  It's safe to say the 
top-10 most voted list would be something we should consider paying more 
attention to.

> | I frankly don't understand why you're so outspoken on this issue.  You
> | can ignore votes if that's what you choose to do.  This is not a
> | policy change proposal, this is an enhancement request for Bugzilla.
>
> 1) Because it will lead to "this bug has over a hundred votes, why is
> it being ignored?" posts.

And would such posts be unreasonable?  I don't think so.  If a bug has a 
large # of votes relative to everything else, and it IS being ignored, 
it's a valid question.

> 2) Because it is yet another field in bugzilla. We already have far too
> many clicky boxes for most people.

We have a wizard bug reporting interface which does not change as a result 
of bug voting.  At most the bug page will show the # of votes, and will 
add one more link at the bottom to vote for the bug.  Big deal.

Keep reaching.

> 3) Because it will lead to vote spamming. Search the Off The Wall forum
> for "portage ignorance" for a good example of why this won't work.

Hmm, voting seems to work pretty well for KDE and Mozilla, among others.  
And it's a trivial change, which again, you seem to be reaching for 
reasons to shoot holes through.  If it doesn't work out, we turn votes 
off, it's as simple as that.

> | Also please read: http://www.unixguide.net/freebsd/faq/16.19.shtml
>
> Posting irrelevant links does not make an argument.

It's not irrelevant, if you actually take a minute to read it instead of 
posting more FUD against bugzilla voting.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 3881 bytes --]

On Tue, 27 Jul 2004 15:26:46 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Tuesday 27 July 2004 2:45 pm, Ciaran McCreesh wrote:
| > Those are assumptions based upon a very large amount of evidence
| 
| So you admit that they are assumptions, based on anecdotal evidence.

Uh, no. They are assumptions based upon a very large body of direct
evidence. Since we can't go and ask every single user what they think,
that's the best we can get.

| > No, I'm saying it's an indicator which already exists if someone
| > wants to find out how popular their bug might be, nothing more.
| > However, Cc: list spamming is pretty pointless, whereas vote
| > spamming could be construed to mean something.
| 
| Funny, that's the idea.  It's not spamming if you have a finite amount
| of votes.  People can spend them any way they choose.  If you spend
| your votes on enhancement requests to app-misc/hello-kitty, that's
| your choice.

That's just it, though. Doesn't take much effort to get a few hundred
Off The Wall readers to register multiple accounts and vote-bomb a bug
because it's 'funny' or 'cool'. Like I said, search for "portage
ignorance" in Off The Wall and you'll see a perfect example.

| What ultimately matters is the sum of all user votes.  It's safe to
| say the top-10 most voted list would be something we should consider
| paying more attention to.

No, the top-10 will end up containing "support reiser4 in g-d-s" and
"add kernel-I'm-not-allowed-to-name to portage". See aforementioned OTW
thread.

| > | I frankly don't understand why you're so outspoken on this issue. 
| > | You can ignore votes if that's what you choose to do.  This is not
| > | a policy change proposal, this is an enhancement request for
| > | Bugzilla.
| >
| > 1) Because it will lead to "this bug has over a hundred votes, why
| > is it being ignored?" posts.
| 
| And would such posts be unreasonable?  I don't think so.  If a bug has
| a large # of votes relative to everything else, and it IS being
| ignored, it's a valid question.

You're assuming that a) votes equate to what our users want, and b) our
users understand every single issue involved. As Peter already
suggested, the subtle but important bugs won't get voted on, because
most people don't know what they're about.

| > 2) Because it is yet another field in bugzilla. We already have far
| > too many clicky boxes for most people.
| 
| We have a wizard bug reporting interface which does not change as a
| result of bug voting.  At most the bug page will show the # of votes,
| and will add one more link at the bottom to vote for the bug.  Big
| deal.

Our interface is already complex enough that most people need a wizard.
Why add even more to it?

| > 3) Because it will lead to vote spamming. Search the Off The Wall
| > forum for "portage ignorance" for a good example of why this won't
| > work.
| 
| Hmm, voting seems to work pretty well for KDE and Mozilla, among
| others.  And it's a trivial change, which again, you seem to be
| reaching for reasons to shoot holes through.  If it doesn't work out,
| we turn votes off, it's as simple as that.

It's a trivial change with a rather large potential impact which
shouldn't be implemented until all the implications are understood.

| > | Also please read: http://www.unixguide.net/freebsd/faq/16.19.shtml
| >
| > Posting irrelevant links does not make an argument.
| 
| It's not irrelevant, if you actually take a minute to read it instead
| of posting more FUD against bugzilla voting.

Of course it's irrelevant. The colour of the bike shed doesn't matter.
Whether or not we enable a feature which could end up causing serious
problems for developers matters a lot. Two entirely separate issues.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 778 bytes --]

On Tue, 2004-07-27 at 16:09, Ciaran McCreesh wrote:
> On Tue, 27 Jul 2004 15:26:46 -0400 Dylan Carlson <absinthe@gentoo.org>
> wrote:
> | On Tuesday 27 July 2004 2:45 pm, Ciaran McCreesh wrote:
> | > Those are assumptions based upon a very large amount of evidence
> | 
> | So you admit that they are assumptions, based on anecdotal evidence.
> 
> Uh, no. They are assumptions based upon a very large body of direct
> evidence. Since we can't go and ask every single user what they think,
> that's the best we can get.

Instead of randomly talking about this, why doesn't someone who cares
about getting it turned on go to other projects using it and ask them
why they did it, what the results have been and how they are used?
-- 
Donnie Berkholz
Gentoo Linux

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Spider]

[-- Attachment #1: Type: text/plain, Size: 574 bytes --]

begin  quote
On Tue, 27 Jul 2004 21:09:43 +0100
Ciaran McCreesh <ciaranm@gentoo.org> wrote:

> 
> Of course it's irrelevant. The colour of the bike shed doesn't matter.
> Whether or not we enable a feature which could end up causing serious
> problems for developers matters a lot. Two entirely separate issues.

*laugh*  Long since I saw this anecdote.


personally, I don't think that adding voting will gain either us or our
users anything.  


//Spider


-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 4:09 pm, Ciaran McCreesh wrote:
>
> Uh, no. They are assumptions based upon a very large body of direct
> evidence. Since we can't go and ask every single user what they think,
> that's the best we can get.

No, that's the best you have, which is another way of saying, nothing.
The problem here is that you presume to know what is best for everyone, and 
worse, what everyone else wants.

> That's just it, though. Doesn't take much effort to get a few hundred
> Off The Wall readers to register multiple accounts and vote-bomb a bug
> because it's 'funny' or 'cool'. Like I said, search for "portage
> ignorance" in Off The Wall and you'll see a perfect example.


bugzilla != phpbb

And I'll say it again:  voting works great for KDE and Mozilla-- which are 
very large projects such as ours (if not larger).  

> No, the top-10 will end up containing "support reiser4 in g-d-s" and
> "add kernel-I'm-not-allowed-to-name to portage". See aforementioned OTW
> thread.

Again, assumptions.   Even if that were true, and most of our users wanted 
reiser4 in g-d-s, then I hope we would at least give them some time to 
consider it.


> You're assuming that a) votes equate to what our users want, and b) our
> users understand every single issue involved. As Peter already
> suggested, the subtle but important bugs won't get voted on, because
> most people don't know what they're about.

a) I'm not assuming that.  The numbers are what they are.  Among Gentoo 
users who are in Bugzilla, and voting. (x) votes have been cast for this 
bug.  Nothing more, nothing less.

b) Subtle but important to whom?  You?  Yes, I can see why letting people 
vote would be a problem for you.  It would potentially shift the 
priorities from the things you feel are important to what the users feel 
are important.

> Our interface is already complex enough that most people need a wizard.
> Why add even more to it?

Because it encourages participation in the process of developing Gentoo.   
It gives people a feature to tell us what's important to them, instead of 
just filing bugs which, to some users, seem to be a black hole.   Voting 
gives people a simple way of expressing, "this is important to me".

Perhaps it would lead to less people filing blocker/critical bugs if they 
felt they could attract attention to a bug by other means.

Package feedback as a separate effort is good, but that doesn't address 
bugs which address all of Gentoo, as a project including our 
documentation, infrastructure, etc.

> Of course it's irrelevant. The colour of the bike shed doesn't matter.
> Whether or not we enable a feature which could end up causing serious
> problems for developers matters a lot. Two entirely separate issues.

Really.  How would enabling voting cause "serious problems" for developers?  

1.  It doesn't change how you (or anyone else) is using Bugzilla
2.  It's a completely opt-in feature, for users and devs alike
3.  It can be quickly disabled at any time.

Sure, serious problems there.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2825 bytes --]

On Tue, 27 Jul 2004 16:37:03 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Tuesday 27 July 2004 4:09 pm, Ciaran McCreesh wrote:
| > Uh, no. They are assumptions based upon a very large body of direct
| > evidence. Since we can't go and ask every single user what they
| > think, that's the best we can get.
| 
| No, that's the best you have, which is another way of saying, nothing.

I'd hardly call 30,000 emails and however many forums posts there are
"nothing".

| > No, the top-10 will end up containing "support reiser4 in g-d-s" and
| > "add kernel-I'm-not-allowed-to-name to portage". See aforementioned
| > OTW thread.
| 
| Again, assumptions.   Even if that were true, and most of our users
| wanted reiser4 in g-d-s, then I hope we would at least give them some
| time to consider it.

Go take a look at the thread.

| b) Subtle but important to whom?  You?  Yes, I can see why letting
| people vote would be a problem for you.  It would potentially shift
| the priorities from the things you feel are important to what the
| users feel are important.

No, subtle as in "this bug will cause people various really strange
problems, but they won't realise what's causing it". Don't forget, the
package maintainers quite often know a lot more about the package and
the way it interacts with the system than the bug submitters and voters.

Good example: the automagic link detection before DHCP feature that
people keep on wanting in baselayout. Looks nice on the surface, lots of
people saying "yes please", but suddenly when it's implemented we get
thousands of users with broken networking because it turns out that that
nifty link detection feature isn't universally reliable.

| Because it encourages participation in the process of developing
| Gentoo.   It gives people a feature to tell us what's important to
| them, instead of just filing bugs which, to some users, seem to be a
| black hole.   Voting gives people a simple way of expressing, "this is
| important to me".

See below...

| Perhaps it would lead to less people filing blocker/critical bugs if
| they felt they could attract attention to a bug by other means.

Assumptions

| Really.  How would enabling voting cause "serious problems" for
| developers?  
| 
| 1.  It doesn't change how you (or anyone else) is using Bugzilla
| 2.  It's a completely opt-in feature, for users and devs alike
| 3.  It can be quickly disabled at any time.

Well, either the voting affects developers, in which case it's a serious
problem because it'll detract from the bugs which are *actually*
important, or it won't affect developers, in which case your claims
above are effectively meaningless.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 5:39 pm, Ciaran McCreesh wrote:

> I'd hardly call 30,000 emails and however many forums posts there are
> "nothing".

Wasn't it you who called them the "vocal minority"?   

In any event, they are our users... and ultimately the more, simple tools 
we can give users to let us know what they think is important, the better 
we are able to prioritize what gets worked on -- particularly enhancements 
to our tools.

> No, subtle as in "this bug will cause people various really strange
> problems, but they won't realise what's causing it". Don't forget, the
> package maintainers quite often know a lot more about the package and
> the way it interacts with the system than the bug submitters and voters.

Right, a completely isolated case.   As a package maintainer should know 
more than most users.  But ultimately, most bugs (that haven't been closed 
out as INVALID/etc) are either problems with the way something works now, 
or an enhancement request.   You think that votes get cast for stupid 
things?  Do you really think our users are stupid? 

Go on, look at KDE's bug system w/votes, or Mozilla's for that matter.

I'll save you the trouble:

KDE defects with votes: http://tinyurl.com/c5ja
KDE enhancements with votes: http://tinyurl.com/c5j3
Mozilla bugs with votes:  http://tinyurl.com/59dxl

Do those bugs that have votes look like a waste of time to you?  The users 
for KDE, Mozilla, etc use the voting system responsibly and I believe ours 
will too.

> Well, either the voting affects developers, in which case it's a serious
> problem because it'll detract from the bugs which are *actually*
> important, or it won't affect developers, in which case your claims
> above are effectively meaningless.

It won't influence any developers (like you) who choose to ignore the 
votes.  For others, it will be a tool like any other (severity, priority, 
etc) to help determine what needs attention.  It's not a mandate.

For developers such as yourself, what are you worried about?  Ignore the 
votes and keep working on your buglist like you normally would.  I fail to 
see the problem here.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]

On Tue, 27 Jul 2004 18:24:48 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Tuesday 27 July 2004 5:39 pm, Ciaran McCreesh wrote:
| > I'd hardly call 30,000 emails and however many forums posts there
| > are"nothing".
| 
| Wasn't it you who called them the "vocal minority"?   

No, I said that that provided strong evidence that we do have a vocal
minority who go around demanding the latest x.x.x.1 releases, spamming
other distributions' IRC channels, using broken kernels and so on.

| Right, a completely isolated case.   As a package maintainer should
| know more than most users.  But ultimately, most bugs (that haven't
| been closed out as INVALID/etc) are either problems with the way
| something works now, or an enhancement request.   You think that votes
| get cast for stupid things?  Do you really think our users are stupid?

I think votes will get cast for trivial cosmetic features (example:
bootsplash) rather than the subtle can-make-your-system-die-horribly
bugs. So, for those kinds of bugs, we'll either have to ignore the
voting (which pretty much defeats the object of having votes at all) or
focus on the 'popular' enhancements at the expense of having a working
system.

| For developers such as yourself, what are you worried about?  Ignore
| the votes and keep working on your buglist like you normally would.  I
| fail to see the problem here.

I am worried that I will see posts saying "why are you ignoring the
several hundred votes on this bug?" on bugs for small cosmetic issues
(example: bootsplash) when there are far more important bugs which don't
attract votes. Although *I* will be ignoring the votes, the voters won't
be.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 6:59 pm, Ciaran McCreesh wrote:
> I think votes will get cast for trivial cosmetic features (example:
> bootsplash) rather than the subtle can-make-your-system-die-horribly
> bugs. So, for those kinds of bugs, we'll either have to ignore the
> voting (which pretty much defeats the object of having votes at all) or
> focus on the 'popular' enhancements at the expense of having a working
> system.

Why speculate?  Especially when it's not happening elsewhere in other large 
open-source projects that have voting turned on?

> I am worried that I will see posts saying "why are you ignoring the
> several hundred votes on this bug?" on bugs for small cosmetic issues
> (example: bootsplash) when there are far more important bugs which don't
> attract votes. Although *I* will be ignoring the votes, the voters won't
> be.

Why are you worried about something that hasn't happened?  You're putting 
the cart in front of the horse.  Voting works well for other large 
projects using bugzilla, and there's nothing that would suggest it 
wouldn't work for us.  If vocal/spamming forum users were a problem for 
bugzilla, dot.kde.org users would have made a mess of bugs.kde.org by now.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Tom Wesley]

[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]

On Tue, 2004-07-27 at 19:12 -0400, Dylan Carlson wrote:
> On Tuesday 27 July 2004 6:59 pm, Ciaran McCreesh wrote:
> > I think votes will get cast for trivial cosmetic features (example:
> > bootsplash) rather than the subtle can-make-your-system-die-horribly
> > bugs. So, for those kinds of bugs, we'll either have to ignore the
> > voting (which pretty much defeats the object of having votes at all) or
> > focus on the 'popular' enhancements at the expense of having a working
> > system.
> 
> Why speculate?  Especially when it's not happening elsewhere in other large 
> open-source projects that have voting turned on?
> 
> > I am worried that I will see posts saying "why are you ignoring the
> > several hundred votes on this bug?" on bugs for small cosmetic issues
> > (example: bootsplash) when there are far more important bugs which don't
> > attract votes. Although *I* will be ignoring the votes, the voters won't
> > be.
> 
> Why are you worried about something that hasn't happened?  You're putting 
> the cart in front of the horse.  Voting works well for other large 
> projects using bugzilla, and there's nothing that would suggest it 
> wouldn't work for us.  If vocal/spamming forum users were a problem for 
> bugzilla, dot.kde.org users would have made a mess of bugs.kde.org by now.
> 
> Cheers,
> Dylan Carlson [absinthe@gentoo.org]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> 

Cart before the horse, or an insight into the minds of the masses,
either way it's a situation that surely has to happen.  I can see the
OTW postings of "Ignorant @gentoo.org dev ignores 300+ votes on kde-
themes-even-more-we-dont-need-0.0.0.1.ebuild"

I do, however, think that the development team should be capable of
ignoring those posts and not losing too much sleep over them.

However, I believe that voting as is done in the KDE project would allow
a reflection of different things for different types of bugs
  a) Enhancements:  How many users would like to see the feature add.
  b) Real bugs:  How much of a pain in the arse is this bug for people.

If you limit the number of votes people can have, as KDE do then people
will be more likely to vote for pain pain in the arse bugs than they
would enhancements.

As another point mentioned somewhere in this thread, bugs are not always
marked as with correct status.  Surely if dev's spot this then they
should alter the bug then and there?

-- 
Tom Wesley <tom@tomaw.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Tommi Pirinen]

Ciaran McCreesh wrote:

>No, subtle as in "this bug will cause people various really strange
>problems, but they won't realise what's causing it". Don't forget, the
>package maintainers quite often know a lot more about the package and
>the way it interacts with the system than the bug submitters and voters.
>
>  
>
IMHO situation like this, when developer knows more than bug reporters, 
should be handled by marking the bug invalid, wontfix or later with an 
explanation. The current situation often seems that developers decide to 
"know more" without saying it to anyone, and from user/bug reporter 
point of view it seems as if he hasn't been heard or no one cares about 
the issue.

The main deal with this whole discussion to me as end user seems that 
gentoo's bugzilla has gotten very much of the reputation that bugs just 
sit there without no one noticing. As you might have noticed this 
concern comes up a lot in the user fora and granted, the reason might be 
the stupidity of users, but I'm sure it won't go away soon. Most of the 
people complaining about it do report at other projects as well, and 
from my and their experience other projects do have quite a lot better 
response times from bugzilla than gentoo does. Of course this bug voting 
wouldn't be much of help to the actual problem, more than just slowdown 
for the most eager bug reporters.

>Good example: the automagic link detection before DHCP feature that
>people keep on wanting in baselayout. Looks nice on the surface, lots of
>people saying "yes please", but suddenly when it's implemented we get
>thousands of users with broken networking because it turns out that that
>nifty link detection feature isn't universally reliable.
>
>  
>
So it's users' fault that someone implemented and released broken 
feature? I know that job of developers isn't easy either, but I think 
this example isn't very good argumentation against anything. And if the 
developer here knew more, he could've just said it's not reliable enough 
to implement.

>Well, either the voting affects developers, in which case it's a serious
>problem because it'll detract from the bugs which are *actually*
>important, or it won't affect developers, in which case your claims
>above are effectively meaningless.
>
>  
>
Or the voting keeps users doing something that seems important to them ;-)


-- 
Flammie, generally nobody from nowhere in the internet.
Uninteresting generic profile at
<URL: http://cs.joensuu.fi/%7Etpirinen>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 2067 bytes --]

On Wed, 28 Jul 2004 01:49:39 +0300 Tommi Pirinen
<tommi.pirinen@kolumbus.fi> wrote:
| The main deal with this whole discussion to me as end user seems that 
| gentoo's bugzilla has gotten very much of the reputation that bugs
| just sit there without no one noticing. As you might have noticed this
| concern comes up a lot in the user fora and granted, the reason might
| be the stupidity of users, but I'm sure it won't go away soon. Most of
| the people complaining about it do report at other projects as well,
| and from my and their experience other projects do have quite a lot
| better response times from bugzilla than gentoo does. Of course this
| bug voting wouldn't be much of help to the actual problem, more than
| just slowdown for the most eager bug reporters.

I've been flamed by a couple of users for not adding a broken gtk-2 file
selector patch to gvim. There're several "please add my horridly broken
ebuild for this lame package which is full of bugs and unmaintained
upstream" bugs which I'd love to close as WONTFIX, but past experience
has shown that it's generally easiest to just leave them alone. Closing
a bug as WONTFIX really upsets some people, no matter what the reason.
If I ignore a bug instead, chances are no-one's gonna know that I'm the
person to flame :)

| >Good example: the automagic link detection before DHCP feature that
| >people keep on wanting in baselayout. Looks nice on the surface, lots
| >of people saying "yes please", but suddenly when it's implemented we
| >get thousands of users with broken networking because it turns out
| >that that nifty link detection feature isn't universally reliable.
| >
| So it's users' fault that someone implemented and released broken 
| feature?

No no. It's that people keep on submitting patches for a thing which we
already know is broken, despite there being existing bugs documenting
why it ended up not working.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Tommi Pirinen]

Ciaran McCreesh wrote:

>I've been flamed by a couple of users for not adding a broken gtk-2 file
>selector patch to gvim. There're several "please add my horridly broken
>ebuild for this lame package which is full of bugs and unmaintained
>upstream" bugs which I'd love to close as WONTFIX, but past experience
>has shown that it's generally easiest to just leave them alone. Closing
>a bug as WONTFIX really upsets some people, no matter what the reason.
>If I ignore a bug instead, chances are no-one's gonna know that I'm the
>person to flame :)
>  
>
Well, there will unfortunately be some of those kind of users as well. 
But still, when bumping in to bugs like this all an end user sees is 
that there's an untouched bug that no one seems to care about, most 
probably the user won't know the brokedness of issue but will rather 
deduce ignorance or laziness of maintainers. The issue is problematic 
though, and I don't know a definitive answer which would work for all, 
but I'd still like a bit more response to bug reports from time to time. 
It's very frustrating to send bug reports when it seems that no one 
reads them.

-- 
Flammie, generally nobody from nowhere in the internet.
Uninteresting generic profile at
<URL: http://cs.joensuu.fi/%7Etpirinen>


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Tom Wesley]

[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]

On Wed, 2004-07-28 at 02:46 +0300, Tommi Pirinen wrote:
> Ciaran McCreesh wrote:
> 
> >I've been flamed by a couple of users for not adding a broken gtk-2 file
> >selector patch to gvim. There're several "please add my horridly broken
> >ebuild for this lame package which is full of bugs and unmaintained
> >upstream" bugs which I'd love to close as WONTFIX, but past experience
> >has shown that it's generally easiest to just leave them alone. Closing
> >a bug as WONTFIX really upsets some people, no matter what the reason.
> >If I ignore a bug instead, chances are no-one's gonna know that I'm the
> >person to flame :)
> >  
> >
> Well, there will unfortunately be some of those kind of users as well. 
> But still, when bumping in to bugs like this all an end user sees is 
> that there's an untouched bug that no one seems to care about, most 
> probably the user won't know the brokedness of issue but will rather 
> deduce ignorance or laziness of maintainers. The issue is problematic 
> though, and I don't know a definitive answer which would work for all, 
> but I'd still like a bit more response to bug reports from time to time. 
> It's very frustrating to send bug reports when it seems that no one 
> reads them.
> 

I agree with this point.  If a dev is scared (/me uses word gently in
case my vision of an angry Scott as Ciaran is true) of marking bugs they
wont fix as WONTFIX then they just appear untouched and obviously adds a
huge amount of apparently open bugs.

Surely a quick comment to say "Patch breaks <something> and not
supported upstream, WONTFIX" is better in that case

-- 
Tom Wesley <tom@tomaw.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Georgi Georgiev]

maillog: 28/07/2004-07:55:16(+0100): Tom Wesley types
> On Wed, 2004-07-28 at 02:46 +0300, Tommi Pirinen wrote:
> > Ciaran McCreesh wrote:
> > 
> > >I've been flamed by a couple of users for not adding a broken gtk-2 file
> > >selector patch to gvim. There're several "please add my horridly broken
> > >ebuild for this lame package which is full of bugs and unmaintained
> > >upstream" bugs which I'd love to close as WONTFIX, but past experience
> > >has shown that it's generally easiest to just leave them alone. Closing
> > >a bug as WONTFIX really upsets some people, no matter what the reason.
> > >If I ignore a bug instead, chances are no-one's gonna know that I'm the
> > >person to flame :)
> > >  
> > >
> > Well, there will unfortunately be some of those kind of users as well. 
> > But still, when bumping in to bugs like this all an end user sees is 
> > that there's an untouched bug that no one seems to care about, most 
> > probably the user won't know the brokedness of issue but will rather 
> > deduce ignorance or laziness of maintainers. The issue is problematic 
> > though, and I don't know a definitive answer which would work for all, 
> > but I'd still like a bit more response to bug reports from time to time. 
> > It's very frustrating to send bug reports when it seems that no one 
> > reads them.
> 
> I agree with this point.  If a dev is scared (/me uses word gently in
> case my vision of an angry Scott as Ciaran is true) of marking bugs they
> wont fix as WONTFIX then they just appear untouched and obviously adds a
> huge amount of apparently open bugs.
> 
> Surely a quick comment to say "Patch breaks <something> and not
> supported upstream, WONTFIX" is better in that case

I'd also like to add that intentionally leaving a bug open in this case
is *very* irresponsible.

-- 
-*   Georgi Georgiev   -* In order to get a loan you must first        -*
*-    chutz@gg3.net    *- prove you don't need it.                     *-
-*  +81(90)6266-1163   -*                                              -*

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]

Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:

> The main deal with this whole discussion to me as end user seems
> that gentoo's bugzilla has gotten very much of the reputation that
> bugs just sit there without no one noticing.

As a user I have to second this view.  There are 37 ~amd64 keyword
bugs in bugzilla. (14 of them are from me and would only require
adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
a week old.

Either they don't get closed properly (they are all NEW:
http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=works+on&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=amd64%40gentoo.org&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=)
or they just aren't acted upon.

So well, *I* think those bugs sit just there waiting with few caring
about them.  YMMV, of course.

        Gabriel.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

[-- Attachment #1: Type: text/plain, Size: 1339 bytes --]

[ Sorry.  Either I or app-emacs/gnus screwed up the last post. ]

Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:

> The main deal with this whole discussion to me as end user seems
> that gentoo's bugzilla has gotten very much of the reputation that
> bugs just sit there without no one noticing.

As a user I have to second this view.  There are 37 ~amd64 keyword
bugs in bugzilla. (14 of them are from me and would only require
adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
a week old.

Either they don't get closed properly (they are all NEW:
http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=works+on&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=amd64%40gentoo.org&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=)
or they just aren't acted upon.

So well, *I* think those bugs sit just there waiting with few caring
about them.  YMMV, of course.

        Gabriel.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

[ Hope it works this time. ]

Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:

> The main deal with this whole discussion to me as end user seems
> that gentoo's bugzilla has gotten very much of the reputation that
> bugs just sit there without no one noticing.

As a user I have to second this view.  There are 37 ~amd64 keyword
bugs in bugzilla. (14 of them are from me and would only require
adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
a week old.

Either they don't get closed properly (they are all NEW:
http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=works+on&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=amd64%40gentoo.org&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=)
or they just aren't acted upon.

So well, *I* think those bugs sit just there waiting with few caring
about them.  YMMV, of course.

        Gabriel.

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

[ Somewhere multipart/signed messages get broken.  Strange. ]

Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:

> The main deal with this whole discussion to me as end user seems
> that gentoo's bugzilla has gotten very much of the reputation that
> bugs just sit there without no one noticing.

As a user I have to second this view.  There are 37 ~amd64 keyword
bugs in bugzilla. (14 of them are from me and would only require
adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
a week old.

Either they don't get closed properly (they are all NEW:
http://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=works+on&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=amd64%40gentoo.org&bugidtype=include&bug_id=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=)
or they just aren't acted upon.

So well, *I* think those bugs sit just there waiting with few caring
about them.  YMMV, of course.

        Gabriel.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 895 bytes --]

On Wed, 28 Jul 2004 01:52:33 +0200 Gabriel Ebner <ge@gabrielebner.at>
wrote:
| Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:
| > The main deal with this whole discussion to me as end user seems
| > that gentoo's bugzilla has gotten very much of the reputation that
| > bugs just sit there without no one noticing.
| 
| As a user I have to second this view.  There are 37 ~amd64 keyword
| bugs in bugzilla. (14 of them are from me and would only require
| adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
| a week old.

Some keywording bugs sit there for *a week* and you're upset? Keywording
isn't just a case of adding in the keyword blindly, ya know. An arch dev
has to actually test the app in question too.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bug voting

[Mike Frysinger]

On Tuesday 27 July 2004 08:02 pm, Ciaran McCreesh wrote:
> Some keywording bugs sit there for *a week* and you're upset? Keywording
> isn't just a case of adding in the keyword blindly, ya know. An arch dev
> has to actually test the app in question too.

a lot sit there for much longer than a week
-mike

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

Ciaran McCreesh <ciaranm@gentoo.org> writes:

> Keywording isn't just a case of adding in the keyword blindly, ya
> know. An arch dev has to actually test the app in question too.

Oh, didn't know that.  I'm not an arch dev. :-)

    Gabriel


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Jon Portnoy]

On Wed, Jul 28, 2004 at 01:52:33AM +0200, Gabriel Ebner wrote:
> [ Somewhere multipart/signed messages get broken.  Strange. ]
> 
> Tommi Pirinen <tommi.pirinen@kolumbus.fi> writes:
> 
> > The main deal with this whole discussion to me as end user seems
> > that gentoo's bugzilla has gotten very much of the reputation that
> > bugs just sit there without no one noticing.
> 
> As a user I have to second this view.  There are 37 ~amd64 keyword
> bugs in bugzilla. (14 of them are from me and would only require
> adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
> a week old.
> 

Keywording bugs are a much lesser priority than "real bugs" -- I don't 
see how a week is really that bad for something like that.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

Jon Portnoy <avenj@gentoo.org> writes:

> Keywording bugs are a much lesser priority than "real bugs" -- I don't 
> see how a week is really that bad for something like that.

I thought they were simpler to fix (simpler than "real bugs").  But as
Ciaran pointed out, arch devs seem to actually test the app in
question, so my point is moot.

          Gabriel.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 7:52 pm, Gabriel Ebner wrote:
> As a user I have to second this view.  There are 37 ~amd64 keyword
> bugs in bugzilla. (14 of them are from me and would only require
> adding ~amd64 to the KEYWORDS.)  The oldest simple bug (no replies) is
> a week old.

As a user, or anyone really, your expectations are a bit too high.  Let's 
take one of the bugs you filed, for instance -- dev-util/darcs:

...which depends on virtual/ghc (not currently available), wxhaskell (not 
currently available) which in turn depends on haddock (not currently 
available).

You're just in luck that I've been using darcs for the past week or so, and 
if I give it one more pass tonight, I will make those packages available. 
And as Ciaran pointed out, we don't blindly keyword packages just because 
they manage to compile.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

Dylan Carlson <absinthe@gentoo.org> writes:

> As a user, or anyone really, your expectations are a bit too high.

Well, I was assuming fixing those bugs involved only adding the arch
to the KEYWORDS.  But if the devs actually test the package (which
they might not have ever used nor have an idea on how to test it
without reading the docs), that's really a bit much to expect from
volunteers.  So you're right -- I'm in no position to demand anything
at all.

> Let's take one of the bugs you filed, for instance --
> dev-util/darcs:
>
> ...which depends on virtual/ghc (not currently available), wxhaskell (not 
> currently available) which in turn depends on haddock (not currently 
> available).

Well, bugs are filed for all of them.

> You're just in luck that I've been using darcs for the past week or so, and 
> if I give it one more pass tonight, I will make those packages available. 
> And as Ciaran pointed out, we don't blindly keyword packages just because 
> they manage to compile.

Thanks.

        Gabriel.


--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Gabriel Ebner]

Gabriel Ebner <ge@gabrielebner.at> writes:

>> Let's take one of the bugs you filed, for instance --
>> dev-util/darcs:
>>
>> ...which depends on virtual/ghc (not currently available), wxhaskell (not 
>> currently available) which in turn depends on haddock (not currently 
>> available).
>
> Well, bugs are filed for all of them.
>
>> You're just in luck that I've been using darcs for the past week or so, and 

Forgot to add: If you don't already have ghc working on amd64, plan in
a couple of hours to bootstrap ghc (a simple build took 3 hours here
-- so once again I should rather thank you than expecting you to add
the keywords now).

>> if I give it one more pass tonight, I will make those packages available. 
>> And as Ciaran pointed out, we don't blindly keyword packages just because 
>> they manage to compile.
>
> Thanks.

    Gabriel.


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[David Sparks]

> No, the top-10 will end up containing "support reiser4 in g-d-s" and
> "add kernel-I'm-not-allowed-to-name to portage". See aforementioned OTW
> thread.

Change the bug resolution to WONTFIX and close it.  It doesn't matter 
how many votes a closed bug gets does it?  I don't see what the problem is.

ds

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Stephen P. Becker]

> 
>>| I frankly don't understand why you're so outspoken on this issue.  You
>>| can ignore votes if that's what you choose to do.  This is not a
>>| policy change proposal, this is an enhancement request for Bugzilla.
>>
>>1) Because it will lead to "this bug has over a hundred votes, why is
>>it being ignored?" posts.
> 
> 
> And would such posts be unreasonable?  I don't think so.  If a bug has a 
> large # of votes relative to everything else, and it IS being ignored, 
> it's a valid question.
> 

The answer is, that depends on the feature/ebuild/bug being voted on.  I 
think ciaranm's thought on this point really gets down to the heart of 
the problem with voting.

There are two ways of looking at this.  First, we as devs have a 
responsibility to incorporate features/ebuilds and fix bugs that our 
users want.  Second, we have a responsibility to protect our users from 
completely fragging their systems, even those who have demonstrated they 
will go out of their way to do so at any chance.

I think the first point is adequately covered by bugzilla as it is.  If 
a user wants a new ebuild included or a bug fixed, he/she files a bug 
for it.  The problem with this is that we simply don't have enough devs 
right now to cover the sheer volume of stuff in bugzilla.  This is a 
fixable problem, however.  As for the second point, I think we already 
do a good job at that, like not including certain kernel source packages 
that include potentially dangerous patches like reiser4.  We also inform 
users we will not support them if they install 3rd-party-sources or 
stuff from breakymgentoo.  This is all very reasonable.

Considering these two points, I think you have to either say "yes, we 
are going to prioritize high votes" or "we're going to protect our users 
from potentially unstable stuff and use discretion instead."

Now that I've rambled on, let me get to what I really think.  I believe 
bug voting would be great for bugs that are truly problems with 
supported configurations/ebuilds.  However, I do not think voting should 
be considered for additions of new ebuilds into portage.  It will create 
too many posts whining that system-killer-6.6.6.ebuild has not been 
added to portage.  As I said before, I'm not sure we can have it both 
ways without there being problems, so I would say voting is a bad idea.

Steve (geoman)

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Kumba]

Dylan Carlson wrote:

> Funny, that's the idea.  It's not spamming if you have a finite amount of 
> votes.  People can spend them any way they choose.  If you spend your 
> votes on enhancement requests to app-misc/hello-kitty, that's your choice.

Given the large amount of hello kitty paraphanelia, this would require 
its own portage category, hello-kitty/  :)


--Kumba

-- 
"Such is oft the course of deeds that move the wheels of the world: 
small hands do them because they must, while the eyes of the great are 
elsewhere."  --Elrond

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Kurt Lieber]

[-- Attachment #1: Type: text/plain, Size: 1072 bytes --]

On Tue, Jul 27, 2004 at 12:54:49PM -0400 or thereabouts, Dylan Carlson wrote:
> I'm assuming there was some reason voting was turned off (since IIRC it's 
> on by default).  If so I'm just curious what that reason is.

No reason that I'm aware of why it was turned off.  That said, I'm
generally leery of enabling technology for technology's sake.  So far, I
haven't seen any indication of how this would be useful.  Folks have said
devs are free to use it or ignore it as they see fit.  That doesn't seem
(to me) like it's going to provide any sort of valuable, useful feedback to
the team or the community beyond what we already get with CC lists.

Plus, as someone else noted, our users are not exactly famous for being
able to use bugzilla correctly in its current form (to be fair, most of the
blame for this falls on bugzilla, which has a horrid UI imo).

Basically, if the argument is, "well...it's there.  Why *not* turn it on?"
then I don't see that as being particularly compelling.  It sounds like a
solution in search of a problem.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

Kurt Lieber wrote:

> Plus, as someone else noted, our users are not exactly famous for being
> able to use bugzilla correctly in its current form (to be fair, most of the
> blame for this falls on bugzilla, which has a horrid UI imo).
> 
> Basically, if the argument is, "well...it's there.  Why *not* turn it on?"
> then I don't see that as being particularly compelling.  It sounds like a
> solution in search of a problem.

Silly question, but do we have a laid out Gentoo document on proper usage for
bugzilla (part of the documentation project). I know documents only work for
those people who read them, but if we don't have a laid out document that talks
about common mistakes that users make, we can't teach them the proper way to
enter new bugs. We're well known for our awesome documentation, we should extend
this to how to use our bug tracking system. Thoughts?

P.S - Correct me if I'm wrong about there not being a document

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

Re: [gentoo-dev] Bug voting

[Lance Albertson]

[-- Attachment #1: Type: text/plain, Size: 1114 bytes --]

Aaron Walker wrote:

> Lance Albertson wrote:
> 
>> Aaron Walker wrote:
>>
>>
>>> Well, there is supposed to be a "Bug Writing Guidelines" which is linked
>>> to by the main Bugzilla page.  It is however, atm, unavailable (404).  I
>>> filed a bug on this a week or two ago
>>> (http://bugs.gentoo.org/show_bug.cgi?id=57282).
>>
>>
>>
>> Thanks for pointing that out. I commented on above bug, see what you
>> think!


[snip]

> Just CC'd myself on that bug.  I agree that more bugzilla documentation
> would be better.  It would reduce flawed bug reports to an extent.  Of
> course, there will always be the few that don't read...

I meant to post this for the list too, but with regard to lack of documentation
for users about our bugzilla, I created a bug [1] to track progress of it. If
any of you would like to contribute, please feel free!

[1] http://bugs.gentoo.org/show_bug.cgi?id=58651

-- 
Lance Albertson <ramereth@gentoo.org>
Gentoo Infrastructure

---
Public GPG key:  <http://www.ramereth.net/lance.asc>
Key fingerprint: 0423 92F3 544A 1282 5AB1  4D07 416F A15D 27F4 B742

ramereth/irc.freenode.net

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]

[gentoo-dev] Re: Bug voting

[Duncan]

Lance Albertson posted <4108F79B.20903@gentoo.org>, excerpted below,  on
Thu, 29 Jul 2004 08:11:55 -0500:

> I meant to post this for the list too, but with regard to lack of
> documentation for users about our bugzilla, I created a bug [1] to track
> progress of it. If any of you would like to contribute, please feel
> free!
> 
> [1] http://bugs.gentoo.org/show_bug.cgi?id=58651

I must say, and I'm sure it's been said before, so pardon my venting,
Gentoo's Bugzilla layout is about the most unintuitive thing I've EVER
seen.  It's a good thing there's the bug entry wizard in place, or things
would be MUCH worse.

It's not Bugzilla itself, either, as Gnome's interface, which I use for
PAN bugs as I follow the lists for it very faithfully, and the Mandrake
interface, for their bugzillas, were MUCH easier to work with.

Intuitively, while the product might be Gentoo Linux, the component should
be the ebuild one wishes to file the bug on, but it doesn't WORK
intuitively!

Anyway, Gentoo does great documentation, and with the bug entry wizard,
the bugzilla interface is at least semi-usable, but Gentoo bugzilla is
still by far the worst aspect of Gentoo Linux I've yet come across.  It
NEEDS some good documentation, as that's the ONLY way one can make heads
or tails of it.  Unfortunate, because that's NOT supposed to be the way
GUI  interfaces work.

(It didn't help that I tried to be a good boy and do a search before
filing my bug, thus, before I met the bug filing wizard, which would have
introduced me to the peculiarities of the Gentoo bugzilla setup.  I don't
swear that much, but I was swearing THAT day, and the fact that I was
searching for a bug I'd found and intended to report if it wasn't already,
as will of course be the usual way folks meet bugzilla, didn't make things
any better!  Sorry if I'm stepping on people's toes, but I'm not sure it
could have been made more difficult if that was the intent!, at least
without changing bugzilla significantly to do so.  The layout is AWFUL!!)

Unfortunately, for compatibility with both people and applications,
there's probably not a lot that can be done about the bugzilla layout
now.. except add more wizards and documentation to it.    I'd seen
references (in the AMD64 technotes) about searching for the application
name in the summary.  At the time, I thought to myself that was stupid,
because it should be in one of the dropdown box selections to prevent
typos and the like.  THEN I went to USE the thing, to actually SEARCH for
a bug, before filing my own, and the reason for having to search the
summary for the app title became ALL to apparent!

Did I say it's terrible, yet?  What about that it's the worst part of
Gentoo that I've come across?  I did.  Oh..  It's still true!

As I said, tho, I'm sure it's all been said b4.

.. But that doesn't make it any less true!!

I wonder what score bug voting would place on a bugzilla usability bug.
I'm sure by now you know where many of MY votes would be likely to go!

Documentation DOES help, tho, even if with this layout it needs to be
step-by-step.  I followed the amd64 technote instructions and just had my
first two keyword bugs resolved, altho I still have a portage bug (56785),
complete with simple (sed command change, simple enough for even /me/ to
figure out, even if I can't figure out Gentoo bugzilla without a wizard)
resolution in a followup comment, that has received no action besides
assignment to the portage folks by bugwranglers, and is still marked as
new, more than two weeks later.  (That's frustrating, but not like trying
to use bugzilla in the first place! <g>  Yes, it's THAT bad, unfortunately.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Dylan Carlson]

On Thursday 29 July 2004 11:14 am, Duncan wrote:

> Anyway, Gentoo does great documentation, and with the bug entry wizard,
> the bugzilla interface is at least semi-usable, but Gentoo bugzilla is
> still by far the worst aspect of Gentoo Linux I've yet come across.  It
> NEEDS some good documentation, as that's the ONLY way one can make heads
> or tails of it.  Unfortunate, because that's NOT supposed to be the way
> GUI  interfaces work.

Well, the query screen is powerful, and as a consequence, it's ugly.   
Everything is there for a reason.  If you're a developer, the query tool 
is what it needs to be.  The same is also true for the full bug screen.

There are some cosmetic hacks that can be done (and have been done by other 
projects using Bugzilla).   The bug screens in our verson of Bugzilla can 
be simplified; both Gnome and KDE have a simplified interface for users, 
and the full interface for developers.

If there's not already a bug in our system asking for this, please open 
one.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 721 bytes --]

On Thu, 29 Jul 2004 13:50:58 -0400 Dylan Carlson <absinthe@gentoo.org>
wrote:
| On Thursday 29 July 2004 11:14 am, Duncan wrote:
| > Anyway, Gentoo does great documentation, and with the bug entry
| > wizard, the bugzilla interface is at least semi-usable, but Gentoo
| > bugzilla is still by far the worst aspect of Gentoo Linux I've yet
| > come across.
| 
| Well, the query screen is powerful, and as a consequence, it's ugly.  

It is? Actually, I'd say that the query is utterly crippled, since
there's no way to search for all bugs on a particular package.

-- 
Ciaran McCreesh : Gentoo Developer (Sparc, MIPS, Vim, Fluxbox)
Mail            : ciaranm at gentoo.org
Web             : http://dev.gentoo.org/~ciaranm


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Re: Bug voting

[Dylan Carlson]

On Thursday 29 July 2004 10:41 pm, Ciaran McCreesh wrote:
> It is? Actually, I'd say that the query is utterly crippled, since
> there's no way to search for all bugs on a particular package.

Query isn't crippled.  If anything: Bugzilla, as shipped, gives us a 
suboptimal set of fields for our particular use case.  If the package name 
is in the Summary line like it should be, then it can be searched... but 
since this relies on user input instead of a selection list, it's not 
reliable.

It would be nice if there were a way to class & subclass maybe 5-6 levels 
deep, without having to assign terms like "product" and "component" -- 
those levels could be named whatever is appropriate.  Alas.

-- 
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Re: Bug voting

[Duncan]

Ciaran McCreesh posted <20040730034129.69c54140@snowdrop.home>, excerpted
below,  on Fri, 30 Jul 2004 03:41:29 +0100:

> On Thu, 29 Jul 2004 13:50:58 -0400 Dylan Carlson <absinthe@gentoo.org>
> wrote:
> | On Thursday 29 July 2004 11:14 am, Duncan wrote:
> | > Anyway, Gentoo does great documentation, and with the bug entry
> | > wizard, the bugzilla interface is at least semi-usable, but Gentoo
> | > bugzilla is still by far the worst aspect of Gentoo Linux I've yet
> | > come across.
> | 
> | Well, the query screen is powerful, and as a consequence, it's ugly.  
> 
> It is? Actually, I'd say that the query is utterly crippled, since
> there's no way to search for all bugs on a particular package.

Exactly my point.

As I said earlier, component should be the particular package, complete
with drop-down list preventing user error on such an important field.  The
summary should be a summary of the problem and not need the package name
or version.

What to do with stuff that doesn't fit that mold, then, in the broader
categories we presently put in product and component?

To some extent, they could be made other choices even if the meta-level
isn't quite the same.

The other way to handle it would be to create multiple bugzillas.  Instead
of simply bugs.gentoo.org, there'd be linux.bugs.gentoo.org to handle the
mainline/traditional software product bugs, and other subdomains as
appropriate for the current top-level "products", therefore
admin.bugs.gentoo.org, recruitment.bugs.gentoo.org, etc.

One advantage of that would be that the bugzilla front-end and database
could be used, without shoehorning everything entered there into being
described as a "bug". Thus, altho I'm not sure exactly what is
tracked by the other categories, rather than admin.bugs.gentoo.org, it
could be called something like admin-tracker.gentoo.org, or
admin-db.gentoo.org, or admin-feedback.gentoo.org, or, perhaps
feedback.admin.gentoo.org, or tracker.admin.gentoo.org.   

Of course, bugzilla admins and even experienced developers and users would
easily see it as bugzilla, but with the labels massaged a bit, it wouldn't
/look/ like a bug database, to someone not accustomed to working with one,
and sometimes, what something is called makes a big difference.

As I said, however, I'm not sure it'd be practical to attempt to switch
horses in mid-stream, as they say.  Further, I'll come right out and say
I'm rather to much of a newbie to pretend that what I might have to say
should have any status at all.  If it makes sense and can be used, great.
Otherwise, Gentoo's still the best (meta-)distribution option I've come
across, and I'll continue to use it, improving my skills and familiarity
with my distrib of choice, and aiming toward active participation at
whatever level I happen to be at, perhaps even as a developer if that time
should come.

-- 
Duncan - List replies preferred.   No HTML msgs.
"They that can give up essential liberty to obtain a little
temporary safety, deserve neither liberty nor safety." --
Benjamin Franklin



--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1792 bytes --]

On Tuesday 27 July 2004 21:49, Kurt Lieber wrote:
> On Tue, Jul 27, 2004 at 12:54:49PM -0400 or thereabouts, Dylan Carlson 
wrote:
> > I'm assuming there was some reason voting was turned off (since IIRC it's
> > on by default).  If so I'm just curious what that reason is.
>
> No reason that I'm aware of why it was turned off.  That said, I'm
> generally leery of enabling technology for technology's sake.  So far, I
> haven't seen any indication of how this would be useful.  Folks have said
> devs are free to use it or ignore it as they see fit.  That doesn't seem
> (to me) like it's going to provide any sort of valuable, useful feedback to
> the team or the community beyond what we already get with CC lists.
>
> Plus, as someone else noted, our users are not exactly famous for being
> able to use bugzilla correctly in its current form (to be fair, most of the
> blame for this falls on bugzilla, which has a horrid UI imo).
>
> Basically, if the argument is, "well...it's there.  Why *not* turn it on?"
> then I don't see that as being particularly compelling.  It sounds like a
> solution in search of a problem.

Many of my packages (like openoffice) are plagued by subtle one of bugs. I 
think that voting in this can be an indication on whether other people also 
have this bug, or whether this user is the only one experiencing problems. 
These bugs are particularly hard to fix, and I really like to know whether 
other users have the same problems. (In many cases cc is a good indication). 
Similarly for feature requests on my packages, I'd like to know if more than 
one person is really waiting for the perl bindings on subversion.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting++

[Frank van de Pol]

[-- Attachment #1: Type: text/plain, Size: 1369 bytes --]


vote++;

it gives a nice understanding on the demand for certain enhancement/ebuild
requests. It's also a nice, low-overhead way for people to say 'heck, I ran
in that bug too and would indeed welcome to see it fixed'.

Of course there might always be people that abuse such a system to get a
stronger voice, but the developer's common sense will for sure deal with
that. After all, the voting is not (and should not be) an official
priority-setting tool. I'd be happy to use it as hint though.

Perhaps it might be usefull to include the 'top 10', or top most of last
week/month entries in the GWN, like the bug squashing/creeping statistics.

Frank.


On Tue, Jul 27, 2004 at 12:54:49PM -0400, Dylan Carlson wrote:
> Greetings,
>
> Stuart touched on this a month ago (see: Tools to help QA, 6/25/04) and I
> didn't see any arguments for, or against it.
>
> My thoughts (I'm in favor of bug voting):
>
> 1.  Without bug voting, there's no way to determine what bugs are most
> important to the public (or at least to the people using Bugzilla, which
> is really *our* public, in a working sense).
>

-- 
+---- --- -- -  -   -    -
| Frank van de Pol                  -o)    A-L-S-A
| FvdPol@coil.demon.nl              /\\  Sounds good!
| http://www.alsa-project.org      _\_v
| Linux - Why use Windows if we have doors available?

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting++

[Dylan Carlson]

On Tuesday 27 July 2004 4:09 pm, Frank van de Pol wrote:
> Perhaps it might be usefull to include the 'top 10', or top most of last
> week/month entries in the GWN, like the bug squashing/creeping
> statistics.

That would be a good use of those numbers, and would also encourage GWN 
readers to participate in the process.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Joel Konkle-Parker]

I'll second this. I'd like to see voting for bugs as well. I've voted 
for certain Mozilla bugs I would like fixed, and I've appreciated the 
feature.

It wouldn't be a forced thing, just a little "hey, there's this bug over 
here that a lot of people are hankering for." It would let voices be 
heard without cluttering up the comments with "me too!"

-- 
Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Mike Gardiner]

Hi Dylan, Ciaran, all

Apologies for entering this late, but from what I gather from the
discussion, there seems to be the notion of voting for "real" bugs
versus "enhancement" bugs, with some believing votes for the second
would outweigh the first, and skew the perception of what really needs
to be done.

So I guess my question follows, is it possible/feasible to only allow
voting on bugs marked as "enhancements"? (as in the bugzilla keyword).

Mike Gardiner
(Obz)

On Wed, 2004-07-28 at 00:54, Dylan Carlson wrote:
> Greetings,
> 
> Stuart touched on this a month ago (see: Tools to help QA, 6/25/04) and I 
> didn't see any arguments for, or against it.  
> 
> My thoughts (I'm in favor of bug voting):
> 
> 1.  Without bug voting, there's no way to determine what bugs are most 
> important to the public (or at least to the people using Bugzilla, which 
> is really *our* public, in a working sense).
> 
> 2.  Turning on voting is a trivial change to our system to give people a 
> way to promote bugs, and that in turn (ideally) shapes our priorities on 
> which ones get addressed first.
> 
> I'm assuming there was some reason voting was turned off (since IIRC it's 
> on by default).  If so I'm just curious what that reason is.
> 
> Cheers,
> Dylan Carlson [absinthe@gentoo.org]
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F
> 
> --
> gentoo-dev@gentoo.org mailing list
> 


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Bug voting

[Robin H. Johnson]

[-- Attachment #1: Type: text/plain, Size: 1357 bytes --]

On Wed, Jul 28, 2004 at 10:53:07AM +0800, Mike Gardiner wrote:
> Hi Dylan, Ciaran, all
> 
> Apologies for entering this late, but from what I gather from the
> discussion, there seems to be the notion of voting for "real" bugs
> versus "enhancement" bugs, with some believing votes for the second
> would outweigh the first, and skew the perception of what really needs
> to be done.
> 
> So I guess my question follows, is it possible/feasible to only allow
> voting on bugs marked as "enhancements"? (as in the bugzilla keyword).
I don't think this would do any good.  Users tend to mark bugs as
enhancement on a whim, from what I've seen.  I'd say we should enable
voting for all bugs, and users should be informed that all enhancements
are considered separately from problems (your "real" bugs), and it
should be possible to show the highest voted problems as such. 

I'm also strongly in favour of a limited number of votes per user. Along
the lines of 2 votes/week for non-developers, and 4 votes/week for
developers. Unused votes should NOT get carried over between weeks, to
prevent vote hoarding.

-- 
Robin Hugh Johnson
E-Mail     : robbat2@orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [gentoo-dev] Bug voting

[Tom Wesley]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

On Tue, 2004-07-27 at 20:11 -0700, Robin H. Johnson wrote:
> On Wed, Jul 28, 2004 at 10:53:07AM +0800, Mike Gardiner wrote:
> > Hi Dylan, Ciaran, all
> > 
> > Apologies for entering this late, but from what I gather from the
> > discussion, there seems to be the notion of voting for "real" bugs
> > versus "enhancement" bugs, with some believing votes for the second
> > would outweigh the first, and skew the perception of what really needs
> > to be done.
> > 
> > So I guess my question follows, is it possible/feasible to only allow
> > voting on bugs marked as "enhancements"? (as in the bugzilla keyword).
> I don't think this would do any good.  Users tend to mark bugs as
> enhancement on a whim, from what I've seen.  I'd say we should enable
> voting for all bugs, and users should be informed that all enhancements
> are considered separately from problems (your "real" bugs), and it
> should be possible to show the highest voted problems as such. 
> 
> I'm also strongly in favour of a limited number of votes per user. Along
> the lines of 2 votes/week for non-developers, and 4 votes/week for
> developers. Unused votes should NOT get carried over between weeks, to
> prevent vote hoarding.
> 

In case you're not aware how the KDE project maintain this, each user
(not sure about special cases for developers, and not sure I agree with
there being one.) has 100 voting points that they can allocated to bugs,
withs a maximum of 20 on any one bug.

-- 
Tom Wesley <tom@tomaw.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] Bug voting

[Dylan Carlson]

On Tuesday 27 July 2004 11:11 pm, Robin H. Johnson wrote:
> I'm also strongly in favour of a limited number of votes per user. Along
> the lines of 2 votes/week for non-developers, and 4 votes/week for
> developers. Unused votes should NOT get carried over between weeks, to
> prevent vote hoarding.

As Tom pointed out, you get a fixed number of votes to allocate at any one 
time (they don't accumulate).   How many you can place on each bug depends 
on the maximum that has been set for the Product the bug belongs to.  You 
can, also, by this same way prevent people on voting for bugs in a 
particular Product (by setting maximum votes for that product to 0.)

So let's throw out an example scenario.  I don't necessarily like how KDE 
does it, since one person can add more weight by slapping 20 votes on. I 
personally prefer a 1 vote per person model, but it could be done either 
way with success.   This is probably how I would set it up:

Users are given 20 votes.  

We let them allocate one vote per bug, for the things that are worthwhile 
to vote on.

We set up the per-product voting settings like this:

Admin: 0  (voting not desireable here)
Developer Relations: 0 
Docs-developer: 1 (one vote per bug)
Docs-user: 1
Gentoo GLSA: 1 
Gentoo Hosted Projects: 1
Gentoo Linux: 1
Gentoo Linux Bugzilla: 0
Gentoo LiveCD: 1
GRP: 1
Mirrors: 1
Portage Development: 1
Recruitment: 0
Web-www.gentoo.org: 1


Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Bug voting

[Joel Konkle-Parker]

Dylan Carlson wrote:
> So let's throw out an example scenario.  I don't necessarily like how KDE 
> does it, since one person can add more weight by slapping 20 votes on. I 
> personally prefer a 1 vote per person model, but it could be done either 
> way with success.   This is probably how I would set it up:

Multiple votes per bug allows people to say "this bug is really 
important to me." They have a limited number available; it's their 
choice whether they want to spend them all on a single bug, or spread 
them out to many.

The Mozilla project uses voting as well, but they allocate 10 votes 
each, to spend however you please.


-- 
Joel Konkle-Parker
Webmaster  [Ballsome.com]

E-mail     [jjk3@msstate.edu]


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Bug voting

[Dylan Carlson]

On Wednesday 28 July 2004 7:58 pm, Joel Konkle-Parker wrote:
> Multiple votes per bug allows people to say "this bug is really
> important to me." They have a limited number available; it's their
> choice whether they want to spend them all on a single bug, or spread
> them out to many.
>
> The Mozilla project uses voting as well, but they allocate 10 votes
> each, to spend however you please.

I thought Mozilla does it 1-per-bug, but I guess I'm mistaken.  KDE works 
well with 20-per-bug.

I'm cool with it either way.  Any reasonable value will probably work.   I 
gave that example to show how I would set it up-- starting at one vote per 
bug and changing it later if users request it.   I prefer incremental 
approaches (starting small and working up as the needs dictate).  

sj7trunks is responsible for maintaining bugzilla...  so I believe he'd 
also be setting that value, if voting gets implemented; and I hope it 
does.  Voting is a low cost, low impact tweak to give the users a way to 
help steer the things we're working on.

Cheers,
Dylan Carlson [absinthe@gentoo.org]
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F

--
gentoo-dev@gentoo.org mailing list