On Thu, 17 May 2012 08:33:19 +1000, Helen South wrote:
On Thu, May 17, 2012 at 5:05 AM, Per Jessen <per@computer.org> wrote:
jdd wrote:
Le 16/05/2012 18:41, Bryen M Yunashko a écrit :
And let's be honest. People don't want to read, read, read. They encounter a problem and just want to report it and be done with it.
I don't think so.
I disagree, Bryen is right - people don't want loads of reading. Everyone is very busy. I NEVER watch videos, I just won't spend ten minutes watching some poor quality explanation of something I can read in thirty seconds. But we need to find some middle road: we are constantly pushing the fact that we are user-friendly enough for less expert users, so we're going to have to deal with bugs from those users.
Well, yes, but in terms of overall users (rather than individual experiences), I think there's benefit to (a) having things documented, and (b) providing those short snippets for those who learn that way. People learn in different ways - myself, I'm far more kinesthetic (hands- on) in learning that those who can read something and get it. But I also have no problem just diving in in most cases and starting to do rather than wanting to be told what/how to do something so I don't break it.
From a training perspective, if we can come up with some content that can be re-purposed for different learning methods, we can cover a lot of ground fairly easily. But the learning "industry" has been moving away from more monolithic methods of learning (read: instructor-led classroom- based training) and more towards more agile methods, such as podcasts/ video/short online sessions/etc.
To successfully get our community members (especially the non-technical ones) involved, we need to engage them in a way that they are able/ willing to consume. That's why we have diversity in our communications mediums with forums, mailing lists, IRC, and so on. As my former boss (when I was in Novell's training department) said to me once, if he wants to repair a hole in his roof, he's going to use Google to find a video of how to fix a hole in his roof. He's not going to take a class on how to put a roof on a house. The same principle applies in this instance. We need to understand how our community *in general* consumes information in order to get involved, and then provide it in a format that they are comfortable with. It's also axiomatic, I think, to say that the way you get people involved in something they're not comfortable with is start with something they are comfortable with. So the delivery mechanism matters, and it's not going to be just one method - because that won't reach as much of the audience.
people want they bug *fixed*. It's of no use to have more bugs reported if we can't fix them...
Actually fixing a bug and getting the fix installed on a user system is quite a long process, especially for inexperienced users.
This is important. We can include some documentation at some point in the process - perhaps a thank-you note post-submission (once someone has invested the time to submit, they are more likely to read it) - that explains this: That the bug fix may take a long time to implement, and they may need to do a fresh install.
Agreed. Follow-through is important, as is setting the expectations (and then meeting the expectations that are set - otherwise setting the expectation is meaningless).
Agreed, it is daunting. What if the the landing-page had two simple options: one, "I'm a technical user and have a Bugzilla login, send me there!" and two "I want to report a bug and haven't used bugzilla. Take me to the easy forum OR show me how to use bugzilla" and have a dedicated forum thread for bug reporting, where we can more easily discuss a bug and a third party can put it on bugzilla. The issue there would be (a) personnel to do the escalating and (b)possible loss of information.
I like this. Another idea would be to have some mentors available to help guide someone through the process of submitting a bug. Using something like Teamviewer (would love to hear about a good OSS alternative to this, too) to do a live demonstration and to gather information could well work. Never underestimate the power of a personal interaction.
could it be possible / usefull to *require* an IRC chat *before* reporting a bug????
No doubt very useful, but hardly possible for a non-commercial operation.
That'd put off a lot of users. Many don't use IRC. Could say the same for forums, but I think people are more comfortable with forums generally.
Another idea is that we have some non-technical flags on a bug: stops install process/affects configuration/security/ random UI problems/obstacle to productivity/printing/ specific software problems/no sound/visual glitches/ other small things that are annoying /trivial issue that looks unprofessional - that might allow a keen but less technical user to assist with triage.
Sort of a self-classification system that's in lay terms? That could be good. We'd want to get some of the target audience involved in crafting the wording. Doing that would help ensure that we used wording that made sense to non-tech people, and of course would help increase buy-in. Jim -- Jim Henderson Please keep on-topic replies on the list so everyone benefits -- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org To contact the owner, email: opensuse-project+owner@opensuse.org