Closed Bug 1926942 Opened 1 year ago Closed 1 month ago

Crash report on demand documentation on SUMO [Desktop and Android V134]

Categories

(support.mozilla.org :: Knowledge Base Content, task)

Product:
support.mozilla.org
Component:
Knowledge Base Content
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: gerard-majax, Assigned: kiki)

References

Details

Attachments

(2 files)

android-release.png
104.26 KB, image/png
Details
desktop-release.png
517.30 KB, image/png
Details

Content access restriction: Is the content restricted to staff or under embargo (yes or no)? [REQUIRED]

No

Product (ensure to select only one product for each ticket. If your request involves multiple products, file an individual Bugzilla for each)

Choose one below and delete others. [REQUIRED]
Firefox for Desktop (Windows)
Firefox for Desktop (macOS)
Firefox for Desktop (Linux)
Firefox for Android
Firefox Focus / Klar (maybe?)

Select the type of request.

Choose one or more below and delete others. [REQUIRED]
KB content update/ new content: there's already https://support.mozilla.org/en-US/kb/mozillacrashreporter, but maybe we want a new page.

In-product link request: I think we need (linking from in-browser notification's "Learn More" link) for Desktop and Mobile (assuming i can add it on mobile)

Please summarize the request, emphasizing any user-facing changes. Include historical context or background information if it helps users understand the new features or changes. [REQUIRED]

We need to explain why it is important to share crash minidumps with us, what sensitive data they may have, and who has access to those data so that people can be sure what they are doing

I can provide a draft

##Are the user-facing changes mentioned above for the production release, or is the feature/change experimental/ beta? (Production, Experimental or Beta) [REQUIRED]

It is targetting production

Are the new features or changes region-specific? Are they going to be released in a gradual rollout? [REQUIRED]

No

Please indicate if this is an on- or off-train release [REQUIRED]

Will be on a train, still hoping for 133 but likely 134 now

What is the anticipated release date? [REQUIRED]

Release stable of 134 (jan 7; https://whattrainisitnow.com/release/?version=134)

Does the content need to be published prior to the release date? If so, when? [REQUIRED]

The sooner the better

Does the content need to be localized in any languages outside of EN-US? If yes, please indicate which languages. [REQUIRED]

It is welcome, and hopefully all languages in which firefox ships should be covered, but this is a community effort, so if we can get FR/DE/ES quickly that would already be good

Please include any related JIRA/Github/Bugzilla tickets, documentation, demos or practical use cases. [REQUIRED]

Bug 1853108
https://mozilla-hub.atlassian.net/browse/UXREQ-275

Please include links to any design assets, visuals, figma files, etc. [REQUIRED]

Cf the bug 1853108 for desktop (linux) and android screenshots

Please add instructions for testing that will enable us to replicate the expected product behavior. [REQUIRED]

I'm not sure this is relevant here, and the manual testing here would be a bit painful since it involves Remote Settings

Does the content need approval before publishing? If yes, identify the one approver responsible for this task.

I can approve

Assignee: nobody → lsiebert
Status: NEW → ASSIGNED

Task link in the Asana Content Roadmap: https://app.asana.com/0/1203460865189761/1208614017007004/f

Summary: Crash report on demand documentation on SUMO → Crash report on demand documentation on SUMO [Desktop and Android V134]
Assignee: lsiebert → lissyx+mozillians

Notes from Jo T:
"Couldn't validate this one and Chris P said it was not related to ToS Crash report. Because we are releasing new SUMOs for crash report, I think it might be okay to mark this as complete. If it comes up again after the release of new crash reporting, then we can reopen."

Closing this as Fixed for now, but a reopening or resubmitting if this functionality has landed or will land in an upcoming release.

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

(In reply to JR Johnson from comment #2)

Notes from Jo T:
"Couldn't validate this one and Chris P said it was not related to ToS Crash report. Because we are releasing new SUMOs for crash report, I think it might be okay to mark this as complete. If it comes up again after the release of new crash reporting, then we can reopen."

Can you elaborate? What is "ToS Crash report" ? What is this new SUMOs for crash report?

Flags: needinfo?(jojohnson)

FTR it's landed for months now, though disabled by default, but we are days away from enabling on nightly

Hi there. This Bugzilla content request has been sitting for 6+ months.

I have been reviewing our open bugs in the knowledge base content component seeking to clear out old open bugs. Looking through Bugzilla comments and reviewing our internal team tracking for content requests to understand if the bugs need to stay open or can be closed to reduce our backlog in Bugzilla.

Lucas our previous Technical writer and Jo T. the Product support manager sought to validate this with a product partner (Chris P) back in January thinking it was tied to Terms of Service (ToS) crash report updates that were landing in March. Chris P indicated to us that this was not related.

"new sumo's for crash report" are a reference to Chris submitting content support requests when updates to crash reporting actually land.

It looks like Lucas then reassigned this bug back to :gerard-majax. I am curious if you realized this was reassigned to you for action? Our assumption is that once assigned the person assigned is the one creating the content, whether that is our Technical writer or a contributor, etc.

My intent is to close this because its been sitting in Bugzilla for a long time with no action.

(In reply to JR Johnson from comment #5)

Hi there. This Bugzilla content request has been sitting for 6+ months.

I've pinged without success

I have been reviewing our open bugs in the knowledge base content component seeking to clear out old open bugs. Looking through Bugzilla comments and reviewing our internal team tracking for content requests to understand if the bugs need to stay open or can be closed to reduce our backlog in Bugzilla.

This bug needs to be fixed. I even proposed to write the content myself. No news.

Lucas our previous Technical writer and Jo T. the Product support manager sought to validate this with a product partner (Chris P) back in January thinking it was tied to Terms of Service (ToS) crash report updates that were landing in March. Chris P indicated to us that this was not related.

"new sumo's for crash report" are a reference to Chris submitting content support requests when updates to crash reporting actually land.

Still unclear to me

It looks like Lucas then reassigned this bug back to :gerard-majax. I am curious if you realized this was reassigned to you for action? Our assumption is that once assigned the person assigned is the one creating the content, whether that is our Technical writer or a contributor, etc.

Lucas did nothing, he left (or was let go, I dont know) and the bug kept even stale. I dont even have SSO access to asana to know what is behind that, I'm totally left out of the status of the bug, so I decided to assign it myself and write the content myself when this will get enabled by default on nightly. We have had long waiting on UX/legal at least on validating some of the changes, with no progress either so there was no "urgency" in having the content written.

My intent is to close this because its been sitting in Bugzilla for a long time with no action.

Easy: let's make content and push it to sumo.

To make it very clear: We are ready to launch a new feature that will prompt a small number of users an additional time for high-value crash reports.

See: https://mozilla-hub.atlassian.net/browse/FFXP-1979 and all the docs listed in the original description.

This should have some documentation that we can link to from within Firefox. So, as stated in the original description in the first comment: I think we need an in-product link where to put it. :gerard-majax can take a stab at the first version of the content.

Please can I pick this one up?

(In reply to Gian-Carlo Pascutto [:gcp] from comment #7)

To make it very clear: We are ready to launch a new feature that will prompt a small number of users an additional time for high-value crash reports.

See: https://mozilla-hub.atlassian.net/browse/FFXP-1979 and all the docs listed in the original description.

This should have some documentation that we can link to from within Firefox. So, as stated in the original description in the first comment: I think we need an in-product link where to put it. :gerard-majax can take a stab at the first version of the content.

When you say it is ready to launch to a small number of users, how many are you targeting and for which release?

Flags: needinfo?(jojohnson)

To be clear myself, I am not trying to simply say no to this content, but to ensure that this is support content worthy and that the timing for the content update is right. I wish it was as simple as "Easy: let's make content and push it to sumo", but there is more that should be considered before just writing content for every request we see.

If this is a request coming from the product team, then its something we would definitely validate and pursue with their sponsorship. It was not a request coming from product initially, which is why we followed up with our POC for android Chris P who indicated it was not needed at the time. it seems to have fallen through the cracks at that point though.

Now, It seems like it is something of Interest as indicated by Gian-Carlo's recent comments. As this relates to support content though, we generally do not write content for Nightly or Beta, but for release. For experiments as well, we generally will only write content if the experiment is hitting 50% of the Current release user base or if there is a legal or high impact/urgent reason to do so.

Prior to now this request did not fit the bill. If Gian-Carlo Pascutto is willing to be our POC on the product side for this and provide some of the release details I ask in comment 20, we can see about getting content generated for this with an in product link.

gerard-majax: I do apologize for introducing confusion here. While Bugzilla is public, the CX team does not only track content requests through Bugzilla. We duplicate and collaborate on content request utilizing Asana, a tool the whole CX team uses for tracking across all of our other CX work streams and projects. Asana, like confluence and some other software in use internally, is not accessible to contributors even NDA'd ones. This does lead to confusion with community members who want to be involved but are not privy to tools like this. I won't get into the details of our use of it as it is something outside of my teams direct control.

Also, I am happy to have Seburo tackle the content request once we have the necessary details and Flavius can support the in product link needs. Provided you are OK with letting them work the request gerard-majax?

Flags: needinfo?(lissyx+mozillians)
Flags: needinfo?(gpascutto)

When you say it is ready to launch to a small number of users, how many are you targeting and for which release?

We are launching the feature to everyone (on Nightly at first, then Beta, etc...). But it will only ever be visible to a specific set of users - those that experienced a crash we have no actionable data for. When deployed to release, about ~5000 users total may be prompted at a given time (this number may evolve as we observe response rates, we'd want to do as little prompting as possible).

As this relates to support content though, we generally do not write content for Nightly or Beta, but for release. For experiments as well, we generally will only write content if the experiment is hitting 50% of the Current release user base or if there is a legal or high impact/urgent reason to do so.

This won't be on release for a while. But the notification that is displayed would pretty much need a "Learn More" link (even on Nightly). I understand it's that which :gerard-majax needs. The content we can write ourselves for a first draft?

I can ping you back then to review the preliminary draft and rewrite/improve the article when the feature is riding the trains to release. Would that work?

Flags: needinfo?(gpascutto)

(Best to reach out when it lands in Beta so that we have the best chance of getting it ready for Release (and to give SUMO L10n a chance to localise the KB update).)

We still need an in-product link given as much as i know, we cannot link to an anchor to an existing page? I'd like us avoiding the route we had to take on https://bugzilla.mozilla.org/show_bug.cgi?id=1947157

Flags: needinfo?(lissyx+mozillians) → needinfo?(jojohnson)

(In reply to JR Johnson from comment #10)

gerard-majax: I do apologize for introducing confusion here. While Bugzilla is public, the CX team does not only track content requests through Bugzilla. We duplicate and collaborate on content request utilizing Asana, a tool the whole CX team uses for tracking across all of our other CX work streams and projects. Asana, like confluence and some other software in use internally, is not accessible to contributors even NDA'd ones. This does lead to confusion with community members who want to be involved but are not privy to tools like this. I won't get into the details of our use of it as it is something outside of my teams direct control.

Just for clarification, I am an employee and I dont have access to Asana.

(In reply to :gerard-majax from comment #13)

We still need an in-product link given as much as i know, we cannot link to an anchor to an existing page? I'd like us avoiding the route we had to take on https://bugzilla.mozilla.org/show_bug.cgi?id=1947157

We should be able to link an anchor to an existing page if that page has an anchor to link to.

Having one page will be easier to maintain and better for users to find the full information.

If I am allowed to, it would be useful to see the draft content to see what we need to do.

I assigned myself because there was no action for (In reply to Seburo from comment #15)

(In reply to :gerard-majax from comment #13)

We still need an in-product link given as much as i know, we cannot link to an anchor to an existing page? I'd like us avoiding the route we had to take on https://bugzilla.mozilla.org/show_bug.cgi?id=1947157

We should be able to link an anchor to an existing page if that page has an anchor to link to.

Confere the above bug, it was not working

Having one page will be easier to maintain and better for users to find the full information.

I agree

If I am allowed to, it would be useful to see the draft content to see what we need to do.

I'll share it later

Assignee: lissyx+mozillians → seburo3
Flags: needinfo?(jojohnson)

I chatted with Paul on this one and he is good to work on this. Thanks all for the comments and push to get this sorted.

Donna, I have handed this request over to Paul to take forward. Though it looks like an in product link would be needed. Can you assist with the in product link?

Flags: needinfo?(dkelly)

FTR current value is requested-crash-minidumps:

Those two values to updates are now the blockers to land both stacks of patches

Please can we have two in-product links - one for Fx Desktop and one for Fenix.

A draft for your approval - https://docs.google.com/document/d/1WQ36Ibx3BxjsZUQlSoB2qUEmPNqYRErxYKFQXzCmdHQ/edit?usp=sharing

It would be good to have the final screenshots of the error message instead of Nightly and pre-Nightly images. In my drat I have used your for placeholders for both of the articles, but will replace by final images when ready.

Once you are happy with this and we have the in-product links and the screenshots, I will load the two articles to Kitsune for staff review after which it will be passed to SUMO L10n to work on.

Flags: needinfo?(lissyx+mozillians)

The Google docs you have access to with my draft has up-to-date screenshot

You need release screenshot?

Flags: needinfo?(seburo3)

The desktop one we can crop (need to make it smaller anyway), but the Android screenshot refers to "Firefox Fenix".

Flags: needinfo?(seburo3)

(In reply to Seburo from comment #24)

The desktop one we can crop (need to make it smaller anyway), but the Android screenshot refers to "Firefox Fenix".

Cropping them is not OK ? I can likely just make a release simulation, but i've never done one for sure on android so :)

Cropping the images will make them easier for users to see - I can take care of that easily enough.

Are you happy with the article text?

Attached image android-release.png —

(In reply to Seburo from comment #21)

A draft for your approval - https://docs.google.com/document/d/1WQ36Ibx3BxjsZUQlSoB2qUEmPNqYRErxYKFQXzCmdHQ/edit?usp=sharing

It would be good to have the final screenshots of the error message instead of Nightly and pre-Nightly images. In my drat I have used your for placeholders for both of the articles, but will replace by final images when ready.

Once you are happy with this and we have the in-product links and the screenshots, I will load the two articles to Kitsune for staff review after which it will be passed to SUMO L10n to work on.

All good for me. I'll share a desktop release screenshot as well so you can use it the way you want

Flags: needinfo?(lissyx+mozillians)
Attached image desktop-release.png —

And here we go with a proper release screenshot :)

Flags: needinfo?(seburo3)

Okay, thank you, we can use that (I might trim it slightly, but all good).

We just need your confirmation around the draft text and SUMO staff to set up the two in-product links.

Flags: needinfo?(seburo3)

Comment 4 I already said I approve

Gentle ping about the in product links ?

Flags: needinfo?(jojohnson)
Flags: needinfo?(dkelly)

Hi Abby, thank you for those. Do you have the underlying article links handy so I can get the content moving forwards?

Flags: needinfo?(aparise)

Any news ?

Unfortunately not - I am still waiting on my needinfo.

See Also: → 1958999, 1931083, 1931078

@Paul I think that should be https://support.mozilla.org/kb/unsent-crash-reports-in-firefox but Abby should be able to confirm.

Can you kindly confirm when do you need this by?

Flags: needinfo?(jojohnson) → needinfo?(lissyx+mozillians)

(In reply to Kelimutu [:kiki] from comment #38)

Can you kindly confirm when do you need this by?

It was requested 11 months ago, so I would say the sooner the better ?

Flags: needinfo?(lissyx+mozillians)

Hi Paul,

The inproduct links are as follows so when you create the new article you should use these slugs so they are directed properly.

Firefox Slug: unsent-crash-reports-in-firefox
Mobile Slug: unsent-crash-reports-in-firefox-android

Firefox
https://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/unsent-crash-reports-in-firefox
Mobile
https://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/unsent-crash-reports-in-firefox-android

Let me know if that doesn't help!

Flags: needinfo?(aparise)
Assignee: seburo3 → kelimutu

This should be fine for review now, the enabling has been OK'd and it's landed for nightly-only. Next step is in bug 1950866 for general enabling. I dont think there will be any problem but we wanted to be safe.

Flags: needinfo?(kelimutu)
See Also: → 1950866

I just approved the article. Apologies for the delay!

Status: REOPENED → RESOLVED
Closed: 6 months ago → 1 month ago
Flags: needinfo?(kelimutu)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: