Re: Bugzilla: is there a walk-thru somewhere?
 

The thing is, "consumers" don't report bugs, so why design a system for them to do it?

Anyone who feels the need to "report bugs" probably isn't scared by the word "repository".

Bugzilla, as is probably quite apparent to everybody, is not for normal users and adapting it to accommodate them would be defeating the purpose. Bugzilla is for power users, developers, and generally anyone who is exposed to bugs on a regular basis. 99% of platform bugs should get squashed or at least reported by developers/power users before they reach production devices, and bugs in Extras software should get reported during the testing process. Both these scenarios involve people that will know how to use Bugzilla.

If normal users are needing a way to contact developers, then an alternate solution should be created. But please don't try to adapt a development tool into a user-facing one.

Re: Bugzilla: is there a walk-thru somewhere?
 

Not sure what you mean - apart from, for some reason sounding overly defensive.

Since you asked, I think the SSO issue should have been resolved a long time ago and that the 'due date' is significantly overdue.
As to 'what happens when it's not met' - I would imagine a combination of continued customer/user dis-satisfaction, reduced levels of involvement (fewer people signing in to systems they have to create a separate account for), continued frustration when the same issue comes up again and again (SSO as an example) and the answer is 'It is being worked on, look here" but with no indication of when it will be resolved - and of course a reinforced perception that the maemo development community is not capable of rather fundamental project management.

Do note however that I don't think that the developer community is particularly poor w/in maemo. Quite contrary, I've seen some really nice applications being developed here and they have added a lot of value for my own NIT use and I am extremely grateful for that and to them. It does, however, not mean that I will have to love every single thing about how maemo.org is being run and I find bugzilla and the rather lackluster project management skills to be very lacking. But once again, I see that as being more a sign of lacking resources and being spread too thin on multiple competing initiatives.

I wish Nokia would step up and assume some ownership of the situation. Maybe invest something more substantial into the community that is developing many of the software reasons that people base their purchase decision on. I know Stskeepes(Sp?) got a p/t position with Nokia a few months ago but not sure what/if that is doing much.

Finally, not sure where you get the notion that due dates are 'inaccurate' and 'unuseful'. I've managed projects for over a decade. Some spanning continents and hundreds of f/t and p/t resources. One of the more important aspects of due-dates is that it helps to set expectations both within the team as well as to its sponsors/customers.

I've said it before and I'll be happy to repeat it: To me the meamo development community is too small to develop and support applications on multiple OS. This will lead to Mer slowly dying and to many of the N8xx applications not getting worked on (the lack of continuity/support of maemo applications has been rather non-existent even prior to the N900 release). I'm sure the N900 will bring a couple of hundred new developers but in 12 months when developers start ramping up for Harmattan we will see the same thing happening again.

I love my N810. I accept that what I have is a really nice h/w device with 15-20 really great applications and a slew of eternal beta-developments. I will however, never spend any money on a device that is supported by a community that is so poorly supported by Nokia themselves.

That's my personal opinion. Yours may differ but I'm entitled to mine.

Re: Bugzilla: is there a walk-thru somewhere?
 

