68156 - need a keyword for low risk - high reward bugs (not just for mailnews)

Status: VERIFIED WONTFIX

(bugzilla.mozilla.org :: Administration, task)

Description

[Peter Lairo]

need a keyword for low risk - high reward bugs (not just for mailnews, i.e. mail6)

--------
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010205

Comment 1

[Peter Lairo]

suggest: LoHigh

BTW: "polish" is only for UI, we need one for "general" low risk high reward
bugs. Best would be to redefine "polish" to be for general bugs, not just UI.

Comment 2

[Asa Dotzler [:asa]]

Peter Lairo, can you please explain to me why you added the keyword 'polish' to
this bug?  Can you also give me a lit of bugs to which you would add this "low
risk high reward" keyword if I created it?  How do you propose this keyword is
used and for what benefit?

Comment 3

[Asa Dotzler [:asa]]

removing confusing, misleading and just plain wrong dependency and keyword.

Comment 4

[Peter Lairo]

"polish" because bugzilla is already 95% perfect and this little KW would make
it just a bit better without too much effort ;)

This new KW would be most beneficial in getting the attention of *novice
programmers* and experienced programmers who need a short break/diversion/easy
success to identify simple bugs that are often overlooked because the feature is
already "good enough" (but not really) as it is, or is not on the "we must do
the other critical bugs first" list..

Examples could be: 
bug 87480
bug 84691
bug 84281
bug 83096
bug 80280
bug 80254
bug 80220
bug 79006
bug 75371
bug 74716
bug 73562
bug 72400
bug 69349
bug 66522
bug 65958
bug 65596
bug 65591
bug 64765
bug 64741
etc...
Please NORE: I'm no programmer, so some might be more effort than I think.

Comment 5

[Asa Dotzler [:asa]]

what's wrong with using the severity field? If you're talking about the bugs
that are not on the "critical" list then look for the severity: trivial or minor
bugs and for UI issues we already have the polish keword. 

Comment 6

[Peter Lairo]

The "severity" gives no idication of the effort involved (a trivial bug might
actually be a bear to fix). This new keywork would be immensely useful to
beginner programmers of persons new to mozilla to identify bugs that are likely
easy to fix. Imagine all those eager to help could be told: "Try to fix a *hilo*
bug, they are a good place to learn the ropes."

This would be an excellent *point of entry* for new recruits. And it would help
fix those many "little" bugs sooner without burdening the more experienced
programmers.
Suggested keywords: LoRiskHiReward, LowHigh, HighReward, LoRHiR

Comment 7

[Asa Dotzler [:asa]]

Peter Lairo, and who would add this keyword.  I'm not sure I like the idea of
handing our developers a "add this keyword and then ignore the bug because its
easy to fix and some newbie contributor will fix it" option.  We already have
enough of that happening (especially with UI) and I'd rather not aggrivate the
problem by formalizing.  If you (and any others out there listening) would like
to build a list of bugs which you think are easy enough that new contributors
could get started you can probably get more than enough bugs (you've got a nice
little handful above in this report) to keep all the new contributors bus for
some time.  I recommend queries for minor, trivial, enhancement severities or
polish keyword  and maybe a quick look throught the bugs assigned to
[e-mail] or targetted at Future plus any others you think are trivial.  

Comment 8

[Peter Lairo]

Developers will not be able to "brush off" a *LoRiskHiReward* where it matters
because those bug will (hopefully) have other keywords, target milestones,
severity indicators. Obviously, noone should r= or sr= an important bug that is
not fixed yet.

However, if the main problem is fixed (as described in the bug report), but
there are *additional* fixes that are not *directly related* to the *critical*
bug, then it would be great to allow senior developers to move on to other
critical bugs and allow novice programmers to fix the other issues. What better
way to efficiently use our resources AND provide a port-of-entry for newbies
wanting to help. 

This could actually be a *MAJOR selling point* on getting people involved. I
would even suggest that moz.org *ADVERTIZE* to new-persons on the homepage to
get their feet wet with *LoRiskHiReward* bugs ;-)

Comment 9

[Peter Lairo]

One of the MAIN hindrances for new programmers to get involved is the enormous
complexity of this whole system. Give them a place to start ("LoRiskHiReward"
bugs) could give this project a major boost.

