Closed Bug 1155070 Opened 5 years ago Closed 5 years ago

Bugs created by bugzilla lite should whiteboard [spark][foxfood]

Categories

(Firefox OS Graveyard :: Gaia::Bugzilla Lite, defect, P1)

ARM
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nhirata, Assigned: daleharvey)

References

Details

(Whiteboard: [spark])

Attachments

(1 file, 1 obsolete file)

1. launch bugzilla lite
2. sign in
3. create a bug

Expected: bug in bugzilla created by bugzilla lite should have whiteboard tag of [ignite][dogfood]
Actual: no whiteboard tag; see bug 1155062
No longer depends on: 1155062
Priority: -- → P1
Whiteboard: [ignite]
Not sure why these bugs should have [ignite] in the whiteboard, currently they are defaulted to the Gaia::Feedback component, once that changes we 'may' want to add a whiteboard tag to them, but not entirely sure.
As per discussion, the reason for the whiteboard tagging is so we know which channel it comes from and can gather statistics on device/app.

We can then check to see if we need to improve things.
Summary: Bugs created by bugzilla lite should whiteboard [ignite][dogfood] → Bugs created by bugzilla lite should whiteboard [ignite][foxfood]
Flags: needinfo?(jgong)
Yes, we will need to 2 distinct tags "[Ignite]" and "[foxfood]".  I am assigning this bug to Dale to implement on Bzlite for auto whiteboard tagging on BzLite app.
Assignee: nobody → dale+testing
Flags: needinfo?(jgong)
Assignee: dale+testing → dale
Whiteboard: [ignite] → [spark]
(In reply to Jean Gong from comment #3)
> Yes, we will need to 2 distinct tags "[Ignite]" and "[foxfood]".  I am
> assigning this bug to Dale to implement on Bzlite for auto whiteboard
> tagging on BzLite app.

(In reply to Naoki Hirata :nhirata (please use needinfo instead of cc) from comment #0)
> 1. launch bugzilla lite
> 2. sign in
> 3. create a bug
> 
> Expected: bug in bugzilla created by bugzilla lite should have whiteboard
> tag of [spark][foxfood]
> Actual: no whiteboard tag; see bug 1155062
Summary: Bugs created by bugzilla lite should whiteboard [ignite][foxfood] → Bugs created by bugzilla lite should whiteboard [spark][foxfood]
Clarification on my update in comment #4. We are replacing whiteboard tag [ignite] with [spark]..
Hey Byron

Quick question, not seeing a way to set whiteboard items via the API - http://bugzilla.readthedocs.org/en/latest/api/core/v1/bug.html#create-bug

Am I missing something? Cheers, Dale
Flags: needinfo?(glob)
(In reply to Dale Harvey (:daleharvey) from comment #6)
> Quick question, not seeing a way to set whiteboard items via the API -
> http://bugzilla.readthedocs.org/en/latest/api/core/v1/bug.html#create-bug

try setting the 'status_whiteboard' field.
i'll file a bug to get that documentation updated.
Flags: needinfo?(glob)
Thanks Byron that worked great
Comment on attachment 8598649 [details] [review]
https://github.com/mozilla-b2g/bzlite/pull/10

I don't think that this is a good way to track these bugs. Here are my suggestions for what we should do instead:
* Add `dogfood` to the keywords. Let's not add `[foxfooding]` to the whiteboard, or anything like that, since it's not ubiquitous, and then we'll have two pools of dogfooding bugs with a great amount of overlap between them.
* Set the `status-b2g-spark: affected` tracking flag. We would have to create this flag before going live with this.
* Include all device info that we can get in the report itself, such as the model and build info.

[spark] is currently being used to track bugs that we've already decided on working on. If we make all user reports use this tag, it'll be difficult to distinguish them.

ni Jean and Naoki for discussion.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(jgong)
Attachment #8598649 - Flags: review?(drs)
(In reply to Doug Sherk (:drs) (use needinfo?) from comment #10)

As per today's standup, we decided not to add a `status-b2g-spark` tracking flag, and instead use the `[spark]` whiteboard tag. The rest of comment 10 still applies.
Setting a status is inappropriate, this is a web application and people will not necessarily being using 'spark' or firefox os or even firefox. As mentioned we have a default 'catch all component' for untriaged bugs. What exactly are we trying to do by adding whiteboard tags at all?

> * Include all device info that we can get in the report itself, such as the model and build info.

If the user triggers by attaching logs then that information will be attached in the bug, otherwise its mostly unavailable.
(In reply to Dale Harvey (:daleharvey) from comment #12)
> Setting a status is inappropriate, this is a web application and people will
> not necessarily being using 'spark' or firefox os or even firefox. As
> mentioned we have a default 'catch all component' for untriaged bugs. What
> exactly are we trying to do by adding whiteboard tags at all?

Yes, but this app will be used mostly within the Spark initiative to start with. You're right that there's not an exact fit between Bugzilla Lite v1 and Spark, but in the vast majority of cases, adding these tags/statuses will help us be more effective at triaging.

There will likely be far fewer people installing this app on their own in the coming months, than those who receive it preloaded with Spark. We can always remove the tags and statuses in the future when Spark is no longer relevant. But in the interim, it's a helpful optimization for our process that doesn't in any way impede uses of the app. Alternatively, we could fork/customize the version that we ship with Spark, but that seems like overkill to me.

To summarize my feedback from comment 10 and comment 11, I think we should add the `dogfood` keyword and remove the `[foxfood]` whiteboard tag. Then I'll r+ this.
I really think we need a scalable way to find the bugs that come through this channel and then triage them.  Without some sort of tag other than unconfirmed, it won't get as much attention as there are too many currently.  Having a dogfood tag would at least let us know it comes from dogfooders and that we need some sort of priority on triaging them.

Also to note, we could use this as a potential method of getting statistics.

Historically, QA are the ones that end up triaging the bugs and verifying that the bugs are real bugs and they are also the ones that end up having to manually add the whiteboard and keywords.

I agree with what Doug is stating.  At the very least place in the keyword of dogfood.  We can get the device information through the other inputs that other people have.
> There will likely be far fewer people installing this app on their own in the coming months
> than those who receive it preloaded with Spark

Thats pretty unlikely, its got ~200 installs and it hasnt really been linked to anywhere (and only includes marketplace installs). I think we should be making a much larger effort to include the wider firefox and web ecosystem when building things for firefox os, we are currently far too siloed.

> Having a dogfood tag would at least let us know it comes from dogfooders 
> and that we need some sort of priority on triaging them.

I am not sure that the fact that bugs were created via bzlite means they should be given priority, it seems like it would be a better approach to ensure that we have a scaleable system to ensure that bugs people file against firefox os are not ignored wherever they come from. Is there anyone triaging 'dogfood' filed bugs? (like officially / regularly)

I think it would be good to have a more official workflow around triaging incoming bugs than to just have QA both file and triage incoming bugs. I self nominated myself to make sure to triage anything landing in Gaia::Feedback but to have a system across the whole of gaia would be great.

> Also to note without a keyword, it's hard to tell where the report came from, and what we need to 
> add to the bugzilla lite to make it better if it's just unconfirmed.

That sounds potentially useful, when bugs arent going straight into gaia:feedback and we have been seeing a lot of unconfirmed bugs can look at adding that
Attachment #8598649 - Flags: review?(drs)
Dale, if the bugs go straight to feedback, it doesn't give a history of where the bugs come from without a white board tag.

This is the same issue that I stated in regards to fennec's crashes, because some of those bugs go into gecko and then lost in the ether.  Some of these bugs will NOT be solely gaia issues and we need to track these bugs across all of bugzilla.
Comment on attachment 8598649 [details] [review]
https://github.com/mozilla-b2g/bzlite/pull/10

Naoki and I discussed this on IRC. We agreed that we'd like to see the "[bzlite]" whiteboard tag so that, once a bug is moved to the correct component, we still know that it came from BZLite. Since the 'dogfood' keyword is already used for dogfooding bugs, it doesn't give us a guaranteed tell that the user filed this using BZLite.

We also thought that it would be helpful to include the UA in the report body. It's standard, doesn't reveal much about the user, and tells us what platform they're on.
Attachment #8598649 - Flags: review?(drs) → review-
(In reply to Dale Harvey (:daleharvey) from comment #16)
> Thats pretty unlikely, its got ~200 installs and it hasnt really been linked
> to anywhere (and only includes marketplace installs). I think we should be
> making a much larger effort to include the wider firefox and web ecosystem
> when building things for firefox os, we are currently far too siloed.

Ok, good point.

> I am not sure that the fact that bugs were created via bzlite means they
> should be given priority, it seems like it would be a better approach to
> ensure that we have a scaleable system to ensure that bugs people file
> against firefox os are not ignored wherever they come from. Is there anyone
> triaging 'dogfood' filed bugs? (like officially / regularly)

It's not just for priority. Tagging them as [bzlite] or some such helps us track the success of BZLite as an app, see how many reports were filed using it, etc. It helps us track the origin of a bug that has since been moved out of Gaia::Feedback. 

> I think it would be good to have a more official workflow around triaging
> incoming bugs than to just have QA both file and triage incoming bugs. I
> self nominated myself to make sure to triage anything landing in
> Gaia::Feedback but to have a system across the whole of gaia would be great.

I agree, but this is easier said than done. We have very limited QA resources, so we should give them all the tools that we can to make their lives easier. Even if we create a better process, we will still benefit from having extra information from the get-go.
Attachment #8598649 - Attachment is obsolete: true
Attachment #8600262 - Flags: review?(drs)
Cheers, merged in https://github.com/mozilla-b2g/bzlite/commit/499a79aabfc5d100ba4040c0fdeb5ae77347861a
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Flags: needinfo?(jgong)
You need to log in before you can comment on or make changes to this bug.