We need a feedback app, separate from bugzilla

RESOLVED WONTFIX

Status

Firefox OS
General
RESOLVED WONTFIX
6 years ago
6 years ago

People

(Reporter: akeybl, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

6 years ago
We need a B2G Input web app as a feedback channel for testers and release users.
(Reporter)

Updated

6 years ago
blocking-basecamp: --- → ?
Depends on: 762629

Updated

6 years ago
blocking-kilimanjaro: --- → ?
(Reporter)

Comment 1

6 years ago
This app (or some other short form feedback mechanism) needs to be in B2G at least pre-release to gather feedback, especially on "less critical" issues that the user may not file a bug about. We need to have very crisp feedback mechanisms for B2G - on Android we use Google Play reviews.
(In reply to Alex Keybl [:akeybl] from comment #1)
> This app (or some other short form feedback mechanism) needs to be in B2G at
> least pre-release to gather feedback, especially on "less critical" issues
> that the user may not file a bug about. We need to have very crisp feedback
> mechanisms for B2G - on Android we use Google Play reviews.

For basecamp, Ibai and Tyler - Is this needed for basecamp?

Comment 3

6 years ago
A Feedback app isnt part of the basecamp requirements from what i can see.  SUMO team is also working with TEF on a Tier 3 support SLA plan.  (mluna driving).   I would minus blocking-basecamp for that.

That said, i think we still need a way to get input from users directly, like this Feedback App idea.  Can this be something that mozilla builds and recommends as a top App from the Marketplace?   

If you're talking about shipping the App as part of default core apps, you'll need to loop in product.
(Reporter)

Comment 4

6 years ago
The main motivation here is pre-release testing and feedback, not post-release support. That means that it wouldn't have ever been a part of the basecamp requirements.

Comment 5

6 years ago
(In reply to Alex Keybl [:akeybl] from comment #4)
> The main motivation here is pre-release testing and feedback, not
> post-release support. That means that it wouldn't have ever been a part of
> the basecamp requirements.

thanks for clarifying, im in agreement.   comment 2 confused me.
blocking-basecamp: ? → ---

Comment 6

6 years ago
The requirement is to have a feedback mechanism, as Tony mentioned.

Developing an app on time could be challenging and Cheng is still looking for resources to update Input (the product) to cover this usecases.

Until then, can we go with a low level solution? I.e. An email address. We can even make a button that launches the email client with the address pre-populated. This is similar to what we are doing with the Marketplace.
(Reporter)

Comment 7

6 years ago
My requirements are:

* No login necessary - short form input
* Build ID(s) provided as part of the submission

Input specifically need not be a requirement, as mentioned in Comment 1. That being said, it's search functionality and graphing would be a huge win.
Is this still a k9o blocker? Or should this be unnomed? If it is, can someone provide rationale?
(Reporter)

Comment 9

6 years ago
(In reply to Jason Smith [:jsmith] from comment #8)
> Is this still a k9o blocker? Or should this be unnomed? If it is, can
> someone provide rationale?

This is really a Basecamp blocker, because we need a low bar feedback channel for testers. See comment 1.
blocking-basecamp: --- → ?

Comment 10

6 years ago
Not anticipating enough testers to make this valid, we could also just make something like this available in the marketplace if needed.
blocking-basecamp: ? → -
(Reporter)

Comment 11

6 years ago
(In reply to JP Rosevear [:jpr] from comment #10)
> Not anticipating enough testers to make this valid, we could also just make
> something like this available in the marketplace if needed.

I think minusing this is awfully premature without further conversation, as feedback channels are necessary to release a high quality product.
(Reporter)

Comment 12

6 years ago
Additionally, we are looking to have on the order of hundreds of testers - limiting feedback to bugs would prevent us from fixing anything but the most critical bugs, and wouldn't give us any insight into general user experience aspects.
I agree with JP and Ibai on this one. We don't need a specific input app, as an email alias is perfectly find in the short-term to manage feedback. We did this for the Mozillian Preview release that was targeted for 3000 users I believe and did not run into any issues on staying on top of user feedback. The input app seems like overkill for now. Might be an issue when we get larger though, so the k9o nom could be valid.
(Reporter)

Comment 14

6 years ago
This is not at all like Mozillians, Jason. From my experience in shipping platforms previously, you need to have more feedback channels than bug reporting for external testing (/especially/ with a 1.0 product)

As mentioned in https://bugzilla.mozilla.org/show_bug.cgi?id=762630#c7, I'm not against using email as long as there's a way to hit an app, automatically include a buildID, and submit the feedback.
blocking-basecamp: - → ?
Summary: We need a B2G Input web app → We need a feedback app, separate from bugzilla
This isn't a gecko-level feature, it would live in gaia.  That work is tracked in https://github.com/mozilla-b2g/gaia .

Since this wouldn't ship to users on real phones, it sort of by definition doesn't block release.  I would love to have something like this though, and I suspect it would take less time to implement than we're spending discussing here :).  (<input>, <button> and XHR POST I would hope.)
(Reporter)

Comment 16

6 years ago
(In reply to Chris Jones [:cjones] [:warhammer] from comment #15)
> This isn't a gecko-level feature, it would live in gaia.  That work is
> tracked in https://github.com/mozilla-b2g/gaia .
> 
> Since this wouldn't ship to users on real phones, it sort of by definition
> doesn't block release.  I would love to have something like this though, and
> I suspect it would take less time to implement than we're spending
> discussing here :).  (<input>, <button> and XHR POST I would hope.)

Makes sense - I've filed https://github.com/mozilla-b2g/gaia/issues/1819. Not sure how to mark that for prioritization, however.
Thanks.  Gaia work is triaged in addition to gecko work, and uses labels/milestones.
(Reporter)

Updated

6 years ago
Status: NEW → RESOLVED
blocking-basecamp: ? → ---
blocking-kilimanjaro: ? → ---
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 18

6 years ago
I'm late to this bug and although this is already resolved, I wanted to add my comments so everyone on this thread is on the same page.

We 100% absolutely need this for release.  Regardless if this ships with the product, it is imperative that we have a feedback mechanism (simple is fine) in place asap.  

Thanks Alex for filing and we'll use the Gaia github issue to track this work.  

If you have further questions or don't agree, please ping me separately.
You need to log in before you can comment on or make changes to this bug.