Mailinglist Archive: opensuse-project (370 mails)

< Previous Next >
[opensuse-project] Re: Improving the bug management lifecycle/process
  • From: Jim Henderson <hendersj@xxxxxxxxx>
  • Date: Thu, 17 May 2012 00:14:08 +0000 (UTC)
  • Message-id: <jp1fsg$gbh$>
On Thu, 17 May 2012 08:33:19 +1000, Helen South wrote:

On Thu, May 17, 2012 at 5:05 AM, Per Jessen
<per@xxxxxxxxxxxx> 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

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

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

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

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

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 Henderson
Please keep on-topic replies on the list so everyone benefits

To unsubscribe, e-mail: opensuse-project+unsubscribe@xxxxxxxxxxxx
To contact the owner, email: opensuse-project+owner@xxxxxxxxxxxx

< Previous Next >