|
|
| Line 31: |
Line 31: |
| === Support all channels of Firefox’s development process === | | === Support all channels of Firefox’s development process === |
| '''Strategy''' | | '''Strategy''' |
| * Develop submission support for Nightly users and a dashboard that supports the new channels in Firefox’s development cycle. Here is a list of what each feedback type (within each channel) will allow our community to give us: | | * Extend the praise/issues/ideas submission methods to all channels. We plan to remove the release dashboard and uplift the beta dashboard to support all channels in Firefox’s development cycle. |
| | |
| '''Outcomes'''
| |
| # Nightlies – Users on this channel are likelier to file bugs into Bugzilla and are adept at understanding regressed issues. Why force them to search through Bugzilla to find out their issue is already filed and lose that piece of additional regression information (i.e. environment, steps to reproduce and additional occurrences)? The Input team will add support to nightly users to file reports to our dashboard allowing our active community members to turn them into bugs or add additional information into already filed ones.
| |
| #* File a Report – Help track down regressions and possible stability/performance concerns by filing simple reports that allow us to cluster the information.
| |
| # Experimental – The purpose of this channel is to determine the future of whether features will be added to a release. The crowd is still rather technical, but more likely to give UX or feature related feedback rather than regressions. Therefore, we’ll need to use focus group type of data to better understand their viability. Fortunately, we’ll be able to use the same happy/sad/issues feedback that we used in the betas and continue it here.
| |
| #* Praise – Tell the development team what they’re doing right on specific features product characteristics.
| |
| #* Issues – Tell the development team about specific problems/bugs/concerns you’re facing with new features that are offered on your experimental build.
| |
| #* Ideas – Offer Ideas on how new features, listed over whats new/firstrun/Input pages, can better fit what you would expect out of that feature.
| |
| # Beta – The purpose of this channel is to determine the stability, performance and quality criteria is met in order to push a build to release. The crowd is still less technical, but still likely to give us enough constructive feedback to better aid our development team. We’ll continue to use the same happy/sad/issues feedback here as well.
| |
| #* Praise – Tell the development team what they’re doing right on specific features product characteristics.
| |
| #* Issues – Tell the development about specific problems/bugs/concerns you’re facing with new features that are offered on your beta build.
| |
| #* Share an Idea – Offer your suggestion on how Firefox could be enhanced.
| |
| # Release – Users are really just looking for a good browser to use rather than helping to build one. Therefore, we’ll use some higher level and deeper niche pieces of user feedback that offer support for these users to give us feedback in a way that will be constructive to the development team.
| |
| #* Rate your Experience – Give us a quick and easy rating on how we are doing over key aspects of Firefox ranging from start-up time to features
| |
| #* File a Report – Help track down regressions and possible stability/performance concerns by filing simple reports that allow us to cluster the information.
| |
| #* Share an Idea -Offer your suggestions on how Firefox could be enhanced.
| |
|
| |
|
| === Marry Input with Big Data approaches === | | === Marry Input with Big Data approaches === |