--> Switching to dev-webapps - realized this actually applies more in
that arena
Hi Karen,
I think understand the concept of the problem you are trying to capture
(which is state of the world of a large scope), but I don't think using
a whiteboard for this is going to work mainly due to the fact that it
encompasses a large, ambiguous scope. For apps-related issues, some
areas within the entire bugzilla component apply already, so I don't see
a need to add a whiteboard for these cases. Examples include:
* Firefox --> Web Apps: Firefox front-end integration into desktop
* Firefox --> Webapp Runtime: Firefox's desktop web runtime after an
app is launched
* FF Android --> Web Apps: FF Android's web apps integration -
front-end and runtime
* Core --> DOM: Apps: Core gecko issues in the mozApps API that
underlies the foundation of the apps system
* Marketplace --> Reviewer Tools: Reviewer tool issues, especially in
the reviewer process
All of those components have pretty much all of their bugs apply very
closely with this definition. I don't see a reason to introduce a
whiteboard on bugs in this component if it applies to the large majority
of bugs in that component. I'd instead just query on those components
and setup your watch list to watch those components.
As for other areas, I'd break these into categories based on need that
has a clear distinction. Here's an example I did a while back - I used
to stick the whiteboard "[topapps]" on any bug that would impact a top
app that was either evangelism or a platform issue. That provided both
an internal benefit to groups such as BD that understand what issues
they are impacted by + globally helping other groups, such as triage
when they need to make a blocking call. Similarly, the same idea applies
to the some of the customization work - that falls under another
category, which has bugs associated with it.
The more global entity I think becomes clearer once you define the
categories clearly that allow others know when and how to flag bugs.
Once you have your categories, then you can work the "black magic" to
get various dashboards up that allow you to view across the board the
bugs by area. By having those dashboards automatically generated, you
then get a clear, automated view into the health of the project by
category. I think that will better achieve the goal you are trying to
solve. Does that make sense?
Sincerely,
Jason Smith
Desktop QA Engineer
Mozilla Corporation
https://quality.mozilla.com
On 2/28/2013 2:36 PM, [email protected] wrote:
Hello -
In order to track bugs (in Bugzilla) specifically related to Apps in
a more consistent way, the Apps team proposes to start making use of
the 'whiteboard' feature in Bugzilla with an [*Apps Watch List]
*flag. The proposed scope of bugs that would be flagged this way
would include:
* Bugs related to a specific 3rd party provider apps targeted for
distribution via Marketplace (such as Nokia, Facebook, YouTube,
Accuweather, etc).
* Bugs tracked via Web Compatibility efforts that affect/intersect
with Marketplace apps
* Bugs related to the Apps Review Process (such as: unable to launch
apps, glitches in review processing, information needs on Dev Hub,
etc)
* Bugs entered as specific feature requests (such as: ability to
make some pre-installed undeletable, features needed to support
music (such as DRM), enhanced video performance, etc.)
* Bugs related to Grid Layouts for pre-installed content (bugs
already tagged with [3rd-party-preloaded-apps] whiteboard label
would be included in the larger [Apps Watch List] category.
* Bugs related to the update process for Apps sourced from Marketplace.
By using this feature, we will be able to view all bugs related to the
delivery of Apps in Marketplace via the Advanced Search Feature in
Bugzilla (Detailed Bug Information, Whiteboard = *[Apps Watch List]
*). This will aid in keeping a handle on bugs impacting apps, assist
with prioritization, assist with setting expectations with partners
and staying tuned in to key bugs that are blocking significant content
partners / capabilities such as DRM for music, video related elements,
etc. All of which should help foster adoption of the Firefox OS in
coming markets.
This approach has been discussed and agreed among several Content Team
members already. We recognize that further
refinements/categorizations may be required in the future but would
like to start with this. I want to implement this approach next week
- your feedback and input is requested .... If you have suggestions,
please let me know.
Best regards,
Karen
_______________________________________________
dev-webapps mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-webapps
