Planet maemo: category "feed:b60f2338d7a5b72897d3a13b738ecf26"


Problems with Mail Clients

2005-10-02 11:14 UTC  by  timeless
Problems with Mail Clients Problems with Mail Clients
Click to read 1018 more words

Improving Mail Clients

2005-10-02 11:10 UTC  by  timeless
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> <Picture 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

2005-09-21 06:54 UTC  by  timeless
Autoshaping based on user tendencies Autoshaping based on user tendencies
Click to read 994 more words

Alternatives to Supporting Comment Redaction

2005-08-05 09:45 UTC  by  timeless
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

2005-08-05 09:38 UTC  by  timeless
Allowing users to edit their comments Allowing users to edit their comments
Click to read 1418 more words

Advertising intelligently to Developers

2005-06-01 09:14 UTC  by  timeless
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

2005-06-01 08:32 UTC  by  timeless
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

2005-03-24 01:16 UTC  by  timeless
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

2005-03-24 01:06 UTC  by  timeless
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
Click to read 2298 more words
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
Click to read 1968 more words

On Customizing Bugzilla

2005-01-09 10:34 UTC  by  timeless
On Customizing Bugzilla On Customizing Bugzilla Suppose you have an established QA process and are transitioning from an established tracker (ClearQuest) to Bugzilla 2.16. What changes might you want?

I recently saw a real company make real modifications. Most of the changes are depressing, we'll see an example bug entry form (<enter_bug.html>), an example bug (<show_bug.html>), an example bug activity (<show_activity.html>), and the query page (<query.html>). Some of the ideas behind the changes are good, but perhaps people can find a better way.

Background (Bugzilla 2.12)

Note that one requirement of any tracking system is a complete change log. Bugzilla normally does this by refusing to allow comment deletion / modification and storing any other changes in an activity log. The log has a per field length limit (256 bytes?), when a field is longer than the limit, the change is recorded by splitting it into multiple change records.

A long time ago, the CC fields was a single text field and Bugzilla suffered dataloss because changes in the activity table didn't deal well with it. But even before then, simply reading changes to the CC list was hard because most of the string was the same. As someone experienced with Bugzilla and the activity log, this is something that I remember with dismay.

Requirements of a converting QA team

A good bug has:
  • steps to reproduce
  • expected results
  • actual results
QA needs to be able to see:
  • build tested
  • build verified
Engineers need to be able to mark bugs for:
  • release noting

Requirements of a customer oriented company

  • for categorization and because we will not be giving everyone access to the bug tracking system, there must be a way to tag a bug as reported by:
    1. customers
    2. QA
    3. development
    4. marketing
    In ClearQuest there's a related use case field, such a field shouldn't really be a problem for Bugzilla, but if you're new to Bugzilla you're likely to reinvent it anyway.