I've been thinking a lot about it, all "trolling" and goofing around aside, and I realize that the problem is that we need a policy here.

Either we tell people to file a bug when they have problems, and focus on making Bugzilla friendly to end users, or we don't mention Bugzilla and the experienced developers and bug-filers act as an intermediary between problems raised in the forums by end-users and the engineers on the other side of the Bugzilla system.

If we don't mention Bugzilla on the forums anymore, this means we need a team of bug-filers who filter and distil the noise of the forums into coherent, well written bugs.

I think this is a good way to do it. I do some document control work, and I know how important it is to have standardized ways to communicate on forms. If we get a team of bug filers to work with our bugmaster, we can get a well-oiled machine set up where the bugs are clear and concise, and the signal-to-noise ratio goes way down.

What I'm talking about here is a kind of community support team. If the user doesn't give enough information in his post originally, or nobody can reproduce the problem, the bug-filers will "interview" the user to get as much information as possible, but in a much more "supportive" way than is possible in the harsh environment of a bug reporting system. The community support people / bug filers will then file a bug and post a link in the thread to the new bug.

I know this is happening to some extent already, but I really think we should stop telling end users to file bugs, when that tends to cause problems for everyone: duplicate bugs, vague confused bug reports, simple problems that could have been fixed with some help from a forum guru, etc, etc.

In fact, there probably could be some kind of suggestion on the bug reporting form that the reporter should ask about the problem on the forums first, before posting a bug.

As usual, these are just some suggestions for discussion. I don't really care if they are followed, I just am getting tired of the arguments and hostility around here lately, and I want to try to inject some positive, lets-move-forward energy.

And no. Before you suggest it, I'll tell you: I'm not filing an enhancement request.

A general principle is that any bug report is better than no bug report.

This goes together with another principle: good reports lead to good resolutions.

Said that, it's not always the duty or the capacity of the bug reporter to come up with the perfect bug report at once. Or to know all the activity around. This is why bug triagers are very important filtering, complementing, prioritizing... This way then the developer able to fix the problem can go ahead making a good use of his time.

If you want to follow the bugs & enhancement requests activity:

Maemo Bug Jars
http://talk.maemo.org/showthread.php?t=26001

maemo.org Bugzilla Feature Jar
http://talk.maemo.org/showthread.php?t=27833

If you want to vote for reports and enhancement requests or file new ones:
http://maemo.org/community/bugs_and_features/

If you want to help triaging bugs & requests:
http://wiki.maemo.org/Bugs:Triage_guide

More:
http://wiki.maemo.org/Bugsquad

In general I try to take a quick look into ITt every day and ask people to forward valuable issues (and I ask everybody else to do the same, please) - that's also what the Bugsquad is for.
Forums (and sometimes mailing lists) are often the first entry point when somebody has an issue - whether it is a misconfiguration or a real bug. Hence I'd like to avoid "can't send mail, plz help" tickets in maemo.org Bugzilla (seen that way too often in Evolution "bug" reports in GNOME Bugzilla and end up closing as NOTABUG and asking people to use a forum instead) and encourage reporters to file real issues in maemo.org Bugzilla.
If there's any ideas to improve this (IMO forums should be a bit more chaotic than bugtrackers due to its nature), just say.

Isn't the bug squad supposed to triage bugs, get more information, and assemble a coherent bug report for the engineers that resolve then? I think (in theory) we have a system in place that does what you propose. As a user, my expectation is that I *should* be able to file bugs.

What I have found in my limited use of bugzilla is that it is not intuitive for an average user like myself. For instance, I filed an enhancement request (4110) after doing a search within bugzilla for something similar. When I did not see anything like what I was proposing, I filed it. A few days later, I found out it was a duplicate of an existing enhancement request (2819). The terms I had used in my initial search did not pull up this existing request. Furthermore, as I typed in my own request, I was not presented with a list of similar bugs that may have been relevant.

I can offer a few things that would make it easier for end users like myself:

