Closed Bug 68156 Opened 20 years ago Closed 20 years ago
need a keyword for low risk - high reward bugs (not just for mailnews)
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
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.
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?
removing confusing, misleading and just plain wrong dependency and keyword.
"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.
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.
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
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 firstname.lastname@example.org or targetted at Future plus any others you think are trivial.
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 ;-)
Whiteboard: LoRiskHiReward - good for newbies and increasing involvment.
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."
Feh. Normally the way to fix complexity problems is to reduce the complexity, not increase it.
Whiteboard: LoRiskHiReward - good for newbies and increasing involvment.
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.
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) ;)
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.
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.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
I protest (i.e., strongly disagree)! This should be discussed on the newsgroup before making any hasty decisions. We need a second oppinion.
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?
verified not useful.
Status: RESOLVED → VERIFIED
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.
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.