We don't want 95% of users to report bugs. Most of them are woefully under-qualified to do so without generating massive overhead for the limited number of people working on triaging bugs to make them consumable for the developers who will actually be able to fix them. Spam doesn't do anybody any good, in the end, having every user report every perceived problem they run into (the vast majority of which will be Andre's configuration problems) you end up with a completely unusable bug tracker. Bugzilla is hostile enough towards Nokians already, thanks.

Re: Bugzilla: is there a walk-thru somewhere?
 

Those 95% of users are also members of the community are they not? It's a little bit of Animal Farm to say that we are all equal - but some more than others.

'Most of them are woefully under-qualified'.
Seriously?

'Spam doesn't do anybody any good"
Users bringing up complaints about functionality - is spam?

"Please buy our product and join our community. But shut up once you're here".

Re: Bugzilla: is there a walk-thru somewhere?
 

No, the vast majority of them are not and never will be members of the community. They don't participate here and most of them don't know what maemo.org is (or Maemo at that). Most people buy a phone to have a phone, and getting them to file bugs isn't on the top of our priority list.

What we want to do is get people who are interested in filling bugs doing so and balancing the amount of pain that both developers and users have to suffer in the process (it's never going to be pain free for both sides, when you make it easier for one, you usually make it harder for the other).

Yes, this is why bug triagers exist. If everybody were completely qualified then you'd never need to triage bugs. Get back to me when you've had your life threatened (on multiple occasions) by "bug" a reporter. :)

Are these complaints bugs, or just complaints? Complaints generally belong either on the forums or the mailing lists. If they're not reproducible codewise issues, then they don't really belong in bugzilla and

Whatever, we're wandering way off-topic here. Political discussions aren't productive. Bugzilla is the tool we use and the tool we're going to continue using, so let's stick to concrete examples and ideas we can use to improve it (like krisse's list). If all you want to do is vent your spleen, then please find another venue for it.

Re: Bugzilla: is there a walk-thru somewhere?
 

I mulled this over last night, and would like to suggest more changes to the language. Title the first section: "Tell us about your device" and the second "Now tell us about your problem"

Simple questions like "What were you doing when the problem happened?" "What actually happened?" "What did you expect to happen?" "What did you have to do to recover the device?" and "What else did you have running in the background at the time?" ask for the same information in words ordinary people can understand. "Expected outcomes" and "Actual outcomes" (along with that strange string along the bottom) aren't easy to follow. This might also be easier for people filing in a second language.

I think there's a danger in becoming elitist about who can/should submit bugs. Six months down the line here there's a huge risk that all those people who jumped in with enthusiasm in the autum will be telling their friends to avoid anything maemo as it's 'buggy as all hell'. If we can involve some of them in the improvement process, they will realise what they're part of and feel they belong, which should make them more patient.

Is all this going to make more work for the bug-squad? Yes, it is. But frankly, they're going to get a pile more work when the new devices reach people's paws anyway. Making the system one where more people might actually submit usable bugs would be better than them handling mountains of useless ones.

Re: Bugzilla: is there a walk-thru somewhere?
 

Yet I was specifically asked (by the Bug-Master) to file a bug on the user-unfriendliness of Bugzilla - which is certainly not a code issue.

So now I'm even more confused than ever! :(

Re: Bugzilla: is there a walk-thru somewhere?
 

Kathy I think you're getting confused on semantics. If an action is reproducable then it can be filed. The issue being talked about is one of communication of the issue in question. Your earlier post was actually quite good in that regard.

If the programme is able to perform as expected without blowing up or acting in an unexpected manner then I would say it is not suffering from a bug.

If the functionality could benefit from additions or modifications to make life easier then there is a debate on whether it is a bug or simply an interpretation.

Breaking design guidelines for user interface would be considered a bug as there is an expected behaviour being deviated from.

If there is just something you would like to see that isn't covered then I wouls start with a brainstorm to ouline your requirements and get some votes for an enhancement to the existing behaviour.

Hope that makes sense and helps some. Does that sit ok with everyone else regards designations?

Re: Bugzilla: is there a walk-thru somewhere?
 

Err no. I understood the first part of that (I think) but then you lost me.

The problem is I speak a range of 'elite' languages - medical, mental health, church (in several variants) theology (again several variants) and sci-fi. But I don't speak OSS. So there's lots of terms being used I simply don't understand. It feels like I'm working in a foreign language which I never got beyond 'o' level.

What exactly do you mean by "Breaking design guidelines for user interface would be considered a bug as there is an expected behaviour being deviated from."

My best guess you mean is that it isn't doing what I expect because I expect to understand it (at which point we're going in circles).

The problem is reproduceable in that I have a mild panic every time I look at the Bugzilla page. ;)

As for brainstorm... I cam start a thread in the brainstorm forum, but if you want me to do more than that... well, I'm back to the same problem.

Re: Bugzilla: is there a walk-thru somewhere?
 

There is a fine line you have to watch here. If you make it too easy to report bugs, you'll have tons of bug reports which aren't usable at all and really require extra work to be made into something usable. If you you make it too hard, you'll only get bug reports by people who don't see many bugs, as they find (for them) easy workarounds.

As someone administrating a slightly easier system (for the user, it is not really for the developer) - Mantis - I see that the tendency for unusable bug reports is there, as that one only requires you to add a Subject line and a short summary.

On the other hand the developer tools aren't as sophisticated, so it makes it harder for people actually work on bugs.

That is what GeneralAntilles was trying to say, I guess: You really only want bug reports by people who at least have thought about how that what they are seeing could be a bug. And you really have to watch out that bug trackers aren't seen as support venues - that's what the web fora and mailing lists are for.

So yes, bugzilla seems to be overly complex (and Krisse already has brought up a great list of valid points) , but it also has uses. What would be great if you could split front- and backend. Gnome does something like that with their bug-buddy tool for bugs which crash system components - bug-buddy automatically files a report into the gnome bugzilla.

On the other hand: If feedback is needed, you have to get the user who submitted a bug via bug-buddy to open an account on the bugzilla at gnome and report back. If the user has to use bugzilla, h already has an account and can answer directly. You always have that step in there: The requirement of having an account.

So in one case you might not get something which you can call "a usable bug report" but you can ask for more info easily, as the reporter already has registered. In the other case you have a easily made bug report, which contains much of what you need to resolve a bug, but the backchannel to the reporter is much worse, as you first have to convince him to get an account.

That is another problem which I see: Normally the number of bug reporters go up, the number of people who - even if they have the knowledge - help sorting out bugs into "not a bug", "easy to fix", "someone needs to take a deep look into that" don't. So yes, you will have to find a way which makes it easier for users to submit good bug reports. This is something where quality matters - not quantity.