1. As ITT did with new threads, is it possible to present a list of existing bug reports (no matter what the resolution or target was) to the user as he/she starts filing their bug. This will limit the S/N ratio.

2. Perhaps 'bugs' should not be able to be filed until they go through a few hoops first. Just like Canadian 'Laws' start out as 'Bills', perhaps we need something for pre-bugs --> URPs (User Reported Problems)? Once it gets some attention from the triage team, it becomes a bug with sufficient information and clarity that the engineers require. I think this is what you are proposing. I think it is better to do this under the bugzilla guise, rather than in a forum. URPs do not get the attention of the engineers, and anybody can file them.

While I can't speak for others, as I see it, you did everything right. Duplicates happen in bug tracking systems. You put forth a good effort to avoid creating one, which is all that can be asked, I think.

I do not think such a feature is available, even in the latest version of Bugzilla. (EDIT: I was mistaken. The guided interface to Bugzilla will do this, as Andre points out in a message below. Thanks, Andre!) And we're not on the latest version.

For enhancement requests, such as yours, a new front-end is coming. Maemo Brainstorm should make for a more user friendly, more easily searchable web-based tool for submitting, voting upon, and commenting upon enhancements.

I don't know that a similar front end is needed for bugs, but it is an interesting idea to ponder.

I was not aware of this proposal. I like it alot! Right now, enhancements and bugs are entered and viewed in the same manner within bugzilla. So, from my viewpoint, using Maemo Brainstorm for both would make sense.

I agree with sjgadsby: Filing duplicates is not bad at all... If you find out that your bug/enhancement/whatever is a duplicate, take a minute to go to the "other" bug and add your info, votes, etc.

Tim

...which is not bad. It simply happens. It's already great that you searched before filing it - not everybody does.

This is possible by using the "guided" interface, see https://bugs.maemo.org/show_bug.cgi?id=2463 , but it currently does not have high priority. From my own usage I'm not totally convinced of it, but as the bug database and especially the user database grows this should become the default for newbie (means: without canconfirm permissions) bug reporters.

It does add another layer to the process though. For enhancements, the additional layer brings enough benefit to make it worthwhile, but I'm not so sure it would help bug reports.

Enhancement requests tend to be big ideas that require larger scale design and planning work before eventual implementation. Brainstorm makes the design and planning discussion and voting process easy and accessible to end users, as it should be. Then, at the end of the process in Brainstorm, a well-defined enhancement request can be placed in Bugzilla for the implementers to target.

There's real benefit there, as Bugzilla's discussion capabilities are limited, and it does not provide the granular voting capability necessary to refine an initial enhancement idea into a plan. Brainstorm and Bugzilla form one of those synergy things.

In contrast, bugs are often smaller, are by their nature more definite (once determined), and should see faster turn around. Discussion is sometimes necessary, but it's usually just to define a bug's effect and cause as clearly as possible to speed resolution and confirmation.

Currently, bugs (and enhancements) exist in both the public, maemo.org Bugzilla and Nokia's own internal bug tracking system. Nokia uses the internal system to hide private details of unreleased hardware and software. So, right now, Andre, for instance, spends time moving information back and forth between maemo.org Bugzilla and the internal tracker, sanitizing as necessary. This is better than it was previously, when reports of bugs at maemo.org Bugzilla often received no feedback at all, but it's hardly ideal. As a long term goal, some folks are investigating solutions that might allow for the elimination of the internal system, which would free Andre up for more productive work.

However, if a Brainstorm-like system were used as the friendly front end for bugs, we'd need many volunteer Andres to move information between that system and maemo.org Bugzilla. It's an increase in work, and it turns bug reporting into a game of telephone, where we risk losing important details.

Thank you all, for your information.

I had not even heard of this Bugsquad that Quim and Andre mentioned. That's very much what I'm looking for here.

If anything, I'd like to see a pre-triage stage that starts in the Forums.

The only other thing is that I'm still not convinced we should be pointing people to the Bugzilla. Perhaps instead we should have a Bugs: wiki page for new bug posters, and send people there instead?