Getting feedback from user support helpers
Nick Thomas (cf)
users, e.g. the usual suspects in #firefox & #mozillazine on IRC,
moderators at the Mozillazine forums, and the "Champions" on the
newsgroups. It seems to me that these people can provide valuable
feedback to developers by reporting which bugs are hurting users most
frequently and severely. In this way, the overall user experience of
Firefox can be improved.
Since there was some encouragement for this idea when I mentioned it on
IRC, here are some ideas on how it could work.
* a Bugzilla keyword/status-whiteboard-phrase(fx-top-support ?) to be
set on existing bugs, with new bugs filed as required. Requires
sufficient Bugzilla privileges & experience for the helpers, but is
integrated with the rest of bug triage and targeting system.
* discussion on this newsgroup (or another one as deemed appropriate).
This option is nicely non-volatile (unlike IRC), as long as it doesn't
distract from the development discussions starting up here.
Cheers,
Nick (aka cf on IRC)
Mike Beltzner
cheers,
mike
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
--
-------
mike beltzner, user experience lead, mozilla corporation
Nick Thomas (cf)
> Great idea, Nick. Can you file this and CC me? Keywords, AIUI, can't be
> restricted by priveledge, but I'm sure we can figure out some way to
> implement this. It might just be that we create a #firefox username in
> BZ which is shared by the "champions" in #firefox, and leaving a comment
> (since that's a query-able event) will be enough to tip us off.
Apparently you need editbugs on Bugzilla to modify Keywords or the
Status Whiteboard. Having an editbugs account with open password
probably isn't too flash :-)
Mike Beltzner
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
Chris Ilias
> * a Bugzilla keyword/status-whiteboard-phrase(fx-top-support ?) to be
> set on existing bugs, with new bugs filed as required. Requires
> sufficient Bugzilla privileges & experience for the helpers, but is
> integrated with the rest of bug triage and targeting system.
How would the above differ from bugzilla votes?
Don't get me wrong. I like the idea of using support volunteers as a
liaison between users and developers, but I don't want people to waste
their time reinventing the wheel.
--
Chris Ilias - Mozilla Champion
mozilla.test.multimedia moderator
Mozilla links <http://ilias.ca>
(Please do not email me tech support questions)
Mike Beltzner
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
Mossop
> Votes aren't (from what I understand) really paid attention to all that
> much. The idea here is that people who are providing a lot of support to
> users have a good impression of what the most frequently encountered
> bugs are. Those people should be able to indicate that to the developers.
This is the key question to me. What impact is a keyword in Bugzilla or
whatever actually going to have. I can see two potentials, first it
could make it easier for users (and supporters) to see the common issues
easily. Secondly developers should pay attention to it. I would hope
that whatever we come up with can hot both those points.
Mossop
Mossop
> I wouldn't be thinking of making it an open password. I'd be thinking of
> giving the password to the notables in the channel who we trust with the
> authority to nominate bugs for "this is something we see all the
> friggin' time" status.
To be honest, are there really many (any?) notable supporters who don't
have editbugs? If not I'd argue that maybe they should have.
Having a "special" bugzilla account to mark bugs as noteworthy really
doesnt sound usable to me, it involves logout, login, flag then logout
and login as yourself.
Mossop
Mossop
> There are quite a number of people who regularly provide support to end
> users, e.g. the usual suspects in #firefox & #mozillazine on IRC,
> moderators at the Mozillazine forums, and the "Champions" on the
> newsgroups.
> * discussion on this newsgroup (or another one as deemed appropriate).
> This option is nicely non-volatile (unlike IRC), as long as it doesn't
> distract from the development discussions starting up here.
This is quite important I think. We have three different support
channels: IRC, Forums and Newsgroups. From what I've seen there is not a
great deal of overlap of the good supporters in each area. Having some
medium for cross pollination is an excellent idea. I'm actually inclined
to suggest a different medium for it though. Newsgroups and forums are
great for initial and somewhat informal discussion, but why not a
newsfeed for some of the final results?
On an operational side, if we choose to go a route of nominating issues
as important, how can we manage that? I would feel confident saying that
something came up a lot on IRC, but I wouldn't have a clue about the
forums or newsgroups. At what point is an issue important, when its seen
a lot in one channel, or only in all three? An issue could be the most
common, but not common in any support channel.
Mossop
scratch
> Great idea, Nick. Can you file this and CC me? Keywords, AIUI, can't be
> restricted by priveledge, but I'm sure we can figure out some way to
> implement this. It might just be that we create a #firefox username in BZ
> which is shared by the "champions" in #firefox, and leaving a comment (since
> that's a query-able event) will be enough to tip us off.
how about a meta bug?
-scratch
Nick Thomas (cf)
> To be honest, are there really many (any?) notable supporters who don't
> have editbugs? If not I'd argue that maybe they should have.
You are probably right for the IRC people, but I have no idea about
forums or newsgroups (the overlap problem!)
How about a straw poll ? I'll contact people from the forums &
newsgroups to add their input.
Data point: I have editbugs and I mostly support on IRC.
> Having a "special" bugzilla account to mark bugs as noteworthy really
> doesnt sound usable to me, it involves logout, login, flag then logout
> and login as yourself.
Agreed. This needs to be an easy process otherwise it won't fly.
Nick (cf)
scratch
> Mossop wrote:
>> To be honest, are there really many (any?) notable supporters who don't
>> have editbugs? If not I'd argue that maybe they should have.
>
> You are probably right for the IRC people, but I have no idea about
> forums or newsgroups (the overlap problem!)
>
> How about a straw poll ? I'll contact people from the forums &
> newsgroups to add their input.
> Data point: I have editbugs and I mostly support on IRC.
i do a lot of forums support (though i'm not a moderator; there are a
number of people who appear to do as much or more support than
moderators there) and do not have editbugs.
-scratch
Michael Hendy
Would there be any way to use, say, a bugzilla group to accomplish this?
--
Michael Hendy
Mozilla PluginDoc - http://plugindoc.mozdev.org/
AIM: Hendikins | ICQ: 45864010 | MSN: hend...@mozdev.org
Majken (Lucy)
Most of the issues we see in IRC are already fixed, are fixable. They're
quirks that happen in the update process, mostly extension related that
have fairly easy workarounds, it's just that those fixes aren't easily
discoverable. I think if we were to do some sort of bug thing, it
wouldn't be a "fix this broken thing" but more "firefox needs to do this
better." I'm not sure how effectively we could file bugs of that nature
without first having posted the issue somewhere and discussing it.
Otherwise I think in the long run it'll annoy the devs to have "Make
quicktime embed audio better" type bugs all over the place. It'd be
better to be able to say "have x help quicktime embed audio better" I
think, anyway.
Secondly, I've caught that at least a few users I've helped have come in
for one issue, said 'well after x, if I can't fix y I'm leaving.'
Inevitably x is something we fix all the time, but the user hadn't been
able to discover this as a common issue, so they didn't pursue help and
had either been using another browser for certain things, or were on the
brink of switching altogether. I think we need a more beginner friendly
version of bugzilla's "hot bugs" for issues we're helping people with
frequently. Perhaps if there were some way to work this with the
mozillazine knowledge base. It already has great documents, we refer to
them all the time.
It would be great to have more contact between supporters from all
forums. I'd be willing to hang out on the forums, although I have to say
I really appreciate being able to deal with users realtime.
Ack, ok I'll stop before this actually qualifies as an essay, but those
were my big 3 thoughts about all this after first read.
-Majken (aka Lucy)
Robert Strong
> cf - thanks for inviting me to stick my nose in here. A few thoughts:
>
> Most of the issues we see in IRC are already fixed, are fixable.
> They're quirks that happen in the update process, mostly extension
> related that have fairly easy workarounds, it's just that those fixes
> aren't easily discoverable. I think if we were to do some sort of bug
> thing, it wouldn't be a "fix this broken thing" but more "firefox
> needs to do this better." I'm not sure how effectively we could file
> bugs of that nature without first having posted the issue somewhere
> and discussing it. Otherwise I think in the long run it'll annoy the
> devs to have "Make quicktime embed audio better" type bugs all over
> the place. It'd be better to be able to say "have x help quicktime
> embed audio better" I think, anyway.
'x'" or the like where the problem is described instead of "have x help
quicktime embed audio better"... the important point being to properly
describe the problem and not a possible solution - though possible
solutions are of course welcome.
~Robert
Chris Ilias
> Votes aren't (from what I understand) really paid attention to all that
> much. The idea here is that people who are providing a lot of support to
> users have a good impression of what the most frequently encountered
> bugs are. Those people should be able to indicate that to the developers.
Whether it be a Meta bug, keyword, voting system, whatever, if Firefox
devs aren't paying attention, or giving it weight, I don't see the value
in it. What method of feedback from support volunteers, would Firefox
developers pay attention to?
--
Chris Ilias
Nick Thomas (cf)
> Whether it be a Meta bug, keyword, voting system, whatever, if Firefox
> devs aren't paying attention, or giving it weight, I don't see the value
> in it. What method of feedback from support volunteers, would Firefox
> developers pay attention to?
You and Mossop are absolutely right, and I probably jumped the gun by
discussing the mechanics of it.
So, to Mike Connor, Gavin & Ben (and any other devs I forgot), do you
think this sort of feedback mechanism would be useful, and do you have
any comments on how to make it work.
Mike Connor
current/next release, and those that need to be fixed.
We need to make sure that the former are being documented, on an ongoing
basis, in an easy to search manner. The mozillaZine KB takes a good
crack at this, but it also has a lot of information that's a bit
dangerous in the wrong hands, and I wouldn't want to point at that type
of help DB from the main browser UI. I need to think a bit more on
this, but I'm starting to think that an online wiki-like support site
makes more sense than in-app help (we'd still have some basic info about
connection troubleshooting that would be accessible from the network
error pages).
We need to do a better job of collating feedback from releases and
prioritizing fixes for the next release, for the most commonly
encountered issues. Obviously, blocking flags are important, but in
terms of triage, a keyword or three might be in order to make plussing
those bugs an easier choice.
In an idealized world where we have a help and support DB, I'd suggest
the following keywords (actual keyword names could change, I'm more
concerned with buckets at this stage):
support-issue-undocumented - Initial state, more writery people can
query on these bugs and write support docs to a simple template.
support-issue-documented - Bugs that are commonly reported, and do not
have a fix. These bugs should be nominated and plussed if possible for
the next release, and are documented in the help DB as known issues.
Reasonable workarounds/alternatives should be documented, and an
indication that the issue is being looked at should be present, without
necessarily linking to Bugzilla.
support-issue-fixed - Bugs that have been fixed as of a certain
release. Should be documented in the help DB with information about
what versions have the fix, and workarounds for older versions should
retained, if applicable.
We're doing a great job of building up MDC (Deb rocks!) and I'd like to
get the same sort of drive behind improving our user documentation and
self-help options, and I think that we need to chain forums/IRC ->
bugzilla -> help and support docs, since searchable help content will
scale well beyond what we can do in the forums and IRC, and getting good
docs in place will free those awesome support people up to find new and
important problems, instead of being masked by the noise of repetitive
questions.
-- Mike
Chris Ilias
> In an idealized world where we have a help and support DB, I'd suggest
> the following keywords (actual keyword names could change, I'm more
> concerned with buckets at this stage):
Okay, bugzilla keywords it is.
What's the next step? Form a list of volunteers to involve in this?
Create the keywords on b.m.o?
I guess the next question is, do we go with one b.m.o user, or make sure
each support volunteer has editbug privileges? Is there a downside to
giving each support volunteer editbug privileges?
How many support volunteers are we going to begin with? IMO, there
should be at least one person from each venue (IRC, Web-forum, newsgroup).
I would also like to eventually expand this to Thunderbird.
Mossop
> Okay, bugzilla keywords it is.
> What's the next step? Form a list of volunteers to involve in this?
> Create the keywords on b.m.o?
You're missing a step. How do we decide what bugs deserve to be marked
in this way. We can't just mark every single bug that is reported by a
user, that makes it a bit of a nonsesense.
Mossop
Chris Ilias
Okay, with no answers and more questions, I guess I'll get behind the
wheel. :-)
Generally speaking there should be a large majority of volunteers who
agree on each bug that gets tagged. Let's face it, if some of us don't
think a bug is one of the most hurtful, and it gets tagged, we're being
reckless with such keywords. Start small and cautious. For instance,
there are only two bugs I can think of right now.
- lost bookmarks.
- former 1.0.x users having no way to re-enable software installation.
Those come up frequently.
We would need a gathering place to discuss them. A list on
lists.mozilla.org would do. If we can't get one there. We've got Google
Groups. Heck, I can create a mailing list on ilias.ca, if it comes to that.
Go with each person having editbug privileges, instead of one ID. I want
to know who marked each bug.
As for the list of people, again, start small and cautious. Like I
stated earlier, we should have at least one person from each venue. I'm
not familiar with most people on the web-forums or IRC; so if someone
from those venues wants to add someone from their venue, I trust them.
Thoughts? Tell me off, if you'd like. I won't be offended. :-)
Mike Beltzner
reckless with such keywords. Start small and cautious. For instance,
there are only two bugs I can think of right now.
- lost bookmarks.
- former 1.0.x users having no way to re-enable software installation.
Those come up frequently.
I like the type of bug you're talking about, and these are two well known examples. So the idea is that these would get a keyword to the effect of "frequently-observed" or something?
We would need a gathering place to discuss them. A list on
lists.mozilla.org would do. If we can't get one there. We've got Google
Groups. Heck, I can create a mailing list on ilias.ca, if it comes to that.
If you want a mailing list, file a bug in mozilla.org against justdave and he'll set one up for you. I think this is a perfectly reasonable request.
Go with each person having editbug privileges, instead of one ID. I want
to know who marked each bug.
Does one need editbugs to mark a keyword? Can we restrict the keywords on a user-by-user basis?
Thoughts? Tell me off, if you'd like. I won't be offended. :-)
Looks good to me so far, Chris :)
Kevin Brosnan
> Does one need editbugs to mark a keyword? Can we restrict the keywords on a
> user-by-user basis?
> --
> -------
> mike beltzner, user experience lead, mozilla corporation
I am quite sure keywords require editbugs to set.
I suspect restricting the keywords would be hard. Self policing would be
a better way to go about this. We should be talking about a low number
of primary bugs. A bugzilla saved search would trivial to setup and
check a few times a week to cull the herd.
Kevin Brosnan
Chris Ilias
> have a fix. These bugs should be nominated and plussed if possible for
> the next release, and are documented in the help DB as known issues.
> Reasonable workarounds/alternatives should be documented, and an
> indication that the issue is being looked at should be present, without
> necessarily linking to Bugzilla.
>
> support-issue-fixed - Bugs that have been fixed as of a certain
> release. Should be documented in the help DB with information about
> what versions have the fix, and workarounds for older versions should
> retained, if applicable.
I was just about to file a bug to get these keywords created, but
noticed a state between support-issue-documented and
support-issue-fixed. They are bugs which are fixed, but have not made it
into a release yet. Eg.
<http://groups.google.com/group/mozilla.support.thunderbird/msg/7c9f60cf60f52cb4>
Personally, I would rather support-issue-fixed be for bugs which are
fixed, but not necessarily in any release. We would have time update
each bug/document as they are fixed, rather then updating everything
upon a new release.
I don't see much need for another keyword to indicate a fix is in a release.
Mike Connor
of that I'm going to be posting today or tomorrow.
-- MIke
Chris Ilias
> Let's hold off for a bit, I have some bigger ideas that this is a part
> of that I'm going to be posting today or tomorrow.
Any update on this, Mike?