How to make an upgrade path comfortable How to make an upgrade path comfortable

step one:

make sure the profile migrator doesn't suck (not tested)

[Confession: this is a p133 laptop running w98, it was using a smoketest build]

step two:

Have the first common dialog the user sees (which will appear if the user tries to open, save or attach a file) start at a directory with no visible critical files and ideally a file which demos the stuff which your app is designed to handle.

Open File
 Look in: [  Program                                |v]        
 Netscape             NetHelp
 import               FullSoft
 defaults             Plugins
 dynfonts             nareadme.htm
 spellchk
 java
 nls
Click to read 900 more words
    

How to make an upgrade path bad. How to make an upgrade path bad.

step one:

Make the migrator look really ugly, including the wrong widgets and no content.
Then make it disappear and have nothing appear on the screen for a while.

[Confession: this is a p133 laptop running w98, it was using a smoketest build]

step two:

Have the first common dialog the user sees (which will appear if the user tries to open, save or attach a file) start at a directory with lots of critical but meaningless support files in the middle of nowhere.

Open File
 Look in: [  1.5b_20030704                         |v]        
 ipc                   gkgfx.dll             nspr4.dll              ssl3.dll
 components            js3250.dll            nss3.dll               xpcom.dll
 uninstall             jsj3250.dll           nssckbi.dll            xpcom_co|
 Setup GRE             mozctl.dll            plc4.dll              xpicleanu|
  install_status.log    mozctlx.dll           plds4.dll              xpistub.dll
  .autoreg             mozipcd.exe           smime3.dll
  softokn3.chk          mozz.dll              softokn3.
Click to read 802 more words
    

the latest feature request: Being able to watch by product the latest feature request: Being able to watch by product

Executive Summary: not worth implementing

Any particular reason?

Reasons:

It shouldn't be easy for people to kill themselves or annoy the world.
Watching a product is at least one if not both.

Why people think they want it:

They have project teamleads who want to see all bugmail related to a product, but not all the mail of the people involved with said product.

What those people should do instead:

Manually watch all of the qa's.

Why can I make this suggestion?

Speaking as the person who probably gets the most bugmail of anyone at bmo (5.7%, 5773 in one week, reported by justdave on 9/8/2003).

You'll find two problems:

1. The person will be overwhelmed
2. People will get annoyed at seeing this person getting bugmail no matter what they do
   1. If there's a second product in the installation then someone might decide to use it to do their work
      Based on the fact that the request is for per product watching this implies there's more than one product (if there isn't then you can just modify the template to cc this team lead to all mail...)

   2. If there isn't, someone might decide not to do any updates in bugzilla until the bug is finished

It's true that in corporate environments you can theoretically discourage both practices, but you'll find that you can't; someone can easily end up doing all work outside of bugzilla and only posting when they're done.

Is it a cultural thing?

In some ways yes. But really it's a human thing.

Suppose you're a pretty small team (~15 people)

How many qa contacts do you have?
and how many of your qa contacts watch touch multiple products?

Perhaps:

four - one for each main product , + one lead

So why doesn't the lead watch the qa contacts?

It is simple, possible today, and it should fit your needs.

But you hadn't thought of that option?

The problem is that i have :)

What should you do when someone asks for a way to watch all bugs in a product? What should you do when someone asks for a way to watch all bugs in a product?

tell them to watch all QA's for the product.

If they don't want to spend the time to do this, then they probably don't have the time to read the mail they think they want. By making them think about the number of components and the amount involved you can encourage them to consider what they're getting into. If they later decide that they've gotten too much mail they will have a way to reduce it by only watching some of the QA's.

If a project lead watching a bunch of QA's is overwhelmed and notices that there's no way to reduce the mail because most of it comes from a single QA, then the lead will hopefully reach the conclusion that the QA's coverage area is too large and some of the work should be given to someone else.