272837 - CANOPENBUG permissions will be required

Status: RESOLVED WONTFIX

(bugzilla.mozilla.org :: General, defect)

Description

[WADA:World Anti-bad-Duping Agency]

CANOPENBUG permission will be required, I believe, since Firefox 1.0 has been
released and Thunderbird 1.0 will be released soon.
I'm afraid of flood of bugs say only "Help me!" or "Funny on my Thunderbird!".

Comment 1

[Anne (:annevk)]

Don't you think bmo is a little bit too technical for that? There has been no
such problem in the past and people are always pointed to forums and go there.
They don't seem to go here unless they think they have found a bug or want to do
a feature request.

Comment 2

[WADA:World Anti-bad-Duping Agency]

See Bug 206247 for example.
Reporter has aparantly well technical knowledge much more than people who asks
at "Thunderbird Support forum" and more than who writes at "Thunderbird Bugs forum".
This looks like good bug initially but this is almost same as "Funny on my
mailer!", then no responce for more than one year.
My experience at b.m.o says that bugs of this type are not so many but not a few.
And due to flood of these bugs, many software vender do not open bug accepting
bureau to usual consumers as MS doesn't.

Since youngsters are much familiar with computer than elder people, I can not
think difficulty of b.m.o is a barrier for them.
And they usually say "software behaviour which is different from their
expectation" is "bug", though many elder people say so too.
If many of them come here, we must teach them before problem analysis. 
It'll be very tough work for me, although teaching to youngster is very
important and joy for me.

Can difficulty of b.m.o continue to be a effective barrier?

Comment 3

[Dave Miller [:justdave]]

b.m.o is going to get easier to use as we go.  People who don't follow up when
asked for additional information are going to get their bugs killed, too. 
There's a plan that should be going into action fairly soon to start killing off
any UNCONFIRMED bugs that aren't confirmed within 2 months, since statistically
if they aren't acted on within 2 months, they never will be.

Comment 4

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #3)
> People who don't follow up when asked for additional information are going to
get their bugs killed, too.

It's very good news. I hope this will be implemented as soon as possible.
  
> There's a plan that should be going into action fairly soon to start killing off
> any UNCONFIRMED bugs that aren't confirmed within 2 months, since statistically
> if they aren't acted on within 2 months, they never will be.

I believe this is statistically true.
But there is at least one exception, one of my bug.

I opened Bug 242744 on 2004-05-05 but no one comfirmed until 2004-11-27.
(I did not have CANCONFIRM permission this time, I have now though.)
This bug has been fixed on 2004-11-28, next day of comfirming!, because
comfirming person assigned the bug to appropriate person, and because data was
sufficient to analyze problem, and because bug was valid bug.
What should we do in this case?
Should I open bug every two months?

Comment 5

[WADA:World Anti-bad-Duping Agency]

I believe automatic cancel for "UNCOMFIRMED for 2 months" is too unkind for many
bug reporters.
If introduced, I think more long term than 2 months is appropriate for automatic
cancel due to long UNCONFIRMED.
Since automatic cancel for "No response for long time" will be implemented, we
will be able to fully utilized this for canceling.
Anne van Kesteren and Dave Miller, what do you think.

By the way, new permission of BE-QUIET-PLEASE or BEHAVE-YORSELF will be  required...
See Bug 239943 Comment #1.
He have changed the bug "Confirmed" and "Critial", further, requested "Blocking!
Avaiary".
He has started to enjoy games in some bugs lately...
Bugzilla should implement "kindergarten teacher" feature :-)
Could someone please teach me how to bring up and make him a good developer.

Comment 6

[WADA:World Anti-bad-Duping Agency]

I saw a bug of complaints on reporting "Bug" at bugzilla.mozilla.org.
> Bug 284807 : Firefox bug reporting is needlessly complicated, discouraging
people from posting/searching bugs
I think this is an incident that misunderstanding by many users will occur in
near future.
Please note that difference from user's expectation is usually "Bug" of software
for many many users.
And this will be much serious when Thunderbird, because user have to do many
many setups correctly before successuful mail use (See many many bugs whose
summary contain SMTP.)

To improve this situation, isolation of "Bug" is required, I think.
   (A) "Bug" for trouble shooting
   (B) "Bug" for development/bug fixing (current "Bug" of bugzilla.mozilla.org)

I think main cause of flood of "Bug" is ;
  Many bugs which should be closed as INVALID/DUP/WORKSFORME
  are kept as NEW for long long period, then it's impossible to ditinguish
  valid bugs from them.
  ("Almost all CANCONFIRM user's bug is NEW" and)
  ("not changing to ASSINGED" are also causes.  )
So I think introducing of new status can be a short term solution.
  New Status of "VALID_PROBLEM" or "ACCEPTED"
  between "NEW"(or "REOPEND") and "ASSIGNED".
But more improvement will be required as long term solution.

For non-Enhancement "Bug", following is my idea for improvement, just an idea
though.
Different approach is required for Enhancement bug, because discussion and
decision is usually required when "Enhancement".

    [Rough sketch of non-Enhancement "Bug"]
    -----------------------------------------------------------------
    (1-1) Any user can open bug of (A).
    (1-2) Problem analysis in (A) and CONFIRMing/DUPing/INVALIDing
          Some status for trouble shooting may be required.
            ASKING_FOR_CONFIRM, WAITING_FOR_RE_CREATION,
            WAITING_FOR_DATA, IN_DATA_ANALYSIS, ...
    -----------------------------------------------------------------
    (1-3) Change (A) to "VALID_PROBLEM" when found to be valid
          (action like returning OK to review)
    -----------------------------------------------------------------
    (1-4) When found to be valid bug(code problem or design problem),
          developer opens bug of (B) for (A) of "VALID_PROBLEM".
          => (A) becomes "WAIT_FOR_FIX"
             (B) starts from "NEW"
    (1-5) When developer starts to implement fix, change (B) to ASSIGNED.
          After this, activity on (B) is completely same as current.
    (1-6) When (B) is FIXED, status of (A) is changed to "FIX_AVAILABLE"
          or "RESOLVED_BY_FIX".
    -----------------------------------------------------------------
    Note: Relation between (A) & (B) should be maintained by Bugzilla.
          Relation between bugs should be enhanced.
           - DUPed/DUPing chain like Depends-on/Blocks chain
           - FIXED_BY/FIXING chain like Depends-on/Blocks chain
           - METAbuged/METAbuging chain instead of using Depends-on/Blocks
           - Simle POINTed/POINTing chain for "See also other bugs"

Comment 7

[Gervase Markham [:gerv]]

We're not going to add this permission.

Gerv