About Bug reporting

[Nokia Ron]

I am pushing for a free bug reporting site until then they must be submitted to Forum Nokia Pro tech support pages.


Ron

[mgroeber9110]

I am pushing for a free bug reporting site until then they must be submitted to Forum Nokia Pro tech support pages.

Just to clarify, does this mean opening a paid support incident?

[Nokia Ron]

I'm splitting this thread off

Just to clarify, does this mean opening a paid support incident?

What was suggested was a discussion board like area where you can listwhat you consider bugs. This way others can comment on them and they prove they are indeed bugs. One reason we ask for ain incident voucher for bug reports is it costs manpower to validate what turns out to be programmer errors.



Ron

[mgroeber9110]

What was suggested was a discussion board like area where you can listwhat you consider bugs. This way others can comment on them and they prove they are indeed bugs. One reason we ask for ain incident voucher for bug reports is it costs manpower to validate what turns out to be programmer errors.

I for one would be happy with a discussion board-like setup, as long as it is reasonably certain that the people who write the "KIS" notes read it from time to time and give consideration to the contents... by making it a public forum, the Nokia people can judge from the replies and the reference threads whether this is worth following up, or whether it looks more like a programmer error.

I think using paid support for bug reports is something I would be less likely to do, because no matter what cost the case voucher is, it would involve going through the budget approval process in our company each time I wanted to report a bug, which I see as a service to Nokia and the community at least as much as much as "scratching my own itch", I would need to get someone else (in a different country, and a different department) to take out their credit card first... I suspect that in many larger companies the engineers at the "coal face" who discover bugs first will be in a similar situation, so this would probably discourage much valuable feedback.

Of course, I understand that there must be a balance between genuine bug reports, and things that are effectively technical support (though which side of the fence programmer errors caused by inaccurate documentation would fall on is probably a judgement call...).

[Nokia Ron]

I'm thinking of making this a sticky, to see if others have opinions on this.

The point is we need to be sure that the information is caught. We need to be sure that the information is valid.

We also need to make sure that the information is interpreted correctly by others. This is why the only type of public bug database I ever favor is one where the actual bug can be discussed so everyone understands it.

Ron

[mgroeber9110]

We also need to make sure that the information is interpreted correctly by others. This is why the only type of public bug database I ever favor is one where the actual bug can be discussed so everyone understands it.

I agree, especially when it comes to deciding whether a bug is really a bug, or user error - however I think it would be a good addition to such a database if there is also a parallel "canonical" document (like the Technical Library) that includes those issues that have been accepted by Nokia as known issues, and may be considered for future revisions.

This would give newcomers a quick place to look for things that have been "discussed to death" already, and also give Nokia the ability to link this Known Issues document to the API documentation (which would be more difficult for an open-ended thread on a discussion board...).

I am still a bit concerned that relevant information for what often are fairly straightforward restrictions are spread out over quite a number of different documents (Technical Library, Firmware Bulletins [which can be relevant, say, for CTelephony compatibility], SDK reference, Whitepapers, Discussion Group postings...).

As an example, one could look at how the fact that MMdaAudioOutputStreamCallback::MaoscPlayComplete diverges significantly in behaviour between devices and emulator (since early 2nd Edition) has not yet made it into the SDK documentation, and the statement "If the end of the sound data has been reached, the function returns KErrUnderFlow." still sits there uncommented, even though it is plainly incorrect on actual devices [the callback only gets invoked on real error conditions, but not at the ordinary end of playback]. In fact, as of v1.26, it is not even listed in the FN Technical Library.

This has probably foxed many people implementing audio on Nokia phones, is part of a recommended, public API, and was mentioned in numerous postings, so I think this could be a good case study for how such reports should be handled...

<climbs off soapbox again, and gets back to writing code...>

[Nokia Ron]

I would urge people with known issues to add a message to the Sticky Thread for them. With our new system these messages will come up on a FN Search both in the DiBo and in other places in Forum Nokia.

If you file an incident report the reporting system will walk you through ways to find if this is a known bug or feature etc and if there is any information about this before you need to purchase a voucher. We are adding a system for feedback on resource pages which will help dramatically in finding issues before they become an issue. I understand your point about information being scattered but this is pretty true universally. I am hoping that the new feedback system that for resources that come out after this is implemented there will not be the need for scattering.

Ron