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)
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
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 :-)
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
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)
_______________________________________________
dev-apps-firefox mailing list
dev-apps...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-apps-firefox
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
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
> * 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
how about a meta bug?
-scratch
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)
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
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
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
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
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.
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
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.
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
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. :-)
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.
Thoughts? Tell me off, if you'd like. I won't be offended. :-)
> 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
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
Any update on this, Mike?