Improving Mail Clients Improving Mail Clients

What could mozmail/thundebird learn from M2?

1. Detect mailing lists and automatically create virtual folders for them.
2. Provide virtual folders for messages with attachments.
3. Provide virtual folders for Unread and various other things.
4. For a detailed list see <Short analysis of M2> <>

What can mozmail/M2 learn from my inbox?

1. If you offer an 'unread' view, don't try to load all the message headers into memory. Don't even download them. Just ask the IMAP server for the list of 'unread' messages.

How could thunderbird improve on this mess?

Provide a standalone mail compose instance. One of my biggest problems is that when I'm composing a message (a task i rarely undertake), the mail client will freeze because it's dealing w/ my inbox. If the mail compose window ran as its own process and talked to the IMAP/SMTP servers instead of to the local mozmail engine, i'd be much happier. It'd mean i could compose mail w/o having to be able to open my inbox.

Autoshaping based on user tendencies Autoshaping based on user tendencies

Alternatives to Supporting Comment Redaction Alternatives to Supporting Comment Redaction

What are the main real reasons people need to redact their comments?

1. People often don't realize how Bugzilla will present their comment.
2. People often mess up bug numbers
3. People often make typos

What's the simple solution to all of these problems?

Provide a preview button (or simply require everyone use preview)

Who else uses this system?

Slashdot oddly enough has it.

How could we make preview more effective?

Preview should in-line certain details from references. Show the referenced bug's:

• description
• current status
• current assignee + QA
• current product/component

For comment references it should reference:

• commenter's name
• commenter's email
• comment creation date

For attachments, it should reference:

• description
• attachment author
• all flags
• bug number

How should foreign bugs that are not already referenced?

Those too should be expanded. it might make sense for all of those details to appear in a sidebar so that a previewer doesn't get confused and think that the content will actually appear in-line. hovering over the reference should probably highlight the relevant item.

Allowing users to edit their comments Allowing users to edit their comments

Advertising intelligently to Developers Advertising intelligently to Developers

What works?

• Innovation for short periods. - This is commonly known as new fangled advertising.
• Persistent visible relevant ads. - This is the model adopted by most modern news sites and google mail.

How can those ideas be used with Bugzilla?

Institute inline ads for Bugzilla users. Ideally these ads would be targetted, relevant, and not necessarily everpresent.

What should the default ad type be?

Related bugs based on a free text index of the current bug (if the current bug is closed, related bugs should include open bugs, if the current bug is open, it probably should exclude resolved bugs). This would be the default in general, and favored by people whose role is QA.

What other types of ads should be available?

For people with request queues, the ads could be a sampled from their queue.

For people without a request queue but who have bugs assigned to them, bugs can be selected to favor severity, target milestone, priority and possibly a bit of a quirkiness bonus.

For people without request queues and bugs, a somewhat random sampling of bugs should be made available, possibly favoring components which the person has touched (reportedby, or component|assignedto changedby), and possibly favoring at times old or new bugs.

How many ads should be shown at a time?

Probably three, this seems to be the number used by gmail and slashdot.

How could Bugzilla intelligently select a user's Role?

• QA - Users who report many bugs or who resolve many bugs as duplicates, or who don't fall into other categories.
• Requestees - Users who have many outstanding requests.
• Assignees - Users who own many open bugs.

How often should Roles be recalculated?

Probably not very often, perhaps weekly or monthly. Most of the time, people don't change their behavior, and if they do, hopefully they'll be willing to specify their behavior to Bugzilla directly.

How often should ads be displayed?

Probably the first quota bug views for the time interval and then perhaps every sqrt(quota) out of 10 bugs.

What controls would there be?

• Administrators could specify a quota of 0 (default to not showing users ads), or some larger number and a time interval (day, week, month).
• Users could specify a bigger quota (if the feature grows on them and they like the model), the role they'd like to play and if they're feeling really excited for a given period they could reset their quota to increase the number of ads they get without permanently volunteering for a higher load.

How could your reward users?

Obviously you could give scores to people who answer the most ads. But hopefully they system itself will be reward enough.

Getting Bugzilla users to Do What You Want Getting Bugzilla users to Do What You Want

How do you get Bugzilla users to do what you want?

That's unfortunately a very hard question.

What has been tried before?