Your suggestion to query trivial or minor bugs will not work because: (A)
newbies will not know how to use the query system that well. (B) finding these
bugs is by no means sure to find ones that are also easy to fix. (C) not focused
on the newbie - why should he FIRST have an intimate knowledge of our system and
THEN get his feet wet. It's ass-backwards. (D) Nothing beats a one-liner: "go
look at some *LoRiskHiReward* bugs."

Comment 10

[Matthew T (active 1999-2002)]

Feh. Normally the way to fix complexity problems is to reduce the complexity, 
not increase it.

Comment 11

[Asa Dotzler [:asa]]

PLairo, 

>Nothing beats a one-liner: "go look at some *LoRiskHiReward* bugs."

And how do they go look at these bugs without a knowledge of the query page and
the usage of keyword searches? 

Oh, you'd provide a link to this query? That way they don't have to use
Bugzilla's query tool at all? 

So what's wrong with hiding any confusing query behind a simple link.  If the
goal is pointing potential contributors at easy to fix bugs why don't you just
point these newbie contributors at this bug with your list.  If those bugs get
fixed by a new contributor who wasn't capable of querying bugzilla then we can
talk about expanding the mechanism to make it easier for you to add bugs to your
list. 

Comment 12

[Peter Lairo]

Unfortunately, you don't seem to understand the marketing and PR potential (not
to mention "snowball effect") of having *LoRiskHiReward* bugs.

We have several dozen keywords that mostly benefit Netscape programmers. We have
very few that reach out to the public and say: "here, this is where you can help".

> why don't you just point these newbie contributors at this bug with your list.

Well, because "newbie contributors" don't contact me (and there is currently NO
way to make this list complete without an appropriate keyword) ;)

Comment 13

[Asa Dotzler [:asa]]

You're right. I don't understand "the marketing and PR potential (not
to mention "snowball effect") of having *LoRiskHiReward* bugs."  I don't
understand how having any bugs is a good thing.  We have lots of them, some are
easy to fix, some are hard to fix. When people come to the project looking for
bugs to fix they are either going to learn to query Bugzilla for bugs or they
are not going to learn to query Bugzilla.  Your solution, a keyword, relies on
them learning to query Bugzilla for keyword: lowriskhighreward.  My system
relies on them querying for severity minor, trivial and enhancement. I don't see
a major leap in complexity there. 

PLairo, and why on earth does the list have to be complete? I don't see invading
armies of hackers fixing the 20 or so you've already compiled.  

Comment 14

[Peter Lairo]

1. All right let's be pedantic: yes, having "bugs" is a bad thing. Obviously I
meant having a "keyword" for certain bugs is desirable. This kind of deliberate
misunderstanding only serves to hinder progress - please refrain from it in the
future (unless it's genuinely funny ;) ).

2. The point is not to avoind having to learn bugzilla (it's currently
unavoidable); the point is to give people a keyword that will give them
something useful they don't currently have: *a way to find bugs that are likely
easy to fix*.

3. minor, trivial and enhancement ONLY indicate the "importance" of a bug. They
give NO indication of the "complexity" of a bug. 

A bug could very well have a "trivial" severity and be quite "difficult" to fix.
Likewise, a bug could be a "blocker" but very "easy" to fix. This would be an
extreme and obvious case of *LoRiskHiReward*.

4. The reason nobody has come to fix the 20 bugs I listed above is because
nobody knows to look for them. Another clear indication that we desperately need
a way for beginner or casual/occasional contributers to help move this project
along.

Comment 15

[Asa Dotzler [:asa]]

wontfix.

Comment 16

[Peter Lairo]

I protest (i.e., strongly disagree)!

This should be discussed on the newsgroup before making any hasty decisions. We
need a second oppinion.

Comment 17

[Peter Lairo]

OK, I just created a discussion thread in "n.p.m.general" dated 7.Aug.2001. It
has the subject line: 

"DISCUSSION: Need *LoRiskHiReward* Keyword for beginner or casual/occasional
contributers"

Let's see what others have to say about this - OK?

Comment 18

[Blake Ross]

verified not useful.

Comment 19

[Peter Lairo]

You could have at *least* waited a week or two to see what the newsgroup
discussion yielded :(

I am now convinced that the *public needs more of a say in this project* - I
have seen too many designer-centric decisions here.