• In the beginning there was whining. When a new bug was filed against a developer, the developer would be sent additional mail until the developer marked the bug as assigned.
• Creating a request queue. When a new request is made against a developer, the developer is sent an additional mail from a different return address, otherwise, the developer tracks these requests (while they're pending) through yet another interface. After a request is granted, it becomes fairly hard to track.

Does experience indicate that the original whining worked?

No, it does not. People started to ignore it, or complained and eventually it was turned off.

Does the request queue work?

Not really, there's no shame in having a long request queue, just as there's no shame in having many whines. Bugzilla currently has 50 requests, I have about 20, and I have about 100 requests of others which are moving nowhere very slowly.

Would adding whining for requests help?

Probably not, there's not much evidence to suggest that the original whining worked well, or that real people whining works particularly well.

Putting bug filers to work Putting bug filers to work

Where can we find "manpower to manually triage all of these old bugs"?

One possibility is to give people a random subset of their open bug list when they log in and asking them to triage it. depending on how annoying you want to be, you could demand that they do so before they take other actions.

How could we harness this potential workforce?

Make people who do not have canconfirm do triage before filing a bug. this could be done in a few steps.

1. A user files a bug and the bug gets put into a holding bin.
2. the user is then given some random (* it's best to try to select the list based on the user's bug filing) portion of the unconfirmed or open buglist for that component and asked to select 5 items from it to be tested.
3. the user would be encouraged to either update the build tested field or add a comment in the case where the bug works for them.
4. if the component does not have enough open bugs, the list could be changed to only resolved (and not verified bugs), again with the user being requested to test 5 (* number is arbitrary and of course should be tunable) such bugs and either comment indicating the problem still occurs [perhaps simply filling in an item into the build tested list], or adding to the verified field.

So what would this do? we can call these brownie points and allow the user to accrue them.

What would users do with their brownie points?

they've earned enough brownie points, bring them back to the bug report they wanted to file and give them a chance to edit it or submit it. hopefully after they've triaged bugs they'll realize how they can improve their filing.

What if the component is really in mint condition?

• We could choose not to require this form of pruning
• Give them a random selection from another component.

What does this give us?

magically you now have "manpower to manually triage all of these old bugs" and while it might not be "the best use of it", it would certainly be a very good use of it.

What's the status of this proposal?

I received a bug report in the Webtools:LXR component, I gave the reporter 3 related open bugs and asked for triage. As it happens, I picked bugs with the same exact url, but we can also do body matching if we don't get good url matches (boy was i lucky). the list of 131 bugs included 72 open bugs.

Spam for the sake of database purity Spam for the sake of database purity

What's wrong with auto resolving unconfirmed bugs?

Lots of things.

What's wrong with a little spam?

Just because you think there's only a little doesn't mean it won't add up quickly for someone else.

What problem am I really talking about?

Gerv's proposal to autoresolve bugs and other people's counter proposals to auto poke bugs to prevent him from autoresolving bugs.

What did i have to say about gerv's proposal?

It incurs more damage and harm than leaving the problem as is. if the bug reporter is good, as happens to be the case of a reporter (to be named later, pending notification and verification from the innocent), he will eventually resolve the bug as worksforme. if the bug reporter is not good, as is probably the average case, we may never hear from him again, and may instead get 15 other reports of the same problem over time.

What improvements have we made to bugzilla recently?

We changed the default search from searching NEW, ASSI, and REOP to --- and DUPL.

How was that insufficient?

people are never going to search the worksforme pile and simply reopen a previously reported bug. We really should include WFM for canTconfirm users).

What was the challenge?

But let's hear your alternative. Where do you suggest we find the manpower to manually triage all of these old bugs? And, having obtained this mass of manpower, would that really be the best use of it anyway?

How can enabling a new feature be so bad that it shouldn't be done until some other old bug is fixed How can enabling a new feature be so bad that it shouldn't be done until some other old bug is fixed

Improving Bugzilla's Flexibility to Satisfy QA Needs Improving Bugzilla's Flexibility to Satisfy QA Needs

QA Fields

How should Steps to Reproduce, Expected Results, and Actual Results be handled?

Four related widgets:

• Comment [#1 by foo @ time |v] contains the current (...).
• An iframe shows the currently selected comment.
• Link to comment
• Update link, which copies the currently selected iframe text to the comment field and changes the Comment select to [Newly submitted comment|v].

If someone wants to update the steps to reproduce, they'd click the link by steps to reproduce and be scrolled to the comment where the current steps are, they could then copy the steps to the comment area and change